From sandeen@redhat.com Wed Jun 1 00:22:28 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p515MRlI095506 for ; Wed, 1 Jun 2011 00:22:28 -0500 X-ASG-Debug-ID: 1306905746-6c0b03990000-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 A53B6492B1E for ; Tue, 31 May 2011 22:22:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id kVRRCPemrI4HV4Jr for ; Tue, 31 May 2011 22:22:26 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p515MPpH000579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2011 01:22:25 -0400 Received: from liberator.sandeen.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p515MMYw021209 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 01:22:24 -0400 Message-ID: <4DE5CC8E.1090208@redhat.com> Date: Wed, 01 Jun 2011 00:22:22 -0500 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Amir Goldstein CC: XFS , Sergey Ivanov , Ext4 Developers List , linux-fsdevel X-ASG-Orig-Subj: Re: [PATCH] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH] xfstests: add support for ext4dev FSTYP References: <4DE5C1FE.8080006@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1306905747 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 5/31/11 11:56 PM, Amir Goldstein wrote: > On Wed, Jun 1, 2011 at 7:37 AM, Eric Sandeen wrote: >> On 5/31/11 10:13 PM, Amir Goldstein wrote: >>> From: Amir Goldstein >>> >>> blkid knows to identify the ext4dev FSTYP of a partition that was >>> formatted with mkfs.ext4dev. >>> quota tools and various util-linux utils are also aware of ext4dev, >>> so ext4dev shares the same capabilities as ext4. >>> >>> While testing on Fedora 15, we encoutered a buggy fsck utility, which >>> invokes fsck.ext4, even though it was called with -t ext4dev argument. >>> In our setup fsck.ext4dev knows about new fs features that fsck.ext4 >>> doesn't know, so the generic_fs_check fails. >>> Since we have no real use of the extra capabilities provided by fsck util, >>> we decided to invoke fsck.$FSTYP directly to avoid this issue. >> >> Adding ext4dev to every case seems harmless enough. TBH I thought I had >> it there already but I guess not. >> >> I'm less certain of the change from fsck -t $FSTYP to fsck.$FSTYP >> >> What issue are you avoiding? wouldn't fsck -t ext4dev invoke fsck.ext4dev anyway? >> >> It seems like it should be harmless, but I don't understand how it helps you. >> > > As I wrote in the patch description, the fsck utility in Fedora 15 invokes > fsck.ext4 for some reason when calling fsck -t ext4dev. Oh, right. > this fails because fsck.ext4 doesn't know the snapshot feature. > I didn't debug fsck utility for that. it seemed pointless. Did you file a bug with Fedora? I'd rather fix the root cause than work around it... Feel free to cc: me on the bug. -Eric From sandeen@redhat.com Wed Jun 1 00:34:41 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p515YfhC095848 for ; Wed, 1 Jun 2011 00:34:41 -0500 X-ASG-Debug-ID: 1306906480-661200030000-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 E9C82492CE5 for ; Tue, 31 May 2011 22:34:40 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id hlfGBFnMyDccEOdE for ; Tue, 31 May 2011 22:34:40 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p515Yc9Q002416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2011 01:34:38 -0400 Received: from liberator.sandeen.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p515YaFb004230 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 01:34:37 -0400 Message-ID: <4DE5CF6C.4080707@redhat.com> Date: Wed, 01 Jun 2011 00:34:36 -0500 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Amir Goldstein CC: XFS , Sergey Ivanov , Ext4 Developers List , linux-fsdevel X-ASG-Orig-Subj: Re: [PATCH] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH] xfstests: add support for ext4dev FSTYP References: <4DE5C1FE.8080006@redhat.com> <4DE5CC8E.1090208@redhat.com> In-Reply-To: <4DE5CC8E.1090208@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1306906480 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/1/11 12:22 AM, Eric Sandeen wrote: > On 5/31/11 11:56 PM, Amir Goldstein wrote: >> On Wed, Jun 1, 2011 at 7:37 AM, Eric Sandeen wrote: >>> On 5/31/11 10:13 PM, Amir Goldstein wrote: >>>> From: Amir Goldstein >>>> >>>> blkid knows to identify the ext4dev FSTYP of a partition that was >>>> formatted with mkfs.ext4dev. >>>> quota tools and various util-linux utils are also aware of ext4dev, >>>> so ext4dev shares the same capabilities as ext4. >>>> >>>> While testing on Fedora 15, we encoutered a buggy fsck utility, which >>>> invokes fsck.ext4, even though it was called with -t ext4dev argument. >>>> In our setup fsck.ext4dev knows about new fs features that fsck.ext4 >>>> doesn't know, so the generic_fs_check fails. >>>> Since we have no real use of the extra capabilities provided by fsck util, >>>> we decided to invoke fsck.$FSTYP directly to avoid this issue. >>> >>> Adding ext4dev to every case seems harmless enough. TBH I thought I had >>> it there already but I guess not. >>> >>> I'm less certain of the change from fsck -t $FSTYP to fsck.$FSTYP >>> >>> What issue are you avoiding? wouldn't fsck -t ext4dev invoke fsck.ext4dev anyway? >>> >>> It seems like it should be harmless, but I don't understand how it helps you. >>> >> >> As I wrote in the patch description, the fsck utility in Fedora 15 invokes >> fsck.ext4 for some reason when calling fsck -t ext4dev. > > Oh, right. > >> this fails because fsck.ext4 doesn't know the snapshot feature. >> I didn't debug fsck utility for that. it seemed pointless. > > Did you file a bug with Fedora? I'd rather fix the root cause than work around it... > Feel free to cc: me on the bug. RHEL6 does the same; mkfs.ext4dev then fsck -t ext4dev invokes fsck.ext4; but this is because blkid identifies it as ext4, not ext4dev, despite the test_fs flag being set. ISTR this is due to some tortured logic about when ext4dev isn't ext4dev, but I don't remember the details... I don't know if this is the same situation you're seeing; just to double check - does blkid correctly identify it as ext4dev on F15? -Eric > -Eric > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html From amir73il@gmail.com Wed Jun 1 01:37:18 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,FREEMAIL_FROM, J_CHICKENPOX_33,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p516bH6N097845 for ; Wed, 1 Jun 2011 01:37:18 -0500 X-ASG-Debug-ID: 1306910236-119700370000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-wy0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0CBD54930F1 for ; Tue, 31 May 2011 23:37:16 -0700 (PDT) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by cuda.sgi.com with ESMTP id JcN9xn1U1NuGhMu9 for ; Tue, 31 May 2011 23:37:16 -0700 (PDT) Received: by wyi11 with SMTP id 11so4477071wyi.26 for ; Tue, 31 May 2011 23:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=liIKI9y6bp0gkrZgiIdQUUdviTZ6fxJEnLry8BtjEsA=; b=sg69Lo3GS1B+6LZWaubqN23rNI07PVKGjw21O30H3gfa3KqFeGDbG5LAfGNBhHnck/ 0+Zz34OwMYRo13hNu5Q3tX/76nNqvccTNpCldkfRuYsBwQucEBZMcwgd+fz03iVjzKqO pR/JiELMhJ4uT80vtMW97XDWkchYThD8aJKx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BkT3pMjffCx9Fizy8T37399TJ0dMPTJEIHTXxRpRnscUNDqS0KZX/4dYMn/WPZw95F WgY1xoEDa+h6paTBJ3eq+dkOJXzjDbus4cXLpfNffonD/gK+cOhsbZu6rz08VLAYtahV 9CEQuWLiQYNr4JyzuWLyjyP3PxriUV8SBZkv4= MIME-Version: 1.0 Received: by 10.216.230.76 with SMTP id i54mr6471263weq.108.1306910235951; Tue, 31 May 2011 23:37:15 -0700 (PDT) Received: by 10.216.221.135 with HTTP; Tue, 31 May 2011 23:37:15 -0700 (PDT) In-Reply-To: <4DE5CF6C.4080707@redhat.com> References: <4DE5C1FE.8080006@redhat.com> <4DE5CC8E.1090208@redhat.com> <4DE5CF6C.4080707@redhat.com> Date: Wed, 1 Jun 2011 09:37:15 +0300 Message-ID: X-ASG-Orig-Subj: Re: [PATCH] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH] xfstests: add support for ext4dev FSTYP From: Amir Goldstein To: Eric Sandeen Cc: XFS , Sergey Ivanov , Ext4 Developers List , linux-fsdevel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-wy0-f181.google.com[74.125.82.181] X-Barracuda-Start-Time: 1306910237 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65269 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Jun 1, 2011 at 8:34 AM, Eric Sandeen wrote: > On 6/1/11 12:22 AM, Eric Sandeen wrote: >> On 5/31/11 11:56 PM, Amir Goldstein wrote: >>> On Wed, Jun 1, 2011 at 7:37 AM, Eric Sandeen wrote= : >>>> On 5/31/11 10:13 PM, Amir Goldstein wrote: >>>>> From: Amir Goldstein >>>>> >>>>> blkid knows to identify the ext4dev FSTYP of a partition that was >>>>> formatted with mkfs.ext4dev. >>>>> quota tools and various util-linux utils are also aware of ext4dev, >>>>> so ext4dev shares the same capabilities as ext4. >>>>> >>>>> While testing on Fedora 15, we encoutered a buggy fsck utility, which >>>>> invokes fsck.ext4, even though it was called with -t ext4dev argument= . >>>>> In our setup fsck.ext4dev knows about new fs features that fsck.ext4 >>>>> doesn't know, so the generic_fs_check fails. >>>>> Since we have no real use of the extra capabilities provided by fsck = util, >>>>> we decided to invoke fsck.$FSTYP directly to avoid this issue. >>>> >>>> Adding ext4dev to every case seems harmless enough. =A0TBH I thought I= had >>>> it there already but I guess not. >>>> >>>> I'm less certain of the change from fsck -t $FSTYP to fsck.$FSTYP >>>> >>>> What issue are you avoiding? =A0wouldn't fsck -t ext4dev invoke fsck.e= xt4dev anyway? >>>> >>>> It seems like it should be harmless, but I don't understand how it hel= ps you. >>>> >>> >>> As I wrote in the patch description, the fsck utility in Fedora 15 invo= kes >>> fsck.ext4 for some reason when calling fsck -t ext4dev. >> >> Oh, right. >> >>> this fails because fsck.ext4 doesn't know the snapshot feature. >>> I didn't debug fsck utility for that. it seemed pointless. >> >> Did you file a bug with Fedora? =A0I'd rather fix the root cause than wo= rk around it... >> Feel free to cc: me on the bug. No, I didn't file a bug. In any case, it was Sergey, who tested and reported the problem on F15. Would you agree to fix the problem in xfstests now, so that F15 users can test ext4dev and fix the bug in fsck regardless? > > RHEL6 does the same; mkfs.ext4dev then fsck -t ext4dev invokes fsck.ext4;= but this > is because blkid identifies it as ext4, not ext4dev, despite the test_fs = flag being set. > > ISTR this is due to some tortured logic about when ext4dev isn't ext4dev,= but > I don't remember the details... I don't know if this is the same situatio= n > you're seeing; just to double check - does blkid correctly identify it as= ext4dev > on F15? For me (on Ubuntu) blkid identifies ext4dev, but maybe the tortured logic finds unknown features a justification for declaring ext4dev? Segrey, can you answer the question for F15? Did you set FSTYP to ext4dev manually or did blkid identified it for you? > > -Eric > >> -Eric >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html > > From ajeet.yadav.77@gmail.com Wed Jun 1 01:41:33 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p516fXie098586 for ; Wed, 1 Jun 2011 01:41:33 -0500 X-ASG-Debug-ID: 1306910492-68f802d90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-vx0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C5C1249311A for ; Tue, 31 May 2011 23:41:32 -0700 (PDT) Received: from mail-vx0-f181.google.com (mail-vx0-f181.google.com [209.85.220.181]) by cuda.sgi.com with ESMTP id heoIZLVqLEulUpvX for ; Tue, 31 May 2011 23:41:32 -0700 (PDT) Received: by vxb39 with SMTP id 39so4495056vxb.26 for ; Tue, 31 May 2011 23:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Fn9MunqSat+F/QKSBoTgkb4vNmO7Z7h6WwLW5hRHcUc=; b=FW9YA7B52JDyt1hSTTxZJ76q2YYEyrcUOtcVyNKpoUxLxaN48dGj3kGDgHRKGn8ehU IQwKMfsrTEgCl6UaiJcN5pLmFzfCq3sVI4MSQzuW6xpuaq+FI5GcFH40niBotk5uZ53m hgfdlPKusheHNRXxWhLizfGX7uSQtQWc3kRCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ee6lxNSzJIaJwdO1WBHKXleLhPdYA9kpS/J5PR7svMZY5T3mm51GrKM2xuwkvsW8B/ KcNwjo1wgpzg2XZ/apYAd4+6koWzMZsmHUAwmWk+5ugvXSOudIh4/nJo11blGGipkN3z sTa0RB77IZf2Yb6A5Fzf3fqD5SQjh5MzO+xEA= MIME-Version: 1.0 Received: by 10.220.201.1 with SMTP id ey1mr2680734vcb.123.1306910491976; Tue, 31 May 2011 23:41:31 -0700 (PDT) Received: by 10.220.75.207 with HTTP; Tue, 31 May 2011 23:41:31 -0700 (PDT) Date: Wed, 1 Jun 2011 12:11:31 +0530 Message-ID: X-ASG-Orig-Subj: What is xfs_prepair64 ? Subject: What is xfs_prepair64 ? From: Ajeet Yadav To: xfs@oss.sgi.com Content-Type: text/plain; charset=UTF-8 X-Barracuda-Connect: mail-vx0-f181.google.com[209.85.220.181] X-Barracuda-Start-Time: 1306910492 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4037 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=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65269 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean xfstests FS QA Test No. 148 needs "xfs_prepair64" to run ? I did not find this in xfsprogs-3.1.5, please guide from where to find this ? With Regards, Ajeet Yadav From s.priebe@profihost.ag Wed Jun 1 05:54:58 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51Asw3U115917 for ; Wed, 1 Jun 2011 05:54:58 -0500 X-ASG-Debug-ID: 1306925695-37c602d20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server655-han.de-nserver.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6D4E0165CB9E for ; Wed, 1 Jun 2011 03:54:56 -0700 (PDT) Received: from server655-han.de-nserver.de (server655-han.de-nserver.de [85.158.177.45]) by cuda.sgi.com with ESMTP id w0Dd89BVCqKZ2lNr for ; Wed, 01 Jun 2011 03:54:56 -0700 (PDT) Received: (qmail 26636 invoked from network); 1 Jun 2011 12:54:55 +0200 Received: from fw-office.allied-internet.ag (HELO s.priebe-desktop) (85.158.179.66) (smtp-auth username hostmaster@profihost.com, mechanism plain) by server655-han.de-nserver.de (qpsmtpd/0.82) with ESMTPA; Wed, 01 Jun 2011 12:54:55 +0200 Message-ID: <4DE61A7F.40800@profihost.ag> Date: Wed, 01 Jun 2011 12:54:55 +0200 From: Stefan Priebe - Profihost AG User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS crashes with shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr Subject: XFS crashes with shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-User-Auth: Auth by hostmaster@profihost.com through 85.158.179.66 X-Barracuda-Connect: server655-han.de-nserver.de[85.158.177.45] X-Barracuda-Start-Time: 1306925697 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0195 1.0000 -1.8943 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.89 X-Barracuda-Spam-Status: No, SCORE=-1.89 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65286 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi guys, we're seeing a really bad behaviour on one of our machines running vanilla 2.6.32.40 kernel. It freezes from time to time or processes starts to hang. At the same time the following message appears in the kernel log: shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-274207938304 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549059303168 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549500554116 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549360922112 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549407219078 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549480231300 Any ideas? An xfs_repair says everything is fine. -- Regards, Stefan Priebe From s.priebe@profihost.ag Wed Jun 1 06:05:48 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51B5m0t116251 for ; Wed, 1 Jun 2011 06:05:48 -0500 X-ASG-Debug-ID: 1306926346-310b03990000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server655-han.de-nserver.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D2B181ED09DB for ; Wed, 1 Jun 2011 04:05:47 -0700 (PDT) Received: from server655-han.de-nserver.de (server655-han.de-nserver.de [85.158.177.45]) by cuda.sgi.com with ESMTP id g0oq7aTPM3FxcGKy for ; Wed, 01 Jun 2011 04:05:47 -0700 (PDT) Received: (qmail 29500 invoked from network); 1 Jun 2011 13:05:45 +0200 Received: from fw-office.allied-internet.ag (HELO s.priebe-desktop) (85.158.179.66) (smtp-auth username hostmaster@profihost.com, mechanism plain) by server655-han.de-nserver.de (qpsmtpd/0.82) with ESMTPA; Wed, 01 Jun 2011 13:05:45 +0200 Message-ID: <4DE61D09.8010507@profihost.ag> Date: Wed, 01 Jun 2011 13:05:45 +0200 From: Stefan Priebe - Profihost AG User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS crashes with shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr Subject: XFS crashes with shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-User-Auth: Auth by hostmaster@profihost.com through 85.158.179.66 X-Barracuda-Connect: server655-han.de-nserver.de[85.158.177.45] X-Barracuda-Start-Time: 1306926347 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0050 1.0000 -1.9886 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.2, rules version 3.2.2.65287 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi guys, we're seeing a really bad behaviour on one of our machines running vanilla 2.6.32.40 kernel. It freezes from time to time or processes starts to hang. At the same time the following message appears in the kernel log: shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-274207938304 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549059303168 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549500554116 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549360922112 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549407219078 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549480231300 Any ideas? An xfs_repair says everything is fine. -- Regards, Stefan Priebe From anonymous@lxplesk223.fm.netbenefit.co.uk Wed Jun 1 06:22:10 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_50,DATE_IN_PAST_24_48 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51BMARw116757 for ; Wed, 1 Jun 2011 06:22:10 -0500 X-ASG-Debug-ID: 1306927327-07ff03330000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lxplesk223.fm.netbenefit.co.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 40D36493B47 for ; Wed, 1 Jun 2011 04:22:07 -0700 (PDT) Received: from lxplesk223.fm.netbenefit.co.uk (www.aestheticandimplantdentistry.co.uk [62.128.152.171]) by cuda.sgi.com with ESMTP id HqrdGj3alGoS0VIf for ; Wed, 01 Jun 2011 04:22:07 -0700 (PDT) Received: (qmail 25346 invoked by uid 48); 31 May 2011 10:00:07 +0100 Date: 31 May 2011 10:00:07 +0100 Message-ID: <20110531090007.25343.qmail@lxplesk223.fm.netbenefit.co.uk> To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Randolf recommends this site Subject: Randolf recommends this site MIME-Version: 1.0 From: "laura.murphy@fmc.co.uk" Reply-To: "bizopps.v73@gmail.com" Content-type: text/plain; charset=iso-8859-1 X-Barracuda-Connect: www.aestheticandimplantdentistry.co.uk[62.128.152.171] X-Barracuda-Start-Time: 1306927328 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4783 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.49 X-Barracuda-Spam-Status: No, SCORE=0.49 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DATE_IN_PAST_24_48, DATE_IN_PAST_24_48_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65288 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 DATE_IN_PAST_24_48 Date: is 24 to 48 hours before Received: date 0.48 DATE_IN_PAST_24_48_2 DATE_IN_PAST_24_48_2 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Your friend Randolf (bizopps.v73@gmail.com ) has recommended this site to you, and sends you the following message: Hi, Are you ready? The biggest trick all these push button scam artists use is. Passing off their vendor account as an affiliate account. And they usually use a Clickbank account vendor account in all those impressive but fake screen shots you see on their websites. Why do they need to do this? Well, because these scam artists are not affiliate marketers, they can’t make it work. They don’t want to make it work, they just want to cheat you out of your money. They don’t make their money from affiliate marketing …they make it by passing off crap software as something it is not!... And hope that as many people as possible buy the crap before word gets around what they are doing, then they just take down the website. Well this guy has had enough of all their crap and exposed their whole facade in this short video... http://simplebis.co.cc/nmo2.php?e=linux-xfs@oss.sgi.com Watch it now, before he takes it down. Kind regards, Randolf To unsubscribe please click the link below: http://simplebis.co.cc/un.php?e=linux-xfs@oss.sgi.com http://www.independentseminars.co.uk/store/proddetail.php?prod=001YDH From support@marketingbiz.com Wed Jun 1 06:22:58 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51BMwqd116913 for ; Wed, 1 Jun 2011 06:22:58 -0500 X-ASG-Debug-ID: 1306927376-07fe03520000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from omr5.networksolutionsemail.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8EF73493B4F for ; Wed, 1 Jun 2011 04:22:56 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by cuda.sgi.com with ESMTP id VqWBqn8L9mK7pXmc for ; Wed, 01 Jun 2011 04:22:56 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p51BMucG005694 for ; Wed, 1 Jun 2011 07:22:56 -0400 Authentication-Results: cm-omr6 smtp.user=support@marketingbiz.com; auth=pass (LOGIN) X-Authenticated-UID: support@marketingbiz.com Received: from [112.201.240.140] ([112.201.240.140:23358] helo=192.168.1.101) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C6/54-03149-F0126ED4; Wed, 01 Jun 2011 07:22:56 -0400 Date: Wed, 1 Jun 2011 11:22:43 +0000 To: linux-xfs@oss.sgi.com From: Wealth Builder Reply-To: Wealth Builder X-ASG-Orig-Subj: Have You Blown A Chance at Wealth? Subject: Have You Blown A Chance at Wealth? Message-ID: <20fe40750a805b328caf55bcdcd6bce7@192.168.1.101> X-Priority: 3 X-Mailer: PHPMailer [version 1.72] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Barracuda-Connect: omr5.networksolutionsemail.com[205.178.146.55] X-Barracuda-Start-Time: 1306927376 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5014 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65288 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi Fellow Marketers, What a stir Mark Hardy has made with his astounding, traffic-driving software. He’s proved he knows whereof he speaks. He’s walked the affiliate marketing walk and now he, and a few select others, reap the benefits of huge commissions, derived from an advanced algorithm that taps into a traffic torrent called the Black River. Have you been by yet? http://iwealth004.co.cc/affmcmx.php?e=linux-xfs@oss.sgi.com Because Mark doesn’t need the small amount he’s charging for his amazing software. And he doesn’t need to be checking on a website for sales. But he does want to help out affiliate marketers who are bold enough to seek help and ready to change their lives for the better. I haven’t been by Mark’s site today, so it may be gone already. If that’s so, and you never made it by, all I can say is: too bad. Opportunities like Mark’s software are rare. Check this out quickly: http://iwealth004.co.cc/affmcmx.php?e=linux-xfs@oss.sgi.com You could’ve been a member of the affiliate marketing elite, pulling in six and seven figures. Instead, you’ll go on being cautious. There may still be time. Six clicks is all it takes to set-up, align and activate this revolutionary software. Six clicks to success. You deserve it. You can handle it. Don’t let yourself and your family down by failing to act. http://iwealth004.co.cc/affmcmx.php?e=linux-xfs@oss.sgi.com Good Luck Wealth Builder Team Removal link: http://iwealth004.co.cc/un.php?e=linux-xfs@oss.sgi.com From sergey57@gmail.com Wed Jun 1 06:48:18 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.1 required=5.0 tests=BAYES_20,FREEMAIL_FROM, HTML_MESSAGE,J_CHICKENPOX_33,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51BmHpl117635 for ; Wed, 1 Jun 2011 06:48:18 -0500 X-ASG-Debug-ID: 1306928896-6bf900650000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-iw0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AFA181ED0B92 for ; Wed, 1 Jun 2011 04:48:16 -0700 (PDT) Received: from mail-iw0-f181.google.com (mail-iw0-f181.google.com [209.85.214.181]) by cuda.sgi.com with ESMTP id UOSpeZ05OKWuAhx9 for ; Wed, 01 Jun 2011 04:48:16 -0700 (PDT) Received: by iwn38 with SMTP id 38so4987454iwn.26 for ; Wed, 01 Jun 2011 04:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ijRwgHlJhhArE/bTmrpPYh8Du64e7J5xOPUFDyiJqo0=; b=c016XsXkTGSbJ4Q4Pfs25Pvfou067FBKcMhBxDgehWleD0uYqgz0mebrk2Y35qTogV jmVXECrB7AaVjAIAU1/NHtDdEsKZhtH1qegDtLqBOxE36IMQ9YjudJahxrvcbLDYMvfc kyAmfel7fggxSEuUnE+Hiotz4BhYS+wanzLLY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FBlSTTU0NK5jV2uHsgnnl9JgLYf/668NlbGb2lXbo/Tv1jT/v/P61kPeTQ9GoU8xKj /k2u7Y+CdkcDGCdDFLJmZ7c0Y153s0NqvQ3drgOuYklpsgpv9S3I60yn2zuM4xK9B3ZS ERT7IJtYbgkwpaZn7cgmIV3vkQT8zO2AWxmus= MIME-Version: 1.0 Received: by 10.42.142.7 with SMTP id q7mr14756568icu.231.1306928896133; Wed, 01 Jun 2011 04:48:16 -0700 (PDT) Received: by 10.231.32.202 with HTTP; Wed, 1 Jun 2011 04:48:16 -0700 (PDT) In-Reply-To: References: <4DE5C1FE.8080006@redhat.com> <4DE5CC8E.1090208@redhat.com> <4DE5CF6C.4080707@redhat.com> Date: Wed, 1 Jun 2011 07:48:16 -0400 Message-ID: X-ASG-Orig-Subj: Re: [PATCH] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH] xfstests: add support for ext4dev FSTYP From: sergey ivanov To: Amir Goldstein Cc: Eric Sandeen , XFS , Ext4 Developers List , linux-fsdevel Content-Type: multipart/alternative; boundary=90e6ba6e822a99cba104a4a51871 X-Barracuda-Connect: mail-iw0-f181.google.com[209.85.214.181] X-Barracuda-Start-Time: 1306928896 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65288 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --90e6ba6e822a99cba104a4a51871 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 1, 2011 at 2:37 AM, Amir Goldstein wrote: > On Wed, Jun 1, 2011 at 8:34 AM, Eric Sandeen wrote: > > On 6/1/11 12:22 AM, Eric Sandeen wrote: > >> On 5/31/11 11:56 PM, Amir Goldstein wrote: > >>> On Wed, Jun 1, 2011 at 7:37 AM, Eric Sandeen > wrote: > >>>> On 5/31/11 10:13 PM, Amir Goldstein wrote: > >>>>> From: Amir Goldstein > >>>>> > >>>>> blkid knows to identify the ext4dev FSTYP of a partition that was > >>>>> formatted with mkfs.ext4dev. > >>>>> quota tools and various util-linux utils are also aware of ext4dev, > >>>>> so ext4dev shares the same capabilities as ext4. > >>>>> > >>>>> While testing on Fedora 15, we encoutered a buggy fsck utility, which > >>>>> invokes fsck.ext4, even though it was called with -t ext4dev > argument. > >>>>> In our setup fsck.ext4dev knows about new fs features that fsck.ext4 > >>>>> doesn't know, so the generic_fs_check fails. > >>>>> Since we have no real use of the extra capabilities provided by fsck > util, > >>>>> we decided to invoke fsck.$FSTYP directly to avoid this issue. > >>>> > >>>> Adding ext4dev to every case seems harmless enough. TBH I thought I > had > >>>> it there already but I guess not. > >>>> > >>>> I'm less certain of the change from fsck -t $FSTYP to fsck.$FSTYP > >>>> > >>>> What issue are you avoiding? wouldn't fsck -t ext4dev invoke > fsck.ext4dev anyway? > >>>> > >>>> It seems like it should be harmless, but I don't understand how it > helps you. > >>>> > >>> > >>> As I wrote in the patch description, the fsck utility in Fedora 15 > invokes > >>> fsck.ext4 for some reason when calling fsck -t ext4dev. > >> > >> Oh, right. > >> > >>> this fails because fsck.ext4 doesn't know the snapshot feature. > >>> I didn't debug fsck utility for that. it seemed pointless. > >> > >> Did you file a bug with Fedora? I'd rather fix the root cause than work > around it... > >> Feel free to cc: me on the bug. > > No, I didn't file a bug. > In any case, it was Sergey, who tested and reported the problem on F15. > > Would you agree to fix the problem in xfstests now, so that F15 users can > test ext4dev and fix the bug in fsck regardless? > > > > > RHEL6 does the same; mkfs.ext4dev then fsck -t ext4dev invokes fsck.ext4; > but this > > is because blkid identifies it as ext4, not ext4dev, despite the test_fs > flag being set. > > > > ISTR this is due to some tortured logic about when ext4dev isn't ext4dev, > but > > I don't remember the details... I don't know if this is the same > situation > > you're seeing; just to double check - does blkid correctly identify it as > ext4dev > > on F15? > > > For me (on Ubuntu) blkid identifies ext4dev, but maybe the tortured logic > finds unknown features a justification for declaring ext4dev? > Segrey, can you answer the question for F15? > Did you set FSTYP to ext4dev manually or did blkid identified it for you? > Amir, Fedora's fsck behaves differently on ext4dev and next4. When I made next4 partition on Fedora-15 by {{{ mkfs -t next4 /dev/sdd9 }}} it requires "export FSTYP=next4" to be defined and exported in local.conf. It mounts partition with {{{ mount -t next4 /dev/sdd9 /mnt/sdd9 }}} But on attempt to fsck it calls wrong fsck, as you reported: {{{ [seriv@pimbra xfstests]$ sudo fsck -t next4 /dev/sdd9 fsck from util-linux 2.19.1 e2fsck 1.41.14 (22-Dec-2010) /dev/sdd9 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7 e2fsck: Get a newer version of e2fsck! }}} And the problem can be easily traced to this wrong call: {{{ [seriv@pimbra xfstests]$ sudo strace -o /var/log/fsck.strace fsck -t next4 /dev/sdd9 fsck from util-linux 2.19.1 e2fsck 1.41.14 (22-Dec-2010) /dev/sdd9 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7 e2fsck: Get a newer version of e2fsck! [seriv@pimbra xfstests]$ grep sbin /var/log/fsck.strace execve("/sbin/fsck", ["fsck", "-t", "next4", "/dev/sdd9"], [/* 17 vars */]) = 0 stat("/sbin/fsck.ext4", {st_mode=S_IFREG|0755, st_size=194280, ...}) = 0 }}} But it's not the case for ext4dev, with it I even don't need "-t ext4dev", it is recognized by blkid: {{{ [seriv@pimbra xfstests]$ sudo mkfs -t ext4dev /dev/sdd9 mke2fs 1.41.14-next3-1.0.13-7 (24-May-2011) [skip] This filesystem will be automatically checked every 27 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. [seriv@pimbra xfstests]$ sudo mount /dev/sdd9 /mnt/sdd9 [seriv@pimbra xfstests]$ mount | grep sdd9 /dev/sdd9 on /mnt/sdd9 type ext4dev (rw) [seriv@pimbra xfstests]$ sudo umount /dev/sdd9 [seriv@pimbra xfstests]$ sudo fsck /dev/sdd9 fsck from util-linux 2.19.1 e2fsck 1.41.14-next3-1.0.13-7 (24-May-2011) The test_fs flag is set (and ext4 is available). Clear? }}} and at this point in another session {{{ [seriv@pimbra xfstests]$ pgrep -f -l fsck 4365 sudo fsck /dev/sdd9 4366 fsck /dev/sdd9 4367 fsck.ext4dev /dev/sdd9 }}} So I'd like this patch to be applied to xfstests to be able to use it on the different filesystems, - if not, then why have this FSTYP and not rely upon blkid -- Regards, Sergey Ivanov. --90e6ba6e822a99cba104a4a51871 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 1, 2011 at 2:37 AM, Amir Goldstein <amir73il@gmail.com> wrote:
On Wed, Jun 1, 2011 at 8:34 AM, Eric Sand= een <sandeen@redhat.com> wr= ote:
> On 6/1/11 12:22 AM, Eric Sandeen wrote:
>> On 5/31/11 11:56 PM, Amir Goldstein wrote:
>>> On Wed, Jun 1, 2011 at 7:37 AM, Eric Sandeen <sandeen@redhat.com> wrote:
>>>> On 5/31/11 10:13 PM, Amir Goldstein wrote:
>>>>> From: Amir Goldstein <amir73il@users.sf.net>
>>>>>
>>>>> blkid knows to identify the ext4dev FSTYP of a partiti= on that was
>>>>> formatted with mkfs.ext4dev.
>>>>> quota tools and various util-linux utils are also awar= e of ext4dev,
>>>>> so ext4dev shares the same capabilities as ext4.
>>>>>
>>>>> While testing on Fedora 15, we encoutered a buggy fsck= utility, which
>>>>> invokes fsck.ext4, even though it was called with -t e= xt4dev argument.
>>>>> In our setup fsck.ext4dev knows about new fs features = that fsck.ext4
>>>>> doesn't know, so the generic_fs_check fails.
>>>>> Since we have no real use of the extra capabilities pr= ovided by fsck util,
>>>>> we decided to invoke fsck.$FSTYP directly to avoid thi= s issue.
>>>>
>>>> Adding ext4dev to every case seems harmless enough. =C2=A0= TBH I thought I had
>>>> it there already but I guess not.
>>>>
>>>> I'm less certain of the change from fsck -t $FSTYP to = fsck.$FSTYP
>>>>
>>>> What issue are you avoiding? =C2=A0wouldn't fsck -t ex= t4dev invoke fsck.ext4dev anyway?
>>>>
>>>> It seems like it should be harmless, but I don't under= stand how it helps you.
>>>>
>>>
>>> As I wrote in the patch description, the fsck utility in Fedor= a 15 invokes
>>> fsck.ext4 for some reason when calling fsck -t ext4dev.
>>
>> Oh, right.
>>
>>> this fails because fsck.ext4 doesn't know the snapshot fea= ture.
>>> I didn't debug fsck utility for that. it seemed pointless.=
>>
>> Did you file a bug with Fedora? =C2=A0I'd rather fix the root = cause than work around it...
>> Feel free to cc: me on the bug.

No, I didn't file a bug.
In any case, it was Sergey, who tested and reported the problem on F15.

Would you agree to fix the problem in xfstests now, so that F15 users can test ext4dev and fix the bug in fsck regardless?

>
> RHEL6 does the same; mkfs.ext4dev then fsck -t ext4dev invokes fsck.ex= t4; but this
> is because blkid identifies it as ext4, not ext4dev, despite the test_= fs flag being set.
>
> ISTR this is due to some tortured logic about when ext4dev isn't e= xt4dev, but
> I don't remember the details... I don't know if this is the sa= me situation
> you're seeing; just to double check - does blkid correctly identif= y it as ext4dev
> on F15?


For me (on Ubuntu) blkid identifies ext4dev, but maybe the tortured l= ogic
finds unknown features a justification for declaring ext4dev?
Segrey, can you answer the question for F15?
Did you set FSTYP to ext4dev manually or did blkid identified it for you?

Amir, Fedora's fsck behaves differen= tly on ext4dev and next4. When I made next4 partition on Fedora-15 by=C2=A0=
{{{
mkfs =C2=A0-t next4 /dev/sdd9
}}}
it= requires "export FSTYP=3Dnext4" to be defined and exported in lo= cal.conf. It mounts partition with
{{{
mount -t next4 /= dev/sdd9 /mnt/sdd9
}}}
But on attempt to fsck it calls wrong fsck, as you repor= ted:
{{{
[seriv@pimbra xfstests]$ sudo fsck -t nex= t4 /dev/sdd9
fsck from util-linux 2.19.1
e2fsck 1.41.14= (22-Dec-2010)
/dev/sdd9 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7=
e2fsck: Get a newer version of e2fsck!
}}}
=

And the problem can be easily traced to this wrong call= :
{{{
[seriv@pimbra xfstests]$ sudo strace -o /var/log/fs= ck.strace fsck -t next4 /dev/sdd9 =C2=A0
fsck from util-linux 2.1= 9.1
e2fsck 1.41.14 (22-Dec-2010)
/dev/sdd9 has unsuppor= ted feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7
e2fsck: Get a newer version of e2fsck!
[seriv@pimbra xfstest= s]$ grep sbin /var/log/fsck.strace=C2=A0
execve("/sbin/fsck&= quot;, ["fsck", "-t", "next4", "/dev/sdd= 9"], [/* 17 vars */]) =3D 0
stat("/sbin/fsck.ext4", {st_mode=3DS_IFREG|0755, st_size=3D1= 94280, ...}) =3D 0
}}}

But it'= s not the case for ext4dev, with it I even don't need "-t ext4dev&= quot;, it is recognized by blkid:
{{{
[seriv@pimbra xfstests]$ sudo mkfs -t ext4dev /dev/= sdd9
mke2fs 1.41.14-next3-1.0.13-7 (24-May-2011)
[skip]=
This filesystem will be automatically checked every 27 mounts or=
180 days, whichever comes first. =C2=A0Use tune2fs -c or -i to overrid= e.
[seriv@pimbra xfstests]$ sudo mount /dev/sdd9 /mnt/sdd9
<= div>[seriv@pimbra xfstests]$ mount | grep sdd9
/dev/sdd9 on /mnt/= sdd9 type ext4dev (rw)
[seriv@pimbra xfstests]$ sudo umount /dev/sdd9
[seriv@pimbra= xfstests]$ sudo fsck /dev/sdd9
fsck from util-linux 2.19.1
=
e2fsck 1.41.14-next3-1.0.13-7 (24-May-2011)
The test_fs flag= is set (and ext4 is available). =C2=A0Clear<y>?=C2=A0
}}}
and at this point in another session
{{{=
[seriv@pimbra xfstests]$ pgrep -f -l fsck
4365 su= do fsck /dev/sdd9
4366 fsck /dev/sdd9
4367 fsck.ext4dev= /dev/sdd9
}}}

So I'd like this patch to be ap= plied to xfstests to be able to use it on the different filesystems, - if n= ot, then why have this FSTYP and not rely upon blkid
--=C2=A0
=C2=A0 Regards,
=C2=A0 =C2=A0Sergey Ivanov.

--90e6ba6e822a99cba104a4a51871-- From amir73il@gmail.com Wed Jun 1 07:37:30 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,FREEMAIL_FROM, J_CHICKENPOX_33,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51CbUpL119171 for ; Wed, 1 Jun 2011 07:37:30 -0500 X-ASG-Debug-ID: 1306931848-457202140000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ww0-f51.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5F559165CEF8 for ; Wed, 1 Jun 2011 05:37:28 -0700 (PDT) Received: from mail-ww0-f51.google.com (mail-ww0-f51.google.com [74.125.82.51]) by cuda.sgi.com with ESMTP id iqrr4EQi4dyka99s for ; Wed, 01 Jun 2011 05:37:28 -0700 (PDT) Received: by wwf26 with SMTP id 26so4723937wwf.32 for ; Wed, 01 Jun 2011 05:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QGBR4461jxECNyYrGrrJBirAF96e6rR2Vbj0+OS+ecU=; b=K6+fSztB2yZ6zrPf2ik3tKz3MgQO6O/+lcOHHG0zIBp7LqY/3Oaeap3OQNz8L4DR7m 9dUkCrA+tLLHBKRYmdrGu9UX/7h/NBb/S2+cYLN2PAQzgSEMIRtmTfKNeIujUh4zKvrO D5X2XisGNrK0OV8zV7yTuWLDotndjDljVKDjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BoNCc/qIbc1eDSwMUE6pz9bvTsihykYZnHx/LQeKu/+lJMUftJkNG9sGUZtUBZeHry PZUyJVulcZie3elmnWjs75YeoArl9fMh0cAhCBfGllhEgilILURwjPaJbs1uUrWVc5gF 7vLbJTP0g0+LmPvjzxgklCWo+XK8ZPGm1DS/8= MIME-Version: 1.0 Received: by 10.216.235.129 with SMTP id u1mr4670167weq.108.1306931847754; Wed, 01 Jun 2011 05:37:27 -0700 (PDT) Received: by 10.216.221.135 with HTTP; Wed, 1 Jun 2011 05:37:27 -0700 (PDT) In-Reply-To: References: <4DE5C1FE.8080006@redhat.com> <4DE5CC8E.1090208@redhat.com> <4DE5CF6C.4080707@redhat.com> Date: Wed, 1 Jun 2011 15:37:27 +0300 Message-ID: X-ASG-Orig-Subj: Re: [PATCH] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH] xfstests: add support for ext4dev FSTYP From: Amir Goldstein To: sergey ivanov Cc: Eric Sandeen , XFS , Ext4 Developers List , linux-fsdevel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-ww0-f51.google.com[74.125.82.51] X-Barracuda-Start-Time: 1306931849 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, DKIM_SIGNED, DKIM_VERIFIED, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65294 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Jun 1, 2011 at 2:48 PM, sergey ivanov wrote: > On Wed, Jun 1, 2011 at 2:37 AM, Amir Goldstein wrote= : >> >> On Wed, Jun 1, 2011 at 8:34 AM, Eric Sandeen wrote: >> > On 6/1/11 12:22 AM, Eric Sandeen wrote: >> >> On 5/31/11 11:56 PM, Amir Goldstein wrote: >> >>> On Wed, Jun 1, 2011 at 7:37 AM, Eric Sandeen >> >>> wrote: >> >>>> On 5/31/11 10:13 PM, Amir Goldstein wrote: >> >>>>> From: Amir Goldstein >> >>>>> >> >>>>> blkid knows to identify the ext4dev FSTYP of a partition that was >> >>>>> formatted with mkfs.ext4dev. >> >>>>> quota tools and various util-linux utils are also aware of ext4dev= , >> >>>>> so ext4dev shares the same capabilities as ext4. >> >>>>> >> >>>>> While testing on Fedora 15, we encoutered a buggy fsck utility, >> >>>>> which >> >>>>> invokes fsck.ext4, even though it was called with -t ext4dev >> >>>>> argument. >> >>>>> In our setup fsck.ext4dev knows about new fs features that fsck.ex= t4 >> >>>>> doesn't know, so the generic_fs_check fails. >> >>>>> Since we have no real use of the extra capabilities provided by fs= ck >> >>>>> util, >> >>>>> we decided to invoke fsck.$FSTYP directly to avoid this issue. >> >>>> >> >>>> Adding ext4dev to every case seems harmless enough. =A0TBH I though= t I >> >>>> had >> >>>> it there already but I guess not. >> >>>> >> >>>> I'm less certain of the change from fsck -t $FSTYP to fsck.$FSTYP >> >>>> >> >>>> What issue are you avoiding? =A0wouldn't fsck -t ext4dev invoke >> >>>> fsck.ext4dev anyway? >> >>>> >> >>>> It seems like it should be harmless, but I don't understand how it >> >>>> helps you. >> >>>> >> >>> >> >>> As I wrote in the patch description, the fsck utility in Fedora 15 >> >>> invokes >> >>> fsck.ext4 for some reason when calling fsck -t ext4dev. >> >> >> >> Oh, right. >> >> >> >>> this fails because fsck.ext4 doesn't know the snapshot feature. >> >>> I didn't debug fsck utility for that. it seemed pointless. >> >> >> >> Did you file a bug with Fedora? =A0I'd rather fix the root cause than >> >> work around it... >> >> Feel free to cc: me on the bug. >> >> No, I didn't file a bug. >> In any case, it was Sergey, who tested and reported the problem on F15. >> >> Would you agree to fix the problem in xfstests now, so that F15 users ca= n >> test ext4dev and fix the bug in fsck regardless? >> >> > >> > RHEL6 does the same; mkfs.ext4dev then fsck -t ext4dev invokes >> > fsck.ext4; but this >> > is because blkid identifies it as ext4, not ext4dev, despite the test_= fs >> > flag being set. >> > >> > ISTR this is due to some tortured logic about when ext4dev isn't >> > ext4dev, but >> > I don't remember the details... I don't know if this is the same >> > situation >> > you're seeing; just to double check - does blkid correctly identify it >> > as ext4dev >> > on F15? >> >> >> For me (on Ubuntu) blkid identifies ext4dev, but maybe the tortured logi= c >> finds unknown features a justification for declaring ext4dev? >> Segrey, can you answer the question for F15? >> Did you set FSTYP to ext4dev manually or did blkid identified it for you= ? > > Amir, Fedora's fsck behaves differently on ext4dev and next4. When I made > next4 partition on Fedora-15 by > {{{ > mkfs =A0-t next4 /dev/sdd9 > }}} > it requires "export FSTYP=3Dnext4" to be defined and exported in local.co= nf. > It mounts partition with > {{{ > mount -t next4 /dev/sdd9 /mnt/sdd9 > }}} > But on attempt to fsck it calls wrong fsck, as you reported: > {{{ > [seriv@pimbra xfstests]$ sudo fsck -t next4 /dev/sdd9 > fsck from util-linux 2.19.1 > e2fsck 1.41.14 (22-Dec-2010) > /dev/sdd9 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7 > e2fsck: Get a newer version of e2fsck! > }}} > And the problem can be easily traced to this wrong call: > {{{ > [seriv@pimbra xfstests]$ sudo strace -o /var/log/fsck.strace fsck -t next= 4 > /dev/sdd9 > fsck from util-linux 2.19.1 > e2fsck 1.41.14 (22-Dec-2010) > /dev/sdd9 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7 > e2fsck: Get a newer version of e2fsck! > [seriv@pimbra xfstests]$ grep sbin /var/log/fsck.strace > execve("/sbin/fsck", ["fsck", "-t", "next4", "/dev/sdd9"], [/* 17 vars */= ]) > =3D 0 > stat("/sbin/fsck.ext4", {st_mode=3DS_IFREG|0755, st_size=3D194280, ...}) = =3D 0 > }}} > But it's not the case for ext4dev, with it I even don't need "-t ext4dev"= , > it is recognized by blkid: > {{{ > [seriv@pimbra xfstests]$ sudo mkfs -t ext4dev /dev/sdd9 > mke2fs 1.41.14-next3-1.0.13-7 (24-May-2011) > [skip] > This filesystem will be automatically checked every 27 mounts or > 180 days, whichever comes first. =A0Use tune2fs -c or -i to override. > [seriv@pimbra xfstests]$ sudo mount /dev/sdd9 /mnt/sdd9 > [seriv@pimbra xfstests]$ mount | grep sdd9 > /dev/sdd9 on /mnt/sdd9 type ext4dev (rw) > [seriv@pimbra xfstests]$ sudo umount /dev/sdd9 > [seriv@pimbra xfstests]$ sudo fsck /dev/sdd9 > fsck from util-linux 2.19.1 > e2fsck 1.41.14-next3-1.0.13-7 (24-May-2011) > The test_fs flag is set (and ext4 is available). =A0Clear? > }}} > and at this point in another session > {{{ > [seriv@pimbra xfstests]$ pgrep -f -l fsck > 4365 sudo fsck /dev/sdd9 > 4366 fsck /dev/sdd9 > 4367 fsck.ext4dev /dev/sdd9 > }}} > So I'd like this patch to be applied to xfstests to be able to use it on = the > different filesystems, - if not, then why have this FSTYP and not rely up= on > blkid > -- To make a long story a bit shorter, there was no intention to set FSTYP manually, that was only a temporary hack to make next4 clone work, but since ext4dev = is identified by blkid and respected by fsck/mkfs/mount, we are going to work with it and not with next4. So I understood the problem incorrectly and the patch to xfstests doesn't n= eed to change fsck -t $FSTYP to fsck.$FSTYP. I will resend the patch without this change. Amir. From amir73il@gmail.com Wed Jun 1 07:57:25 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_62,J_CHICKENPOX_65,J_CHICKENPOX_66,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51CvOjW119862 for ; Wed, 1 Jun 2011 07:57:24 -0500 X-ASG-Debug-ID: 1306933043-023b02690000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ww0-f51.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 23FA24941BC for ; Wed, 1 Jun 2011 05:57:23 -0700 (PDT) Received: from mail-ww0-f51.google.com (mail-ww0-f51.google.com [74.125.82.51]) by cuda.sgi.com with ESMTP id zHgwu7lIBIkGILua for ; Wed, 01 Jun 2011 05:57:23 -0700 (PDT) Received: by wwf26 with SMTP id 26so4738908wwf.32 for ; Wed, 01 Jun 2011 05:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:from:to:cc:subject:date:message-id :x-mailer; bh=ELjjdNN3VFeOEBVQJlanuzFqbXmJvu3XZXR1OtdNPHE=; b=ZT0ephmGUXI6ELc3ncSBwciY8FD3rCA/M+1oE/WHvyAT8nnf5UG7m+E+LmN03K4hyp QczDCTLZ6diylPd1JpdGPqcyW1TfZ65ctg83t0WOWvO6dzq0iJpanRaq6GVlToVLcuvj 5ivq9R2LRXYEueFulOU0Yc7NLIfmSgwdy1ct4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:cc:subject:date:message-id:x-mailer; b=JAtbjen8FJrO6mVvmngOipdHrOfEZvn1LDmWxdj46swWDrWJjZ5JsbM7RHf2VE8ICf 9F8mgplFUAFq9eUf0pHuX7HqEzHejDDCx/+2cY6e3ZpYnrJTLxmZap59EaA66G8NkTbN VyHU39jVMvbZ+HZB9NihSRC9wUMnX2Af6eIH8= Received: by 10.216.82.6 with SMTP id n6mr4988044wee.27.1306933042892; Wed, 01 Jun 2011 05:57:22 -0700 (PDT) Received: from localhost.localdomain (bzq-218-153-66.cablep.bezeqint.net [81.218.153.66]) by mx.google.com with ESMTPS id w58sm620002weq.1.2011.06.01.05.57.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 05:57:22 -0700 (PDT) Sender: Amir Goldstein From: amir73il@users.sourceforge.net To: xfs@oss.sgi.com Cc: sandeen@redhat.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein X-ASG-Orig-Subj: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: [PATCH v2] xfstests: add support for ext4dev FSTYP Date: Wed, 1 Jun 2011 15:56:52 +0300 Message-Id: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> X-Mailer: git-send-email 1.7.4.1 X-Barracuda-Connect: mail-ww0-f51.google.com[74.125.82.51] X-Barracuda-Start-Time: 1306933044 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, MAILTO_TO_SPAM_ADDR, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65295 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Amir Goldstein From: Amir Goldstein blkid knows to identify the ext4dev FSTYP of a partition that was formatted with mkfs.ext4dev. quota tools and various util-linux utils are also aware of ext4dev, so ext4dev shares the same capabilities as ext4. Signed-off-by: Amir Goldstein Tested-by: Sergey Ivanov --- ext4dev is used to test experimental ext4 code in mutual existance with production ext4 code on the same system. Specifically, ext4 snapshots code is available for testing as a stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4 (see http://next3.sf.net). v1 -> v2: - undo change of fsck -t $FSTYP to fsck.$FSTYP common.defrag | 2 +- common.quota | 4 ++-- common.rc | 10 +++++----- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/common.defrag b/common.defrag index 1bcf01d..4850803 100644 --- a/common.defrag +++ b/common.defrag @@ -26,7 +26,7 @@ _require_defrag() xfs) DEFRAG_PROG=/usr/sbin/xfs_fsr ;; - ext4) + ext4|ext4dev) DEFRAG_PROG=/usr/bin/e4defrag ;; *) diff --git a/common.quota b/common.quota index 3c87ce1..b6d5f16 100644 --- a/common.quota +++ b/common.quota @@ -29,7 +29,7 @@ _require_quota() [ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed" case $FSTYP in - ext2|ext3|ext4|reiserfs) + ext2|ext3|ext4|ext4dev|reiserfs) if [ ! -d /proc/sys/fs/quota ]; then _notrun "Installed kernel does not support quotas" fi @@ -237,7 +237,7 @@ _check_quota_usage() # Sync to get delalloc to disk sync VFS_QUOTA=0 - if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "reiserfs" ]; then + if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "ext4dev" -o $FSTYP = "reiserfs" ]; then VFS_QUOTA=1 quotaon -f -u -g $SCRATCH_MNT 2>/dev/null fi diff --git a/common.rc b/common.rc index e634fbb..c510c66 100644 --- a/common.rc +++ b/common.rc @@ -65,7 +65,7 @@ _mount_opts() nfs) export MOUNT_OPTIONS=$NFS_MOUNT_OPTIONS ;; - ext2|ext3|ext4) + ext2|ext3|ext4|ext4dev) # acls & xattrs aren't turned on by default on ext$FOO export MOUNT_OPTIONS="-o acl,user_xattr $EXT_MOUNT_OPTIONS" ;; @@ -110,7 +110,7 @@ _mkfs_opts() _fsck_opts() { case $FSTYP in - ext2|ext3|ext4) + ext2|ext3|ext4|ext4dev) export FSCK_OPTIONS="-nf" ;; reiserfs) @@ -326,10 +326,10 @@ _scratch_mkfs_sized() xfs) _scratch_mkfs_xfs -d size=$fssize -b size=$blocksize ;; - ext2|ext3|ext4) + ext2|ext3|ext4|ext4dev) /sbin/mkfs.$FSTYP $MKFS_OPTIONS -b $blocksize $SCRATCH_DEV $blocks ;; - btrfs) + btrfs) /sbin/mkfs.$FSTYP $MKFS_OPTIONS $SCRATCH_DEV -b $fssize ;; *) @@ -354,7 +354,7 @@ _scratch_mkfs_geom() xfs) MKFS_OPTIONS+=" -b size=$blocksize, -d su=$sunit_bytes,sw=$swidth_mult" ;; - ext4) + ext4|ext4dev) MKFS_OPTIONS+=" -b $blocksize -E stride=$sunit_blocks,stripe_width=$swidth_blocks" ;; *) -- 1.7.4.1 From sandeen@redhat.com Wed Jun 1 10:28:01 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51FS1W8126806 for ; Wed, 1 Jun 2011 10:28:01 -0500 X-ASG-Debug-ID: 1306942080-2c9b01280000-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 2C1511ED18B3 for ; Wed, 1 Jun 2011 08:28:00 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id mAlVGc6JuRQKwgU2 for ; Wed, 01 Jun 2011 08:28:00 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p51FRw5m027840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2011 11:27:58 -0400 Received: from liberator.sandeen.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p51FRumb023564 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 11:27:57 -0400 Message-ID: <4DE65A7C.7070908@redhat.com> Date: Wed, 01 Jun 2011 10:27:56 -0500 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Amir Goldstein CC: sergey ivanov , XFS , Ext4 Developers List , linux-fsdevel X-ASG-Orig-Subj: Re: [PATCH] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH] xfstests: add support for ext4dev FSTYP References: <4DE5C1FE.8080006@redhat.com> <4DE5CC8E.1090208@redhat.com> <4DE5CF6C.4080707@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1306942081 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/1/11 7:37 AM, Amir Goldstein wrote: > On Wed, Jun 1, 2011 at 2:48 PM, sergey ivanov wrote: >> On Wed, Jun 1, 2011 at 2:37 AM, Amir Goldstein wrote: >>> >>> On Wed, Jun 1, 2011 at 8:34 AM, Eric Sandeen wrote: >>>> On 6/1/11 12:22 AM, Eric Sandeen wrote: >>>>> On 5/31/11 11:56 PM, Amir Goldstein wrote: >>>>>> On Wed, Jun 1, 2011 at 7:37 AM, Eric Sandeen >>>>>> wrote: >>>>>>> On 5/31/11 10:13 PM, Amir Goldstein wrote: >>>>>>>> From: Amir Goldstein >>>>>>>> >>>>>>>> blkid knows to identify the ext4dev FSTYP of a partition that was >>>>>>>> formatted with mkfs.ext4dev. >>>>>>>> quota tools and various util-linux utils are also aware of ext4dev, >>>>>>>> so ext4dev shares the same capabilities as ext4. >>>>>>>> >>>>>>>> While testing on Fedora 15, we encoutered a buggy fsck utility, >>>>>>>> which >>>>>>>> invokes fsck.ext4, even though it was called with -t ext4dev >>>>>>>> argument. >>>>>>>> In our setup fsck.ext4dev knows about new fs features that fsck.ext4 >>>>>>>> doesn't know, so the generic_fs_check fails. >>>>>>>> Since we have no real use of the extra capabilities provided by fsck >>>>>>>> util, >>>>>>>> we decided to invoke fsck.$FSTYP directly to avoid this issue. >>>>>>> >>>>>>> Adding ext4dev to every case seems harmless enough. TBH I thought I >>>>>>> had >>>>>>> it there already but I guess not. >>>>>>> >>>>>>> I'm less certain of the change from fsck -t $FSTYP to fsck.$FSTYP >>>>>>> >>>>>>> What issue are you avoiding? wouldn't fsck -t ext4dev invoke >>>>>>> fsck.ext4dev anyway? >>>>>>> >>>>>>> It seems like it should be harmless, but I don't understand how it >>>>>>> helps you. >>>>>>> >>>>>> >>>>>> As I wrote in the patch description, the fsck utility in Fedora 15 >>>>>> invokes >>>>>> fsck.ext4 for some reason when calling fsck -t ext4dev. >>>>> >>>>> Oh, right. >>>>> >>>>>> this fails because fsck.ext4 doesn't know the snapshot feature. >>>>>> I didn't debug fsck utility for that. it seemed pointless. >>>>> >>>>> Did you file a bug with Fedora? I'd rather fix the root cause than >>>>> work around it... >>>>> Feel free to cc: me on the bug. >>> >>> No, I didn't file a bug. >>> In any case, it was Sergey, who tested and reported the problem on F15. >>> >>> Would you agree to fix the problem in xfstests now, so that F15 users can >>> test ext4dev and fix the bug in fsck regardless? >>> >>>> >>>> RHEL6 does the same; mkfs.ext4dev then fsck -t ext4dev invokes >>>> fsck.ext4; but this >>>> is because blkid identifies it as ext4, not ext4dev, despite the test_fs >>>> flag being set. >>>> >>>> ISTR this is due to some tortured logic about when ext4dev isn't >>>> ext4dev, but >>>> I don't remember the details... I don't know if this is the same >>>> situation >>>> you're seeing; just to double check - does blkid correctly identify it >>>> as ext4dev >>>> on F15? >>> >>> >>> For me (on Ubuntu) blkid identifies ext4dev, but maybe the tortured logic >>> finds unknown features a justification for declaring ext4dev? >>> Segrey, can you answer the question for F15? >>> Did you set FSTYP to ext4dev manually or did blkid identified it for you? >> >> Amir, Fedora's fsck behaves differently on ext4dev and next4. When I made >> next4 partition on Fedora-15 by >> {{{ >> mkfs -t next4 /dev/sdd9 >> }}} >> it requires "export FSTYP=next4" to be defined and exported in local.conf. >> It mounts partition with >> {{{ >> mount -t next4 /dev/sdd9 /mnt/sdd9 >> }}} >> But on attempt to fsck it calls wrong fsck, as you reported: >> {{{ >> [seriv@pimbra xfstests]$ sudo fsck -t next4 /dev/sdd9 >> fsck from util-linux 2.19.1 >> e2fsck 1.41.14 (22-Dec-2010) >> /dev/sdd9 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7 >> e2fsck: Get a newer version of e2fsck! >> }}} >> And the problem can be easily traced to this wrong call: >> {{{ >> [seriv@pimbra xfstests]$ sudo strace -o /var/log/fsck.strace fsck -t next4 >> /dev/sdd9 >> fsck from util-linux 2.19.1 >> e2fsck 1.41.14 (22-Dec-2010) >> /dev/sdd9 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7 >> e2fsck: Get a newer version of e2fsck! >> [seriv@pimbra xfstests]$ grep sbin /var/log/fsck.strace >> execve("/sbin/fsck", ["fsck", "-t", "next4", "/dev/sdd9"], [/* 17 vars */]) >> = 0 >> stat("/sbin/fsck.ext4", {st_mode=S_IFREG|0755, st_size=194280, ...}) = 0 >> }}} >> But it's not the case for ext4dev, with it I even don't need "-t ext4dev", >> it is recognized by blkid: >> {{{ >> [seriv@pimbra xfstests]$ sudo mkfs -t ext4dev /dev/sdd9 >> mke2fs 1.41.14-next3-1.0.13-7 (24-May-2011) >> [skip] >> This filesystem will be automatically checked every 27 mounts or >> 180 days, whichever comes first. Use tune2fs -c or -i to override. >> [seriv@pimbra xfstests]$ sudo mount /dev/sdd9 /mnt/sdd9 >> [seriv@pimbra xfstests]$ mount | grep sdd9 >> /dev/sdd9 on /mnt/sdd9 type ext4dev (rw) >> [seriv@pimbra xfstests]$ sudo umount /dev/sdd9 >> [seriv@pimbra xfstests]$ sudo fsck /dev/sdd9 >> fsck from util-linux 2.19.1 >> e2fsck 1.41.14-next3-1.0.13-7 (24-May-2011) >> The test_fs flag is set (and ext4 is available). Clear? >> }}} >> and at this point in another session >> {{{ >> [seriv@pimbra xfstests]$ pgrep -f -l fsck >> 4365 sudo fsck /dev/sdd9 >> 4366 fsck /dev/sdd9 >> 4367 fsck.ext4dev /dev/sdd9 >> }}} >> So I'd like this patch to be applied to xfstests to be able to use it on the >> different filesystems, - if not, then why have this FSTYP and not rely upon >> blkid >> -- > > To make a long story a bit shorter, there was no intention to set > FSTYP manually, > that was only a temporary hack to make next4 clone work, but since ext4dev is > identified by blkid and respected by fsck/mkfs/mount, we are going to > work with it > and not with next4. > > So I understood the problem incorrectly and the patch to xfstests doesn't need > to change fsck -t $FSTYP to fsck.$FSTYP. > I will resend the patch without this change. Thanks, that makes sense to me. Just wanted to make sure we weren't masking some other problem by working around it in xfstests ... -Eric > Amir. From achender@linux.vnet.ibm.com Wed Jun 1 15:51:00 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51KoxdQ146012 for ; Wed, 1 Jun 2011 15:51:00 -0500 X-ASG-Debug-ID: 1306961458-5bf9031f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e9.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1786C1ED2D7B for ; Wed, 1 Jun 2011 13:50:58 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by cuda.sgi.com with ESMTP id xgbvrNczFa6FguFY for ; Wed, 01 Jun 2011 13:50:58 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p51KKobW007453 for ; Wed, 1 Jun 2011 16:20:50 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p51KotAW063100 for ; Wed, 1 Jun 2011 16:50:55 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p51KosQv009814 for ; Wed, 1 Jun 2011 16:50:55 -0400 Received: from [9.48.102.246] (sig-9-48-102-246.mts.ibm.com [9.48.102.246]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p51KooDo009584; Wed, 1 Jun 2011 16:50:51 -0400 Message-ID: <4DE6A621.7040206@linux.vnet.ibm.com> Date: Wed, 01 Jun 2011 13:50:41 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Yongqiang Yang CC: Ext4 Developers List , xfs-oss , Dave Chinner , "Ted Ts'o" X-ASG-Orig-Subj: Re: xfsprogs: Fix for xfstest 252 hang on ext4 Subject: Re: xfsprogs: Fix for xfstest 252 hang on ext4 References: <4DDAC4EF.1050702@linux.vnet.ibm.com> <4DDB1A0C.5030502@linux.vnet.ibm.com> <4DE50881.90401@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Barracuda-Connect: e9.ny.us.ibm.com[32.97.182.139] X-Barracuda-Start-Time: 1306961459 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 5/31/2011 6:58 PM, Yongqiang Yang wrote: > On Tue, May 31, 2011 at 11:25 PM, Allison Henderson > wrote: >> On 5/23/2011 7:38 PM, Allison Henderson wrote: >>> >>> On 5/23/2011 6:16 PM, Yongqiang Yang wrote: >>>> >>>> On Tue, May 24, 2011 at 4:34 AM, Allison Henderson >>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> While trying to add more punch hole tests to xfstest, I found that >>>>> test 252 hangs on ext4 due to a loop in xfsprogs that does not exit. >>>>> XFS gets out of this loop because there is logic in the loop that >>>>> looks for the last extent flag and breaks out. But it looks like ext4 >>>>> does not return a last extent when the file has a hole at the end. I >>>>> am not sure if this is the correct behavior or not, so I will copy >>>>> the ext4 folks on this too. Below is a copy of the fix for xfsprogs: >>>> >>>> Hi there, >>>> >>>> What's blocksize of the tested ext4? For now, ext4 returns >>>> LAST_EXTENT if the logical offset covered by the extent is greater >>>> than file size, so if there is a hole at the end, no last extent is >>>> returned. Thx! >>>> >>>> Yongqiang. >>> >>> Hi there, >>> >>> The block size I've been using is 4096. As long as that behavior is >>> expected, I think the test will be ok with just the xfsprogs fix, >>> though. Thx! >>> >>> Allison Henderson >>> >>>> >>>>> >>>>> diff --git a/io/fiemap.c b/io/fiemap.c >>>>> index fa990cc..81fc92c 100644 >>>>> --- a/io/fiemap.c >>>>> +++ b/io/fiemap.c >>>>> @@ -246,7 +246,7 @@ fiemap_f( >>>>> flg_w, _("FLAGS")); >>>>> } >>>>> >>>>> - while (!last&& ((cur_extent + 1) != max_extents)) { >>>>> + while (!last&& (cur_extent<= max_extents)) { >>>>> if (max_extents) >>>>> num_extents = min(num_extents, >>>>> max_extents - (cur_extent + 1)); >>>>> >>>>> >>>>> It looks like the loop enters with last=0, cur_extents=0, and >>>>> max_extents = 0, and on the first iteration cur_extents get set to 2, >>>>> so we dont see ((cur_extent + 1) == max_extents for a very long time. >>>>> I doubt the logic was meant to work that way, so this patch should >>>>> fix it, but I wanted to make sure that the fiemap for ext4 is working >>>>> as intended too. Feed back appreciated! Thx all! >>>>> >>>>> Allison Henderson >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in >>>>> the body of a message to majordomo@vger.kernel.org >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>> >>>> >>>> >>>> >>> >> >> >>>> Hi all, >>>> >>>> I haven't heard much back on this patch, so Im just poking this >>>> thread to make sure it doesn't get forgotten. I have some patches >>>> out there for punch hole, and I'm currently looking at fixing up >>>> some older punch hole tests in the dmapi code, but they wont do much >>>> good for ext4 with out this fix. If I could get a quick peek from >>>> some one on the xfs list for this patch, that would be much >>>> appreciated. Thx all! >>> >>> If ext4 is not setting the last extent flag on the last extent then >>> that's an ext4 bug that the test has detected, right? And so you >>> should be fixing ext4 rather than modifying the test to hide the >>> different behaviour? >>> >>> Cheer >>> >>> -- Dave Chinner david@fromorbit.com >> >> Hi All, >> >> Sorry, I should have poked the thread with Yongqiang's response, so I will >> move the dialog into this thread. At the moment, it sounds like the fiemap >> for ext4 is working as intended. Yongqiang, do you agree that the fiemap >> for ext4 should be changed? I think you are more familiar with this part of > Yes, I agree. ext4 should return LAST extent. I am thinking if we > can find a new solution collecting extents. > > Maybe we can insert delayed extents into extent tree. This way fiemap > will be simpler and much more efficient. > > I would like to throw out the proposal inserting delayed-extents into > extent tree. What will it bring? AFAIK it will bring: > 1. We need to down i_data_sem in delayed write-path to insert > delayed-extents into the tree without journaling it. > > 2. When we come to block allocation, we can convert delayed-extents to > normal extents. > > There is a problem that the solution can be only used in ordered mode. > So what are your opinions？ > > Yongqiang. Hi All, Well, I am not yet familiar with how the code for ordered mode works, so I may not be much help here, but I do think that if we could get it to work, it would help simplify a lot of things including fiemap and punch hole. I know that the earlier versions of punch hole were a little complicated because of the different mechanisms needed to identify mapped extents, delayed extents and holes. Eventually what we did was to flush out the data in the region to be punched out in order to avoid race conditions, and also to simplify the logic. This has introduced some problems in some of the existing xfstests punch hole tests, because the tests want to see a hole in unwritten extents instead of written extents. I was working on some optimization patches to avoid this, but if this proposal is put in place, I think I could optimize that fix a lot. And I know the fiemap routines would get simpler sense they would only have to deal with the extent tree. If we decide to do what you propose, I will wait on doing any punch hole or fiemap patches to take advantage of that. I'll poke around with the modes too to see if there's any thing we can do to get around that problem. Thx! Allison Henderson > >> the code than I am, and I just want to make sure we find a solution that >> everyone is happy with. Thx! >> >> Allison Henderson >> >> >> >> >> >>> _______________________________________________ >>> xfs mailing list >>> xfs@oss.sgi.com >>> http://oss.sgi.com/mailman/listinfo/xfs >> >> > > > From achender@linux.vnet.ibm.com Wed Jun 1 18:01:32 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_64,J_CHICKENPOX_66,J_CHICKENPOX_92 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51N1VS5153963 for ; Wed, 1 Jun 2011 18:01:32 -0500 X-ASG-Debug-ID: 1306969290-09e401a00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e2.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1D1B8D6CC77 for ; Wed, 1 Jun 2011 16:01:30 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by cuda.sgi.com with ESMTP id BojHjC2MrIrffuhY for ; Wed, 01 Jun 2011 16:01:30 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p51MfJ8M005305 for ; Wed, 1 Jun 2011 18:41:19 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p51N1T161413218 for ; Wed, 1 Jun 2011 19:01:29 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p51N1TFN004151 for ; Wed, 1 Jun 2011 19:01:29 -0400 Received: from [9.48.102.246] (sig-9-48-102-246.mts.ibm.com [9.48.102.246]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p51N1S0f004044; Wed, 1 Jun 2011 19:01:28 -0400 Message-ID: <4DE6C4BE.5030805@linux.vnet.ibm.com> Date: Wed, 01 Jun 2011 16:01:18 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: xfs-oss CC: Dave Chinner X-ASG-Orig-Subj: Re: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX Subject: Re: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX References: <4DDDBC34.7050809@linux.vnet.ibm.com> In-Reply-To: <4DDDBC34.7050809@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e2.ny.us.ibm.com[32.97.182.142] X-Barracuda-Start-Time: 1306969291 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 5/25/2011 7:34 PM, Allison Henderson wrote: > This patch adds punch hole tests to the fsx stress test. > > Signed-off-by: Allison Henderson > > v1 -> v2: > Corrections to the Makefile have been backed out. > Those corrections have been addressed in the > "xfstests: clean up fallocate configuration tests" > patch > > The punch hole tests can be disabled with the > -H flag, and will also be disabled if it is > detected that the filesystem does not support > punch hole > > v2 -> v4 > Punch hole tests and functionality tests have been moved > into their own functions. Existing dofallocate routine > has been renamed to do_preallocate. > --- > :100644 100755 fe072d3... a55b6f7... M ltp/fsx.c > ltp/fsx.c | 140 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------- > 1 files changed, 122 insertions(+), 18 deletions(-) > > diff --git a/ltp/fsx.c b/ltp/fsx.c > old mode 100644 > new mode 100755 > index fe072d3..a55b6f7 > --- a/ltp/fsx.c > +++ b/ltp/fsx.c > @@ -69,6 +69,7 @@ int logcount = 0; /* total ops */ > #define OP_MAPWRITE 6 > #define OP_SKIPPED 7 > #define OP_FALLOCATE 8 > +#define OP_PUNCH_HOLE 9 > > #undef PAGE_SIZE > #define PAGE_SIZE getpagesize() > @@ -110,6 +111,7 @@ int randomoplen = 1; /* -O flag disables it */ > int seed = 1; /* -S flag */ > int mapped_writes = 1; /* -W flag disables */ > int fallocate_calls = 1; /* -F flag disables */ > +int punch_hole_calls = 1; /* -H flag disables */ > int mapped_reads = 1; /* -R flag disables it */ > int fsxgoodfd = 0; > int o_direct; /* -Z */ > @@ -279,6 +281,14 @@ logdump(void) > badoff< lp->args[0] + lp->args[1]) > prt("\t******FFFF"); > break; > + case OP_PUNCH_HOLE: > + prt("PUNCH HOLE\t0x%x thru 0x%x\t(0x%x bytes)", > + lp->args[0], lp->args[0] + lp->args[1] - 1, > + lp->args[1]); > + if (badoff>= lp->args[0]&& badoff< > + lp->args[0] + lp->args[1]) > + prt("\t******PPPP"); > + break; > case OP_SKIPPED: > prt("SKIPPED (no operation)"); > break; > @@ -784,10 +794,67 @@ dotruncate(unsigned size) > } > } > > +#ifdef FALLOC_FL_PUNCH_HOLE > +void > +do_punch_hole(unsigned offset, unsigned length) > +{ > + unsigned end_offset; > + int max_offset = 0; > + int max_len = 0; > + int mode = FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE; > + > + if (length == 0) { > + if (!quiet&& testcalls> simulatedopcount) > + prt("skipping zero length punch hole\n"); > + log4(OP_SKIPPED, OP_PUNCH_HOLE, offset, length); > + return; > + } > + > + if (file_size<= (loff_t)offset) { > + if (!quiet&& testcalls> simulatedopcount) > + prt("skipping hole punch off the end of the file\n"); > + log4(OP_SKIPPED, OP_PUNCH_HOLE, offset, length); > + return; > + } > + > + end_offset = offset + length; > + > + log4(OP_PUNCH_HOLE, offset, length, 0); > + > + if (testcalls<= simulatedopcount) > + return; > + > + if ((progressinterval&& testcalls % progressinterval == 0) || > + (debug&& (monitorstart == -1 || monitorend == -1 || > + end_offset<= monitorend))) { > + prt("%lu punch\tfrom 0x%x to 0x%x, (0x%x bytes)\n", testcalls, > + offset, offset+length, length); > + } > + if (fallocate(fd, mode, (loff_t)offset, (loff_t)length) == -1) { > + prt("%punch hole: %x to %x\n", offset, length); > + prterr("do_punch_hole: fallocate"); > + report_failure(161); > + } > + > + > + max_offset = offset< file_size ? offset : file_size; > + max_len = max_offset + length<= file_size ? length : > + file_size - max_offset; > + memset(good_buf + max_offset, '\0', max_len); > +} > + > +#else > +void > +do_punch_hole(unsigned offset, unsigned length) > +{ > + return; > +} > +#endif > + > #ifdef FALLOCATE > /* fallocate is basically a no-op unless extending, then a lot like a truncate */ > void > -dofallocate(unsigned offset, unsigned length) > +do_preallocate(unsigned offset, unsigned length) > { > unsigned end_offset; > int keep_size; > @@ -831,13 +898,13 @@ dofallocate(unsigned offset, unsigned length) > prt("%lu falloc\tfrom 0x%x to 0x%x\n", testcalls, offset, length); > if (fallocate(fd, keep_size ? FALLOC_FL_KEEP_SIZE : 0, (loff_t)offset, (loff_t)length) == -1) { > prt("fallocate: %x to %x\n", offset, length); > - prterr("dofallocate: fallocate"); > + prterr("do_preallocate: fallocate"); > report_failure(161); > } > } > #else > void > -dofallocate(unsigned offset, unsigned length) > +do_preallocate(unsigned offset, unsigned length) > { > return; > } > @@ -895,8 +962,7 @@ test(void) > unsigned long offset; > unsigned long size = maxoplen; > unsigned long rv = random(); > - unsigned long op = rv % (3 + !lite + mapped_writes + fallocate_calls); > - > + unsigned long op = rv % (3 + !lite + mapped_writes + fallocate_calls + punch_hole_calls); > /* turn off the map read if necessary */ > > if (op == 2&& !mapped_reads) > @@ -924,6 +990,7 @@ test(void) > * TRUNCATE: op = - 3 > * MAPWRITE: op = 3 4 > * FALLOCATE: op = - 5 > + * PUNCH HOLE: op = - 6 > */ > if (lite ? 0 : op == 3&& (style& 1) == 0) /* vanilla truncate? */ > dotruncate(random() % maxfilelen); > @@ -941,7 +1008,12 @@ test(void) > offset %= maxfilelen; > if (offset + size> maxfilelen) > size = maxfilelen - offset; > - dofallocate(offset, size); > + do_preallocate(offset, size); > + } else if (op == 6) { > + offset %= maxfilelen; > + if (offset + size> maxfilelen) > + size = maxfilelen - offset; > + do_punch_hole(offset, size); > } else if (op == 1 || op == (lite ? 3 : 4)) { > /* write / mapwrite */ > offset %= maxfilelen; > @@ -1013,6 +1085,9 @@ usage(void) > #ifdef FALLOCATE > " -F: Do not use fallocate (preallocation) calls\n" > #endif > +#ifdef FALLOC_FL_PUNCH_HOLE > +" -H: Do not use punch hole calls\n" > +#endif > " -L: fsxLite - no file creations& no file size changes\n\ > -N numops: total # operations to do (default infinity)\n\ > -O: use oplen (see -o flag) for every op (default random)\n\ > @@ -1161,6 +1236,41 @@ int aio_rw(int rw, int fd, char *buf, unsigned len, unsigned offset) > > #endif > > +void > +test_fallocate() > +{ > +#ifdef FALLOCATE > + if (!lite&& fallocate_calls) { > + if (fallocate(fd, 0, 0, 1)&& errno == EOPNOTSUPP) { > + warn("main: filesystem does not support fallocate, disabling"); > + fallocate_calls = 0; > + } else { > + ftruncate(fd, 0); > + } > + } > +#else /* ! FALLOCATE */ > + fallocate_calls = 0; > +#endif > +} > + > +void > +test_punch_hole() > +{ > +#ifdef FALLOC_FL_PUNCH_HOLE > + if (!lite&& punch_hole_calls) { > + if (fallocate(fd, 0, 0, > + FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE)&& > + errno == EOPNOTSUPP) { > + > + warn("main: filesystem does not support fallocate punch hole, disabling"); > + punch_hole_calls = 0; > + } > + } > +#else /* ! PUNCH HOLE */ > + punch_hole_calls = 0; > +#endif > +} > + > int > main(int argc, char **argv) > { > @@ -1179,7 +1289,7 @@ main(int argc, char **argv) > > setvbuf(stdout, (char *)0, _IOLBF, 0); /* line buffered stdout */ > > - while ((ch = getopt(argc, argv, "b:c:dfl:m:no:p:qr:s:t:w:xyAD:FLN:OP:RS:WZ")) > + while ((ch = getopt(argc, argv, "b:c:dfl:m:no:p:qr:s:t:w:xyAD:FHLN:OP:RS:WZ")) > != EOF) > switch (ch) { > case 'b': > @@ -1276,6 +1386,9 @@ main(int argc, char **argv) > case 'F': > fallocate_calls = 0; > break; > + case 'H': > + punch_hole_calls = 0; > + break; > case 'L': > lite = 1; > break; > @@ -1421,17 +1534,8 @@ main(int argc, char **argv) > } else > check_trunc_hack(); > > -#ifdef FALLOCATE > - if (!lite&& fallocate_calls) { > - if (fallocate(fd, 0, 0, 1)&& errno == EOPNOTSUPP) { > - warn("main: filesystem does not support fallocate, disabling"); > - fallocate_calls = 0; > - } else > - ftruncate(fd, 0); > - } > -#else /* ! FALLOCATE */ > - fallocate_calls = 0; > -#endif > + test_fallocate(); > + test_punch_hole(); > > while (numops == -1 || numops--) > test(); Hi all, I just wanted to poke this patch set before too much time gets away. Most of the changes that happened between v3 and v4 were discussed in the previous threads. I updated my xfstest recently and noticed that some activity in this code has caused the patch not to apply, so I may need to send out an update, but if anyone has any more comments please let me know so I can add them in. Thx! Allison Henderson From achender@linux.vnet.ibm.com Wed Jun 1 18:01:54 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_65 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51N1sNK153994 for ; Wed, 1 Jun 2011 18:01:54 -0500 X-ASG-Debug-ID: 1306969313-7b7d021d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e9.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5A5111ED3430 for ; Wed, 1 Jun 2011 16:01:53 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by cuda.sgi.com with ESMTP id 8cxwErIPug7enW9K for ; Wed, 01 Jun 2011 16:01:53 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p51MVlpG024507 for ; Wed, 1 Jun 2011 18:31:47 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p51N1raG118424 for ; Wed, 1 Jun 2011 19:01:53 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p51N1qvA005731 for ; Wed, 1 Jun 2011 19:01:53 -0400 Received: from [9.48.102.246] (sig-9-48-102-246.mts.ibm.com [9.48.102.246]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p51N1pwP005695; Wed, 1 Jun 2011 19:01:52 -0400 Message-ID: <4DE6C4D6.9080305@linux.vnet.ibm.com> Date: Wed, 01 Jun 2011 16:01:42 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: xfs-oss CC: Dave Chinner X-ASG-Orig-Subj: Re: [XFSTEST Add Fallocate Punch Hole Tests 2/3 v4] Expand 252 punch hole test to cover additional corner cases Subject: Re: [XFSTEST Add Fallocate Punch Hole Tests 2/3 v4] Expand 252 punch hole test to cover additional corner cases References: <4DDDBC3F.9080704@linux.vnet.ibm.com> In-Reply-To: <4DDDBC3F.9080704@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e9.ny.us.ibm.com[32.97.182.139] X-Barracuda-Start-Time: 1306969314 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 5/25/2011 7:34 PM, Allison Henderson wrote: > This patch adds additional punch hole tests to 252 > that were used to test ext4 punch hole. The _test_generic_punch > routine has been modified to accept two new flags: > > -k To keep the test file between tests. > This will test the handling of existing holes > > -d To not sync the file between tests. > This will test the handling of delayed extents > > Four new corner cases have also been added to the routine: > 14. data -> hole @ EOF > 15. data -> hole @ 0 > 16. data -> cache cold ->hole > 17. data -> hole in single block file > > > Signed-off-by: Allison Henderson > > --- > :100755 100755 dfdf3f8... 5efa243... M 252 > :100644 100644 cd8e4b4... 930c924... M 252.out > :100644 100644 e2da5d8... ddf63b0... M common.punch > 252 | 10 +++ > 252.out | 192 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > common.punch | 150 ++++++++++++++++++++++++++++++++++++++------- > 3 files changed, 330 insertions(+), 22 deletions(-) > > diff --git a/252 b/252 > index dfdf3f8..5efa243 100755 > --- a/252 > +++ b/252 > @@ -52,6 +52,16 @@ _require_xfs_io_fiemap > > testfile=$TEST_DIR/252.$$ > > +# Standard punch hole tests > _test_generic_punch falloc fpunch fpunch fiemap _filter_fiemap $testfile -F > > +# Delayed allocation punch hole tests > +_test_generic_punch -d falloc fpunch fpunch fiemap _filter_fiemap $testfile -F > + > +# Multi hole punch tests > +_test_generic_punch -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F > + > +# Delayed allocation multi punch hole tests > +_test_generic_punch -d -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F > + > status=0 ; exit > diff --git a/252.out b/252.out > index cd8e4b4..930c924 100644 > --- a/252.out > +++ b/252.out > @@ -45,3 +45,195 @@ QA output created by 252 > 0: [0..7]: data > 1: [8..31]: hole > 2: [32..39]: data > + 14. data -> hole @ EOF > +0: [0..23]: data > +1: [24..39]: hole > + 15. data -> hole @ 0 > +0: [0..15]: hole > +1: [16..39]: data > + 16. data -> cache cold ->hole > +0: [0..15]: hole > +1: [16..39]: data > + 17. data -> hole in single block file > +0: [0..7]: data > + 1. into a hole > + 2. into allocated space > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 3. into unwritten space > +0: [0..7]: unwritten > +1: [8..23]: hole > +2: [24..39]: unwritten > + 4. hole -> data > +0: [0..23]: hole > +1: [24..31]: data > +2: [32..39]: hole > + 5. hole -> unwritten > +0: [0..23]: hole > +1: [24..31]: unwritten > +2: [32..39]: hole > + 6. data -> hole > +0: [0..7]: data > +1: [8..39]: hole > + 7. data -> unwritten > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..31]: unwritten > +3: [32..39]: hole > + 8. unwritten -> hole > +0: [0..7]: unwritten > +1: [8..39]: hole > + 9. unwritten -> data > +0: [0..7]: unwritten > +1: [8..23]: hole > +2: [24..31]: data > +3: [32..39]: hole > + 10. hole -> data -> hole > + 11. data -> hole -> data > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 12. unwritten -> data -> unwritten > +0: [0..7]: unwritten > +1: [8..31]: hole > +2: [32..39]: unwritten > + 13. data -> unwritten -> data > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 14. data -> hole @ EOF > +0: [0..23]: data > +1: [24..39]: hole > + 15. data -> hole @ 0 > +0: [0..15]: hole > +1: [16..39]: data > + 16. data -> cache cold ->hole > +0: [0..15]: hole > +1: [16..39]: data > + 17. data -> hole in single block file > +0: [0..7]: data > + 1. into a hole > +0: [0..7]: data > +1: [8..39]: hole > + 2. into allocated space > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 3. into unwritten space > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 4. hole -> data > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 5. hole -> unwritten > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 6. data -> hole > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 7. data -> unwritten > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 8. unwritten -> hole > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 9. unwritten -> data > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 10. hole -> data -> hole > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 11. data -> hole -> data > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 12. unwritten -> data -> unwritten > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 13. data -> unwritten -> data > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 14. data -> hole @ EOF > +0: [0..23]: data > +1: [24..39]: hole > + 15. data -> hole @ 0 > +0: [0..15]: hole > +1: [16..39]: data > + 16. data -> cache cold ->hole > +0: [0..15]: hole > +1: [16..39]: data > + 17. data -> hole in single block file > +0: [0..7]: data > + 1. into a hole > +0: [0..7]: data > +1: [8..39]: hole > + 2. into allocated space > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 3. into unwritten space > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 4. hole -> data > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 5. hole -> unwritten > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 6. data -> hole > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 7. data -> unwritten > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 8. unwritten -> hole > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 9. unwritten -> data > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 10. hole -> data -> hole > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 11. data -> hole -> data > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 12. unwritten -> data -> unwritten > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 13. data -> unwritten -> data > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 14. data -> hole @ EOF > +0: [0..23]: data > +1: [24..39]: hole > + 15. data -> hole @ 0 > +0: [0..15]: hole > +1: [16..39]: data > + 16. data -> cache cold ->hole > +0: [0..15]: hole > +1: [16..39]: data > + 17. data -> hole in single block file > +0: [0..7]: data > diff --git a/common.punch b/common.punch > index e2da5d8..ddf63b0 100644 > --- a/common.punch > +++ b/common.punch > @@ -256,8 +256,39 @@ die_now() > # 11. data -> hole -> data > # 12. unwritten -> data -> unwritten > # 13. data -> unwritten -> data > +# 14. data -> hole @ EOF > +# 15. data -> hole @ 0 > +# 16. data -> cache cold ->hole > +# 17. data -> hole in single block file > +# > +# Test file is removed, created and sync'd between tests. > +# > +# Use -k flag to keep the file between tests. This will > +# test the handling of pre-existing holes. > +# > +# Use the -d flag to not sync the file between tests. > +# This will test the handling of delayed extents > +# > _test_generic_punch() > { > + > + remove_testfile=1 > + sync_cmd="-c fsync" > + OPTIND=1 > + while getopts 'dk' OPTION > + do > + case $OPTION in > + k) remove_testfile= > + ;; > + d) sync_cmd= > + ;; > + ?) echo Invalid flag > + exit 1 > + ;; > + esac > + done > + shift $(($OPTIND - 1)) > + > alloc_cmd=$1 > punch_cmd=$2 > zero_cmd=$3 #if not testing zero just set to punch > @@ -267,22 +298,28 @@ _test_generic_punch() > xfs_io_opt=$7 #needs to be -F if not testing xfs > > echo " 1. into a hole" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$zero_cmd 4k 8k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 2. into allocated space" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > - -c "pwrite 0 20k" -c "fsync" \ > + -c "pwrite 0 20k" $sync_cmd \ > -c "$zero_cmd 4k 8k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 3. into unwritten space" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 0 20k" \ > -c "$zero_cmd 4k 8k" \ > @@ -290,15 +327,19 @@ _test_generic_punch() > [ $? -ne 0 ]&& die_now > > echo " 4. hole -> data" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > - -c "pwrite 8k 8k" -c "fsync" \ > + -c "pwrite 8k 8k" $sync_cmd \ > -c "$zero_cmd 4k 8k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 5. hole -> unwritten" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 8k 8k" \ > -c "$zero_cmd 4k 8k" \ > @@ -306,24 +347,30 @@ _test_generic_punch() > [ $? -ne 0 ]&& die_now > > echo " 6. data -> hole" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > - -c "pwrite 0 8k" -c "fsync" \ > + -c "pwrite 0 8k" $sync_cmd \ > -c "$zero_cmd 4k 8k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 7. data -> unwritten" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > - -c "pwrite 0 8k" -c "fsync" \ > + -c "pwrite 0 8k" $sync_cmd \ > -c "$alloc_cmd 8k 8k" \ > -c "$zero_cmd 4k 8k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 8. unwritten -> hole" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 0 8k" \ > -c "$zero_cmd 4k 8k" \ > @@ -331,49 +378,108 @@ _test_generic_punch() > [ $? -ne 0 ]&& die_now > > echo " 9. unwritten -> data" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 0 8k" \ > - -c "pwrite 8k 8k" -c "fsync" \ > + -c "pwrite 8k 8k" $sync_cmd \ > -c "$zero_cmd 4k 8k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 10. hole -> data -> hole" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > - -c "pwrite 8k 4k" -c "fsync" \ > + -c "pwrite 8k 4k" $sync_cmd \ > -c "$zero_cmd 4k 12k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 11. data -> hole -> data" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 0 20k" \ > -c "pwrite 0 8k" \ > - -c "pwrite 12k 8k" -c "fsync" \ > + -c "pwrite 12k 8k" $sync_cmd \ > -c "$punch_cmd 8k 4k" \ > -c "$zero_cmd 4k 12k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 12. unwritten -> data -> unwritten" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 0 20k" \ > - -c "pwrite 8k 4k" -c "fsync" \ > + -c "pwrite 8k 4k" $sync_cmd \ > -c "$zero_cmd 4k 12k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now Hi all, I had some questions about test 12. The output for this test is: 12. unwritten -> data -> unwritten 0: [0..7]: unwritten 1: [8..31]: hole 2: [32..39]: unwritten But ext4 gets data extents here instead of unwritten extents (on the first test with the fsync flag on). I did some investigating and it looks like the fsync command causes the extents to be written out before the punch hole operation even starts. So it makes sense to me that it should end up with data extents. Can someone explain why the golden output has unwritten extents here? Thx! Allison Henderson > > echo " 13. data -> unwritten -> data" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 0 20k" \ > - -c "pwrite 0k 8k" -c "fsync" \ > + -c "pwrite 0k 8k" $sync_cmd \ > -c "pwrite 12k 8k" -c "fsync" \ > -c "$zero_cmd 4k 12k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > + > + echo " 14. data -> hole @ EOF" > + rm -f $testfile > + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > + -c "pwrite 0 20k" $sync_cmd \ > + -c "$zero_cmd 12k 8k" \ > + -c "$map_cmd -v" $testfile | $filter_cmd > + [ $? -ne 0 ]&& die_now > + > + echo " 15. data -> hole @ 0" > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > + -c "pwrite 0 20k" $sync_cmd \ > + -c "$zero_cmd 0k 8k" \ > + -c "$map_cmd -v" $testfile | $filter_cmd > + [ $? -ne 0 ]&& die_now > + > + echo " 16. data -> cache cold ->hole" > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + rm -f $testfile.2 > + else > + cp $testfile $testfile.2 > + fi > + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > + -c "pwrite 8k 12k" -c "fsync" $testfile.2 \ > + > /dev/null > + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > + -c "pwrite 0 20k" $sync_cmd \ > + -c "$zero_cmd 0k 8k" \ > + -c "fadvise -d" \ > + -c "$map_cmd -v" $testfile | $filter_cmd > + diff $testfile $testfile.2 > + [ $? -ne 0 ]&& die_now > + rm -f $testfile.2 > + > + echo " 17. data -> hole in single block file" > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > + block_size=`stat -f $TEST_DEV | grep "Block size" | cut -d " " -f3` > + $XFS_IO_PROG $xfs_io_opt -f -c "truncate $block_size" \ > + -c "pwrite 0 $block_size" $sync_cmd \ > + -c "$zero_cmd 128 128" \ > + -c "$map_cmd -v" $testfile | $filter_cmd > + [ $? -ne 0 ]&& die_now > + > } From achender@linux.vnet.ibm.com Wed Jun 1 18:02:24 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_65 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51N2NfE154027 for ; Wed, 1 Jun 2011 18:02:24 -0500 X-ASG-Debug-ID: 1306969342-3d4c018d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e9.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8F6384958C4 for ; Wed, 1 Jun 2011 16:02:22 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by cuda.sgi.com with ESMTP id yVhqZpEsz6P60dQr for ; Wed, 01 Jun 2011 16:02:22 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p51MWGqG024587 for ; Wed, 1 Jun 2011 18:32:16 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p51N2Mov100512 for ; Wed, 1 Jun 2011 19:02:22 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p51N2LdE007518 for ; Wed, 1 Jun 2011 19:02:21 -0400 Received: from [9.48.102.246] (sig-9-48-102-246.mts.ibm.com [9.48.102.246]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p51N2JN6007462; Wed, 1 Jun 2011 19:02:19 -0400 Message-ID: <4DE6C4F2.7040706@linux.vnet.ibm.com> Date: Wed, 01 Jun 2011 16:02:10 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: xfs-oss , Dave Chinner X-ASG-Orig-Subj: Re: [XFSTEST Add Fallocate Punch Hole Tests 3/3 v4] Add ENOSPC Hole Punch Test Subject: Re: [XFSTEST Add Fallocate Punch Hole Tests 3/3 v4] Add ENOSPC Hole Punch Test References: <4DDDBC44.2070100@linux.vnet.ibm.com> In-Reply-To: <4DDDBC44.2070100@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e9.ny.us.ibm.com[32.97.182.139] X-Barracuda-Start-Time: 1306969343 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 5/25/2011 7:34 PM, Allison Henderson wrote: > This patch adds a test to 252 that tests that a hole can be punched even when the > disk is full. Reserved blocks should be used to allow a punch hole to proceed even > when there is not enough blocks to further fragment the file. To test this, the > file system is fragmented by punching holes in regular intervals and filling > the file system between punches. This will eventually force the file system to use > reserved blocks to proceed with the punch hole operation. > > Signed-off-by: Allison Henderson > --- > :100755 100755 5efa243... b5204fe... M 252 > :100644 100644 ddf63b0... fc6123c... M common.punch > 252 | 12 +++++++ > common.punch | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 107 insertions(+), 0 deletions(-) > > diff --git a/252 b/252 > index 5efa243..b5204fe 100755 > --- a/252 > +++ b/252 > @@ -49,6 +49,7 @@ _supported_os Linux > > _require_xfs_io_falloc_punch > _require_xfs_io_fiemap > +_require_scratch > > testfile=$TEST_DIR/252.$$ > > @@ -64,4 +65,15 @@ _test_generic_punch -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F > # Delayed allocation multi punch hole tests > _test_generic_punch -d -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F > > +# Test full filesystem hole punching. > +# Make a small file system to fill > +umount $SCRATCH_DEV&> /dev/null > +_scratch_mkfs_sized $(( 1024 * 1024 * 1024 ))&> /dev/null > +_scratch_mount > +# Test must be able to write files with non-root permissions > +chmod 777 $SCRATCH_MNT > + > +block_size=`stat -f $SCRATCH_DEV | grep "Block size" | cut -d " " -f3` > +_test_full_fs_punch $(( $block_size * 2 )) $block_size 500 $SCRATCH_MNT/252.$$ > + > status=0 ; exit > diff --git a/common.punch b/common.punch > index ddf63b0..fc6123c 100644 > --- a/common.punch > +++ b/common.punch > @@ -481,5 +481,100 @@ _test_generic_punch() > -c "$zero_cmd 128 128" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > +} > + > +# _fill_fs() > +# > +# Fills a file system by repeatedly creating files in the given folder > +# starting with the given file size. Files are reduced in size when > +# they can no longer fit untill no more files can be created. > +# > +# This routine is used by _test_full_fs_punch to test that a hole may > +# still be punched when the disk is full by borrowing reserved blocks. > +# All files are created as a non root user to prevent reserved blocks > +# from being consumed. > +# > +_fill_fs() { > + local file_size=$1 > + local dir=$2 > + local file_count=1 > + > + if [ $# -ne 2 ] > + then > + echo "USAGE: $0 filesize dir" > + exit 1 > + fi > + > + mkdir -p $dir&> /dev/null > + if [[ $? != 0 ]] ; then > + return 0 > + fi > + chmod 777 $dir > + > + rc=0 > + while [ $file_size -gt 0 -a $rc == 0 ] > + do > + # This part must not be done as root or > + # reserved blocks will be consumed > + sudo -u nobody $XFS_IO_PROG -F -f -c "pwrite 0 $file_size" $dir/$file_count.bin&> /dev/null Hi all, This is the ENOSPC test that we used on the ext4 punch hole, but modified to use the xfsprogs facilities. I notice the test takes a lot longer to run after doing this. If I replace the above command with the original code: sudo -u nobody dd if=/dev/zero of=$dir/$file_count.bin bs=$file_size count=1 &> /dev/null it runs a lot faster (takes off almost 15 minutes). Is there anything we can do to improve the xfsprogs command? Thx! Allison Henderson > + rc=$? > + > + # If there was no room to make the file, > + # and the file size can still be made smaller, > + # then divide it in half, and keep going > + if [ $file_size -gt 1 -a $rc != 0 ] > + then > + file_size=$(( $file_size / 2 )) > + rc=0 > + fi > + file_count=$(( $file_count + 1 )) > + > + done > +} > > +# _test_full_fs_punch() > +# > +# This function will test that a hole may be punched > +# even when the file system is full. Reserved blocks > +# should be used to allow a punch hole to proceed even > +# when there is not enough blocks to further fragment the > +# file. To test this, this function will fragment the file > +# system by punching holes in regular intervals and filling > +# the file system between punches. > +# > +_test_full_fs_punch() > +{ > + hole_len=$1 # The length of the holes to punch > + hole_interval=$2 # The interval between the holes > + iterations=$3 # The number of holes to punch > + file_name=$4 # File to punch holes in > + file_len=$(( $(( $hole_len + $hole_interval )) * $iterations )) > + path=`dirname $file_name` > + hole_offset=0 > + > + rm -f $file_name&> /dev/null > + > + $XFS_IO_PROG -F -f -c "pwrite 0 $file_len" \ > + -c "fsync" $file_name&> /dev/null > + chmod 666 $file_name > + > + _fill_fs $(( 1024 * 1024 * 1024 )) $path/fill > + > + for (( i=0; i<$iterations; i++ )) > + do > + # This part must not be done as root in order to > + # test that reserved blocks are used when needed > + sudo -u nobody $XFS_IO_PROG -F -f -c "fpunch $hole_offset $hole_len" $file_name > + rc=$? > + if [[ $? != 0 ]] ; then > + echo Punch hole failed > + break > + fi > + > + hole_offset=$(( $hole_offset + $hole_len + $hole_interval )) > + > + _fill_fs $hole_len $path/fill.$i > + > + done > } > + From david@fromorbit.com Wed Jun 1 18:28:10 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_62,J_CHICKENPOX_65,J_CHICKENPOX_66 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51NSAZG154970 for ; Wed, 1 Jun 2011 18:28:10 -0500 X-ASG-Debug-ID: 1306970887-3d4b02c40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 65C07495A2E for ; Wed, 1 Jun 2011 16:28:08 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id ZFl4AYWiyRuY7tDs for ; Wed, 01 Jun 2011 16:28:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoEADXK5k15LCoegWdsb2JhbABFDpgajhcVAQEWJiXHUg6DCQSDBQSZRoZO Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail04.adl6.internode.on.net with ESMTP; 02 Jun 2011 08:58:06 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QRupY-0006l8-Lk; Thu, 02 Jun 2011 09:28:04 +1000 Date: Thu, 2 Jun 2011 09:28:04 +1000 From: Dave Chinner To: amir73il@users.sourceforge.net Cc: xfs@oss.sgi.com, sandeen@redhat.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Message-ID: <20110601232804.GL32466@dastard> References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1306970889 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 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.2, rules version 3.2.2.65337 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Jun 01, 2011 at 03:56:52PM +0300, amir73il@users.sourceforge.net wrote: > From: Amir Goldstein > > From: Amir Goldstein > > blkid knows to identify the ext4dev FSTYP of a partition that was > formatted with mkfs.ext4dev. > quota tools and various util-linux utils are also aware of ext4dev, > so ext4dev shares the same capabilities as ext4. > > Signed-off-by: Amir Goldstein > Tested-by: Sergey Ivanov > --- > ext4dev is used to test experimental ext4 code in mutual existance > with production ext4 code on the same system. > > Specifically, ext4 snapshots code is available for testing as a > stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4 > (see http://next3.sf.net). > > v1 -> v2: > - undo change of fsck -t $FSTYP to fsck.$FSTYP > > common.defrag | 2 +- > common.quota | 4 ++-- > common.rc | 10 +++++----- > 3 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/common.defrag b/common.defrag > index 1bcf01d..4850803 100644 > --- a/common.defrag > +++ b/common.defrag > @@ -26,7 +26,7 @@ _require_defrag() > xfs) > DEFRAG_PROG=/usr/sbin/xfs_fsr > ;; > - ext4) > + ext4|ext4dev) > DEFRAG_PROG=/usr/bin/e4defrag > ;; > *) > diff --git a/common.quota b/common.quota > index 3c87ce1..b6d5f16 100644 > --- a/common.quota > +++ b/common.quota > @@ -29,7 +29,7 @@ _require_quota() > [ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed" > > case $FSTYP in > - ext2|ext3|ext4|reiserfs) > + ext2|ext3|ext4|ext4dev|reiserfs) > if [ ! -d /proc/sys/fs/quota ]; then > _notrun "Installed kernel does not support quotas" > fi > @@ -237,7 +237,7 @@ _check_quota_usage() > # Sync to get delalloc to disk > sync > VFS_QUOTA=0 > - if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "reiserfs" ]; then > + if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "ext4dev" -o $FSTYP = "reiserfs" ]; then > VFS_QUOTA=1 > quotaon -f -u -g $SCRATCH_MNT 2>/dev/null > fi Perhaps this should be changes to a case statement? Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Wed Jun 1 18:37:07 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51Nb65v155287 for ; Wed, 1 Jun 2011 18:37:06 -0500 X-ASG-Debug-ID: 1306971424-221b02180000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D63C015DA73D for ; Wed, 1 Jun 2011 16:37:04 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id TD04AxuFan6eYecZ for ; Wed, 01 Jun 2011 16:37:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwDADXK5k15LCoegWdsb2JhbABTpjEVAQEWJiXHUg6GEgSgFA Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail04.adl6.internode.on.net with ESMTP; 02 Jun 2011 09:07:03 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QRuyE-0006mK-6q; Thu, 02 Jun 2011 09:37:02 +1000 Date: Thu, 2 Jun 2011 09:37:02 +1000 From: Dave Chinner To: Michael Weissenbacher Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfssyncd and disk spin down Subject: Re: xfssyncd and disk spin down Message-ID: <20110601233702.GJ561@dastard> References: <20101227140750.GB24828@dastard> <20101227171939.GA7759@pandora.simplex.ro> <20101231001323.GD15179@dastard> <20110120100143.GA2007@peter.simplex.ro> <20110120234310.GV16267@dastard> <20110210204254.GA10451@peter.simplex.ro> <20110210221851.GG2559@dastard> <4DE5064D.1010203@dermichi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE5064D.1010203@dermichi.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1306971425 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65338 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, May 31, 2011 at 05:16:29PM +0200, Michael Weissenbacher wrote: > Brian wrote: > > > > Can anyone please comment if this bug was ever fixed? > > > > I have searched and see no further talk about this. > > > > echo 720000 > /proc/sys/fs/xfs/xfssyncd_centisecs allows a drive to sleep more > > often, but still is impacted by this. > > > > Thanks! > > > AFAICT nothing has changed in this regard. I sill see the same behavior > with kernel 2.6.39. Thanks to this thread i found out about the problems > related to accumulating head unloads which i was able to mitigate by > setting xfssyncd_centisecs to a higher value. commit fd074841cfe01b006465fb9388091012585e8dfb Author: Dave Chinner Date: Fri Apr 8 12:45:07 2011 +1000 xfs: push the AIL from memory reclaim and periodic sync When we are short on memory, we want to expedite the cleaning of dirty objects. Hence when we run short on memory, we need to kick the AIL flushing into action to clean as many dirty objects as quickly as possible. To implement this, sample the lsn of the log item at the head of the AIL and use that as the push target for the AIL flush. Further, we keep items in the AIL that are dirty that are not tracked any other way, so we can get objects sitting in the AIL that don't get written back until the AIL is pushed. Hence to get the filesystem to the idle state, we might need to push the AIL to flush out any remaining dirty objects sitting in the AIL. This requires the same push mechanism as the reclaim push. This patch also renames xfs_trans_ail_tail() to xfs_ail_min_lsn() to match the new xfs_ail_max_lsn() function introduced in this patch. Similarly for xfs_trans_ail_push -> xfs_ail_push. Signed-off-by: Dave Chinner Reviewed-by: Alex Elder Cheers, Dave. -- Dave Chinner david@fromorbit.com From support@bizoppers-invites.com Wed Jun 1 18:40:28 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.9 required=5.0 tests=BAYES_50,HTML_IMAGE_ONLY_16, HTML_MESSAGE autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51NeNlI155407 for ; Wed, 1 Jun 2011 18:40:28 -0500 X-ASG-Debug-ID: 1306971620-09e503490000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from swom-invites.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 73D2415DA1FE for ; Wed, 1 Jun 2011 16:40:21 -0700 (PDT) Received: from swom-invites.com (swom-invites.com [78.46.57.228]) by cuda.sgi.com with ESMTP id kNqDJkXROdsqHMjB for ; Wed, 01 Jun 2011 16:40:21 -0700 (PDT) Received: from bizoppers-invites.com (app1.bizoppers.com [46.4.80.185]) (Authenticated sender: support@bizoppers-invites.com) by swom-invites.com (Postfix) with ESMTPSA id 09A2229F8FD for ; Thu, 2 Jun 2011 00:40:20 +0100 (BST) Date: Wed, 01 Jun 2011 23:40:20 +0000 From: Jaypee Verdera To: linux-xfs@oss.sgi.com Message-ID: <4de6cde4adf_22d010c513872802585@app1.bizoppers.com.mail> X-ASG-Orig-Subj: Can you join my network on BizOppers? Subject: Can you join my network on BizOppers? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_4de6cde3f0e9f_22d010c5138728022c0"; charset=UTF-8 Content-Transfer-Encoding: 7bit host: bizoppers.com X-BIZOPPERS-UUID: 6277962-4f4e6 X-Barracuda-Connect: swom-invites.com[78.46.57.228] X-Barracuda-Start-Time: 1306971621 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0002 1.0000 -2.0196 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.39 X-Barracuda-Spam-Status: No, SCORE=-1.39 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_IMAGE_ONLY_16, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65338 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.63 HTML_IMAGE_ONLY_16 BODY: HTML: images with 1200-1600 bytes of words 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean ----==_mimepart_4de6cde3f0e9f_22d010c5138728022c0 Date: Wed, 01 Jun 2011 23:40:19 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-ID: <4de6cde3f3d7f_22d010c5138728023fa@app1.bizoppers.com.mail> Jaypee Verdera has joined BizOppers and says they know you: Hey, I'd like to add you to my wealth network on BizOppers. Like Facebook but pays :) - jaypee p.s. Here's the link: http://bizoppers.com/r/328308?utm_campaign=imported_contact_invitation&utm_content=et_1_text_1&utm_medium=email&utm_source=user_mailer If you don't know Jaypee Verdera you can report this member and unsubscribe: http://bizoppers.com/unsubscribe/6277962/4f4e6?utm_campaign=imported_contact_invitation&utm_content=et_1_text_2&utm_medium=email&utm_source=user_mailer ----==_mimepart_4de6cde3f0e9f_22d010c5138728022c0 Date: Wed, 01 Jun 2011 23:40:20 +0000 Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-ID: <4de6cde3f3d7f_22d010c5138728024e7@app1.bizoppers.com.mail>

BizOppers

Jaypee Verdera

Jaypee Verdera has joined BizOppers and says they know you:

 

Hey,

I'd like to add you to my wealth network on BizOppers. Like Facebook but pays :)

  • jaypee

View invitation from Jaypee Verdera

 

If you don't know Jaypee Verdera you can report this member.

 

© 2011 BizOppers

----==_mimepart_4de6cde3f0e9f_22d010c5138728022c0-- From support@bizoppers-invites.com Wed Jun 1 18:40:33 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51NeSMG155414 for ; Wed, 1 Jun 2011 18:40:33 -0500 X-ASG-Debug-ID: 1306971624-3d4b035d0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from swom-invites.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DB1C8495ACC for ; Wed, 1 Jun 2011 16:40:24 -0700 (PDT) Received: from swom-invites.com (swom-invites.com [78.46.57.228]) by cuda.sgi.com with ESMTP id W0d85eUxGUtWam4D for ; Wed, 01 Jun 2011 16:40:24 -0700 (PDT) Received: from bizoppers-invites.com (app1.bizoppers.com [46.4.80.185]) (Authenticated sender: support@bizoppers-invites.com) by swom-invites.com (Postfix) with ESMTPSA id 443BB29F91B for ; Thu, 2 Jun 2011 00:40:23 +0100 (BST) Date: Wed, 01 Jun 2011 23:40:23 +0000 From: Arjay Verdera To: linux-xfs@oss.sgi.com Message-ID: <4de6cde7394f2_22c510c513872571115@app1.bizoppers.com.mail> X-ASG-Orig-Subj: Can you join my network on BizOppers? Subject: Can you join my network on BizOppers? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_4de6cde7317f3_22c510c5138725708a2"; charset=UTF-8 Content-Transfer-Encoding: 7bit host: bizoppers.com X-BIZOPPERS-UUID: 6277997-4f4e6 X-Barracuda-Connect: swom-invites.com[78.46.57.228] X-Barracuda-Start-Time: 1306971624 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0013 1.0000 -2.0122 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65337 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean ----==_mimepart_4de6cde7317f3_22c510c5138725708a2 Date: Wed, 01 Jun 2011 23:40:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-ID: <4de6cde7346d2_22c510c51387257091e@app1.bizoppers.com.mail> Arjay Verdera has joined BizOppers and says they know you: Hey, I'd like to add you to my wealth network on BizOppers. Like Facebook but pays :) - arjay p.s. Here's the link: http://bizoppers.com/r/328793?utm_campaign=imported_contact_invitation&utm_content=et_1_text_1&utm_medium=email&utm_source=user_mailer If you don't know Arjay Verdera you can report this member and unsubscribe: http://bizoppers.com/unsubscribe/6277997/4f4e6?utm_campaign=imported_contact_invitation&utm_content=et_1_text_2&utm_medium=email&utm_source=user_mailer ----==_mimepart_4de6cde7317f3_22c510c5138725708a2 Date: Wed, 01 Jun 2011 23:40:23 +0000 Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-ID: <4de6cde735672_22c510c513872571094@app1.bizoppers.com.mail>

BizOppers

Arjay Verdera has joined BizOppers and says they know you:

 

Hey,

I'd like to add you to my wealth network on BizOppers. Like Facebook but pays :)

  • arjay

View invitation from Arjay Verdera

 

If you don't know Arjay Verdera you can report this member.

 

© 2011 BizOppers

----==_mimepart_4de6cde7317f3_22c510c5138725708a2-- From david@fromorbit.com Wed Jun 1 18:41:17 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51NfHsg155480 for ; Wed, 1 Jun 2011 18:41:17 -0500 X-ASG-Debug-ID: 1306971675-09e503510000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0057815DA77F for ; Wed, 1 Jun 2011 16:41:16 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id 904Cya4yGtQK0sy6 for ; Wed, 01 Jun 2011 16:41:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwDALbN5k15LCoegWdsb2JhbABTpjEVAQEWJiXHYQ6GEgSYHod2 Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail04.adl6.internode.on.net with ESMTP; 02 Jun 2011 09:11:15 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QRv2I-0006mq-Bs; Thu, 02 Jun 2011 09:41:14 +1000 Date: Thu, 2 Jun 2011 09:41:14 +1000 From: Dave Chinner To: Ajeet Yadav Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: What is xfs_prepair64 ? Subject: Re: What is xfs_prepair64 ? Message-ID: <20110601234114.GK561@dastard> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1306971677 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0555 1.0000 -1.6652 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.67 X-Barracuda-Spam-Status: No, SCORE=-1.67 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65338 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Jun 01, 2011 at 12:11:31PM +0530, Ajeet Yadav wrote: > xfstests FS QA Test No. 148 needs "xfs_prepair64" to run ? > I did not find this in xfsprogs-3.1.5, please guide from where to find this ? You'll never find it. It was an Irix-only, one-off parallelised xfs_repair prototype that was thrown away when the OSS xfs_repair code was parallelised much more effectively. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Wed Jun 1 18:51:55 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p51NpsKH155965 for ; Wed, 1 Jun 2011 18:51:55 -0500 X-ASG-Debug-ID: 1306972312-09cc038a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0C9D3D6CA39 for ; Wed, 1 Jun 2011 16:51:53 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id oEPioWcFES5uOxXH for ; Wed, 01 Jun 2011 16:51:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwDALbN5k15LCoegWdsb2JhbABTpjEVAQEWJiWIcb5wDoMcgnYEmB6Hdg Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail04.adl6.internode.on.net with ESMTP; 02 Jun 2011 09:21:52 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QRvCY-0006nX-NE; Thu, 02 Jun 2011 09:51:50 +1000 Date: Thu, 2 Jun 2011 09:51:50 +1000 From: Dave Chinner To: Stefan Priebe - Profihost AG Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS crashes with shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr Subject: Re: XFS crashes with shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr Message-ID: <20110601235150.GL561@dastard> References: <4DE61A7F.40800@profihost.ag> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE61A7F.40800@profihost.ag> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1306972314 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65338 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Jun 01, 2011 at 12:54:55PM +0200, Stefan Priebe - Profihost AG wrote: > Hi guys, > > we're seeing a really bad behaviour on one of our machines running > vanilla 2.6.32.40 kernel. > > It freezes from time to time or processes starts to hang. At the > same time the following message appears in the kernel log: Perhaps 2.6.32.40 needs this patch: commit 081003fff467ea0e727f66d5d435b4f473a789b3 Author: Johannes Weiner Date: Fri Oct 1 07:43:54 2010 +0000 xfs: properly account for reclaimed inodes When marking an inode reclaimable, a per-AG counter is increased, the inode is tagged reclaimable in its per-AG tree, and, when this is the first reclaimable inode in the AG, the AG entry in the per-mount tree is also tagged. When an inode is finally reclaimed, however, it is only deleted from the per-AG tree. Neither the counter is decreased, nor is the parent tree's AG entry untagged properly. Since the tags in the per-mount tree are not cleared, the inode shrinker iterates over all AGs that have had reclaimable inodes at one point in time. The counters on the other hand signal an increasing amount of slab objects to reclaim. Since "70e60ce xfs: convert inode shrinker to per-filesystem context" this is not a real issue anymore because the shrinker bails out after one iteration. But the problem was observable on a machine running v2.6.34, where the reclaimable work increased and each process going into direct reclaim eventually got stuck on the xfs inode shrinking path, trying to scan several million objects. Fix this by properly unwinding the reclaimable-state tracking of an inode when it is reclaimed. Signed-off-by: Johannes Weiner Cc: stable@kernel.org Reviewed-by: Dave Chinner Signed-off-by: Alex Elder > > shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to > delete nr=-274207938304 That's an error messge that was introduced in 2.6.34, and the above patch was introduced in 2.6.36. Obvious a bug has been backported to 2.6.32, but was the fix? It was clearly marked for stable kernels, but I have no I have no idea if the stable kernel folks pushed it back to .32. I really don't have the time to track what fixes were or were not backported to what kernels because there are too many "long term stable" kernels in existance now. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Wed Jun 1 19:16:29 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p520GTqe156953 for ; Wed, 1 Jun 2011 19:16:29 -0500 X-ASG-Debug-ID: 1306973786-2ee1021f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7DAE5167AFBD for ; Wed, 1 Jun 2011 17:16:27 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id iV9MFHv6TkEEm3ma for ; Wed, 01 Jun 2011 17:16:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwDALHU5k15LCoegWdsb2JhbABTpjEVAQEWJiXHdA6GEgSgFA Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail04.adl6.internode.on.net with ESMTP; 02 Jun 2011 09:46:26 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QRvaK-0006qM-UT; Thu, 02 Jun 2011 10:16:24 +1000 Date: Thu, 2 Jun 2011 10:16:24 +1000 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] xfs: clear inode per-lifetime state when recycling it Subject: Re: [PATCH 1/2] xfs: clear inode per-lifetime state when recycling it Message-ID: <20110602001624.GM561@dastard> References: <1306815659-23346-1-git-send-email-david@fromorbit.com> <1306815659-23346-2-git-send-email-david@fromorbit.com> <20110531200950.GA31713@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110531200950.GA31713@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1306973788 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65339 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, May 31, 2011 at 04:09:50PM -0400, Christoph Hellwig wrote: > Looks good. > > > Reviewed-by: Christoph Hellwig > > > + * XXX(dgc): should the XFS_ISTALE flag only be cleared here? > > I think so. Right now any iget on a stale inode will clear it, which > is very wrong. Care to send a separate patch for that? However, the di_mode has already been set to zero before it is marked stale, so any lookup on it without the XFS_IGET_CREATE flag set will fail. And only inode allocation sets that flag, in which case we want the XFS_ISTALE flag cleared. We can't have a race with the XFS_ISTALE flag being set (both inode freeing and allocation requires the AGI lock), so once it is stale it is protected by the mode/flag check. So it seems safe where it is, but it's not exactly obvious why. Hmmmm. The inode_init_always() failure case does not clear the XFS_IRECLAIM flag - that seems like a bug as it will prevent the inode from ever being reclaimed. Indeed, the error handling looks completely broken - it's like it is assuming the inode has already been removed from the reclaim list and marked XFS_INEW. Oh, it used to do exactly that before this commmit: commit f1f724e4b523d444c5a598d74505aefa3d6844d2 Author: Christoph Hellwig Date: Mon Mar 1 11:30:31 2010 +0000 xfs: fix locking for inode cache radix tree tag updates The radix-tree code requires it's users to serialize tag updates against other updates to the tree. While XFS protects tag updates against each other it does not serialize them against updates of the tree contents, which can lead to tag corruption. Fix the inode cache to always take pag_ici_lock in exclusive mode when updating radix tree tags. Signed-off-by: Christoph Hellwig Reported-by: Patrick Schreurs Tested-by: Patrick Schreurs Signed-off-by: Alex Elder So yes, it needs fixing. Cheers, Dave. -- Dave Chinner david@fromorbit.com From amir73il@gmail.com Wed Jun 1 21:16:08 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_62,J_CHICKENPOX_65,J_CHICKENPOX_66,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p522G8rG160650 for ; Wed, 1 Jun 2011 21:16:08 -0500 X-ASG-Debug-ID: 1306980966-139901220000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-wy0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4917F167B688 for ; Wed, 1 Jun 2011 19:16:06 -0700 (PDT) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by cuda.sgi.com with ESMTP id oYXekCYqVeUPrGGf for ; Wed, 01 Jun 2011 19:16:06 -0700 (PDT) Received: by wyi11 with SMTP id 11so313077wyi.26 for ; Wed, 01 Jun 2011 19:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q+xFObwO/tJ02xz/23Iwu/TP+DWXoo5K2ij9jcJCfnQ=; b=vtiNcWC/8csp2J4w2Fo4d7OGkqehf3I8/VeBrf7reV7KZa1Yknib1W/J87BM2cPf3A 9usMFQ3/znD+hmHAQF30qQzLyqB+165xN/8VptFs203S6IIVh7ahMFxTBVWGvGUQ1RBe NgSctHBkECjMt2wuR85jt9s9doZCCcwhwubOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ZmfMi4/051/8AWKXzSZI3UlWS91wvTlwcGgVXenjCScWpIDNMKTnnO9RZpfDLlKxTc yGPmDE4jD6lKsRqQ4iHYqHkgmYV3U8u52553XVR7rzYnT0noCwMaa/WgX1NFJPRirNQY 619QISVeF/03xUzFMVdjVpLUGA5/0UdGm0VQo= MIME-Version: 1.0 Received: by 10.216.235.129 with SMTP id u1mr5349782weq.108.1306980965524; Wed, 01 Jun 2011 19:16:05 -0700 (PDT) Sender: amir73il@gmail.com Received: by 10.216.221.135 with HTTP; Wed, 1 Jun 2011 19:16:05 -0700 (PDT) In-Reply-To: <20110601232804.GL32466@dastard> References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> Date: Thu, 2 Jun 2011 05:16:05 +0300 X-Google-Sender-Auth: ZXGbHN98mx7fLC4GMwXlUsmm8os Message-ID: X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP From: "Amir G." To: Dave Chinner Cc: xfs@oss.sgi.com, sandeen@redhat.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-wy0-f181.google.com[74.125.82.181] X-Barracuda-Start-Time: 1306980967 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65347 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner wrote: > On Wed, Jun 01, 2011 at 03:56:52PM +0300, amir73il@users.sourceforge.net = wrote: >> From: Amir Goldstein >> >> From: Amir Goldstein >> >> blkid knows to identify the ext4dev FSTYP of a partition that was >> formatted with mkfs.ext4dev. >> quota tools and various util-linux utils are also aware of ext4dev, >> so ext4dev shares the same capabilities as ext4. >> >> Signed-off-by: Amir Goldstein >> Tested-by: Sergey Ivanov >> --- >> ext4dev is used to test experimental ext4 code in mutual existance >> with production ext4 code on the same system. >> >> Specifically, ext4 snapshots code is available for testing as a >> stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4 >> (see http://next3.sf.net). >> >> v1 -> v2: >> - undo change of fsck -t $FSTYP to fsck.$FSTYP >> >> =A0common.defrag | =A0 =A02 +- >> =A0common.quota =A0| =A0 =A04 ++-- >> =A0common.rc =A0 =A0 | =A0 10 +++++----- >> =A03 files changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/common.defrag b/common.defrag >> index 1bcf01d..4850803 100644 >> --- a/common.defrag >> +++ b/common.defrag >> @@ -26,7 +26,7 @@ _require_defrag() >> =A0 =A0 =A0xfs) >> =A0 =A0 =A0 =A0 =A0DEFRAG_PROG=3D/usr/sbin/xfs_fsr >> =A0 =A0 =A0 ;; >> - =A0 =A0ext4) >> + =A0 =A0ext4|ext4dev) >> =A0 =A0 =A0 =A0 =A0DEFRAG_PROG=3D/usr/bin/e4defrag >> =A0 =A0 =A0 ;; >> =A0 =A0 =A0*) >> diff --git a/common.quota b/common.quota >> index 3c87ce1..b6d5f16 100644 >> --- a/common.quota >> +++ b/common.quota >> @@ -29,7 +29,7 @@ _require_quota() >> =A0 =A0 =A0[ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed= " >> >> =A0 =A0 =A0case $FSTYP in >> - =A0 =A0ext2|ext3|ext4|reiserfs) >> + =A0 =A0ext2|ext3|ext4|ext4dev|reiserfs) >> =A0 =A0 =A0 if [ ! -d /proc/sys/fs/quota ]; then >> =A0 =A0 =A0 =A0 =A0 _notrun "Installed kernel does not support quotas" >> =A0 =A0 =A0 fi >> @@ -237,7 +237,7 @@ _check_quota_usage() >> =A0 =A0 =A0 # Sync to get delalloc to disk >> =A0 =A0 =A0 sync >> =A0 =A0 =A0 VFS_QUOTA=3D0 >> - =A0 =A0 if [ $FSTYP =3D "ext2" -o $FSTYP =3D "ext3" -o $FSTYP =3D "ext= 4" -o $FSTYP =3D "reiserfs" ]; then >> + =A0 =A0 if [ $FSTYP =3D "ext2" -o $FSTYP =3D "ext3" -o $FSTYP =3D "ext= 4" -o $FSTYP =3D "ext4dev" -o $FSTYP =3D "reiserfs" ]; then >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 VFS_QUOTA=3D1 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 quotaon -f -u -g $SCRATCH_MNT 2>/dev/null >> =A0 =A0 =A0 fi > > Perhaps this should be changes to a case statement? > you're making me go to v3 in such a trivial patch, but ok, I'll do it ;-) > Cheers, > > Dave. > > -- > Dave Chinner > david@fromorbit.com > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at =A0http://vger.kernel.org/majordomo-info.html > From amir73il@gmail.com Wed Jun 1 21:33:37 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_62,J_CHICKENPOX_65,J_CHICKENPOX_66,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p522XbdX161702 for ; Wed, 1 Jun 2011 21:33:37 -0500 X-ASG-Debug-ID: 1306982015-497101ca0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-wy0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6B1F0495D1F for ; Wed, 1 Jun 2011 19:33:35 -0700 (PDT) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by cuda.sgi.com with ESMTP id lo89879vSeJ6h491 for ; Wed, 01 Jun 2011 19:33:35 -0700 (PDT) Received: by wyi11 with SMTP id 11so320282wyi.26 for ; Wed, 01 Jun 2011 19:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cxpeHbpUAVOd8mjIEEZ8KisO1sngxGJFXHtgqT1DLSE=; b=oZ3vtzk0pDbPzgXD8MtdiBRWhtYJ8WVkvig4dO8SGx1lacLXKOTky82f4rEziquGOp GsZBTSa8XTbIMlEKlbArn5B8YOlvyj3C4wfYZlwwZY+dVFJ8qDU4ANE7uUaNyVM+OmAb MdO3gKVOW92f24qJOjQ06wkIeAwrqxgkw9F6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=X9NDH5tfOtikavIbtVu+YczYBo9xM2fNsBzN+guyeAzfYi1aCCthPk75UDXHvolGEp CCU6vtXP2ijupsdsoqlo9wJmCkfUNIRWQlzESH4bn+akUZ/MDUhRR5LlVgXE3wQHg6OY SD0cVLIaACjR9BQzni4VJbtS8GQROQbjBiytE= MIME-Version: 1.0 Received: by 10.216.235.129 with SMTP id u1mr5359102weq.108.1306982014781; Wed, 01 Jun 2011 19:33:34 -0700 (PDT) Sender: amir73il@gmail.com Received: by 10.216.221.135 with HTTP; Wed, 1 Jun 2011 19:33:34 -0700 (PDT) In-Reply-To: References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> Date: Thu, 2 Jun 2011 05:33:34 +0300 X-Google-Sender-Auth: fv4Ps33AyL0RpezjwSQA0KL9lpE Message-ID: X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP From: "Amir G." To: Dave Chinner Cc: xfs@oss.sgi.com, sandeen@redhat.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-wy0-f181.google.com[74.125.82.181] X-Barracuda-Start-Time: 1306982016 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65349 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 2, 2011 at 5:16 AM, Amir G. wr= ote: > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner wrote: >> On Wed, Jun 01, 2011 at 03:56:52PM +0300, amir73il@users.sourceforge.net= wrote: >>> From: Amir Goldstein >>> >>> From: Amir Goldstein >>> >>> blkid knows to identify the ext4dev FSTYP of a partition that was >>> formatted with mkfs.ext4dev. >>> quota tools and various util-linux utils are also aware of ext4dev, >>> so ext4dev shares the same capabilities as ext4. >>> >>> Signed-off-by: Amir Goldstein >>> Tested-by: Sergey Ivanov >>> --- >>> ext4dev is used to test experimental ext4 code in mutual existance >>> with production ext4 code on the same system. >>> >>> Specifically, ext4 snapshots code is available for testing as a >>> stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4 >>> (see http://next3.sf.net). >>> >>> v1 -> v2: >>> - undo change of fsck -t $FSTYP to fsck.$FSTYP >>> >>> =A0common.defrag | =A0 =A02 +- >>> =A0common.quota =A0| =A0 =A04 ++-- >>> =A0common.rc =A0 =A0 | =A0 10 +++++----- >>> =A03 files changed, 8 insertions(+), 8 deletions(-) >>> >>> diff --git a/common.defrag b/common.defrag >>> index 1bcf01d..4850803 100644 >>> --- a/common.defrag >>> +++ b/common.defrag >>> @@ -26,7 +26,7 @@ _require_defrag() >>> =A0 =A0 =A0xfs) >>> =A0 =A0 =A0 =A0 =A0DEFRAG_PROG=3D/usr/sbin/xfs_fsr >>> =A0 =A0 =A0 ;; >>> - =A0 =A0ext4) >>> + =A0 =A0ext4|ext4dev) >>> =A0 =A0 =A0 =A0 =A0DEFRAG_PROG=3D/usr/bin/e4defrag >>> =A0 =A0 =A0 ;; >>> =A0 =A0 =A0*) >>> diff --git a/common.quota b/common.quota >>> index 3c87ce1..b6d5f16 100644 >>> --- a/common.quota >>> +++ b/common.quota >>> @@ -29,7 +29,7 @@ _require_quota() >>> =A0 =A0 =A0[ -n $QUOTA_PROG ] || _notrun "Quota user tools not installe= d" >>> >>> =A0 =A0 =A0case $FSTYP in >>> - =A0 =A0ext2|ext3|ext4|reiserfs) >>> + =A0 =A0ext2|ext3|ext4|ext4dev|reiserfs) >>> =A0 =A0 =A0 if [ ! -d /proc/sys/fs/quota ]; then >>> =A0 =A0 =A0 =A0 =A0 _notrun "Installed kernel does not support quotas" >>> =A0 =A0 =A0 fi >>> @@ -237,7 +237,7 @@ _check_quota_usage() >>> =A0 =A0 =A0 # Sync to get delalloc to disk >>> =A0 =A0 =A0 sync >>> =A0 =A0 =A0 VFS_QUOTA=3D0 >>> - =A0 =A0 if [ $FSTYP =3D "ext2" -o $FSTYP =3D "ext3" -o $FSTYP =3D "ex= t4" -o $FSTYP =3D "reiserfs" ]; then >>> + =A0 =A0 if [ $FSTYP =3D "ext2" -o $FSTYP =3D "ext3" -o $FSTYP =3D "ex= t4" -o $FSTYP =3D "ext4dev" -o $FSTYP =3D "reiserfs" ]; then >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 VFS_QUOTA=3D1 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 quotaon -f -u -g $SCRATCH_MNT 2>/dev/null >>> =A0 =A0 =A0 fi >> >> Perhaps this should be changes to a case statement? >> > > you're making me go to v3 in such a trivial patch, but ok, I'll do it ;-) > I rechecked the fsck -t ext4dev vs. fsck.ext4dev. fsck -t ext4dev doesn't work for me :-( Sergey has a newer version of util-linux-ng see: amir@qalab:~/xfstests$ sudo fsck -t ext4dev -nf /dev/sda5 fsck from util-linux-ng 2.17.2 e2fsck 1.41.14 (22-Dec-2010) /dev/sda5 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7 e2fsck: Get a newer version of e2fsck! amir@qalab:~/xfstests$ sudo fsck.ext4dev -nf /dev/sda5 e2fsck 1.41.14-next3-1.0.13-7 (24-May-2011) Checking snapshots: 1,done Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda5: 6596/6561792 files (3.6% non-contiguous), 1242522/26216064 block= s amir@qalab:~/xfstests$ What do you thing, Dave? Should xfstests rely on a non-buggy generic fsck util, or just implement it's own non-buggy generic fsck (invoke fsck.$FSTYP directly) I am running a recent system (Ubuntu 11.4) and I don't thing that upgrading util-linux should be a requirement for xfstests to work. >> Cheers, >> >> Dave. >> >> -- >> Dave Chinner >> david@fromorbit.com >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html >> > From david@fromorbit.com Wed Jun 1 22:08:11 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_43,J_CHICKENPOX_62,J_CHICKENPOX_65,J_CHICKENPOX_66 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5238B9g166483 for ; Wed, 1 Jun 2011 22:08:11 -0500 X-ASG-Debug-ID: 1306984088-543302b50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1CCBE495E0A for ; Wed, 1 Jun 2011 20:08:08 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id G7kMjHuG2EQ491IU for ; Wed, 01 Jun 2011 20:08:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0DAGb75k15LCoegWdsb2JhbABFDqYxFQEBFiYliHG+TA6DCQSDBQSZRoZO Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail04.adl6.internode.on.net with ESMTP; 02 Jun 2011 12:38:04 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QRyGQ-0007G6-Hr; Thu, 02 Jun 2011 13:08:02 +1000 Date: Thu, 2 Jun 2011 13:08:02 +1000 From: Dave Chinner To: "Amir G." Cc: xfs@oss.sgi.com, sandeen@redhat.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Message-ID: <20110602030802.GR561@dastard> References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> 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.20 (2009-06-14) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1306984090 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 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.2, rules version 3.2.2.65350 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 02, 2011 at 05:33:34AM +0300, Amir G. wrote: > On Thu, Jun 2, 2011 at 5:16 AM, Amir G. wrote: > > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner wrote: > >> On Wed, Jun 01, 2011 at 03:56:52PM +0300, amir73il@users.sourceforge.net wrote: > >>> From: Amir Goldstein > >>> > >>> From: Amir Goldstein > >>> > >>> blkid knows to identify the ext4dev FSTYP of a partition that was > >>> formatted with mkfs.ext4dev. > >>> quota tools and various util-linux utils are also aware of ext4dev, > >>> so ext4dev shares the same capabilities as ext4. > >>> > >>> Signed-off-by: Amir Goldstein > >>> Tested-by: Sergey Ivanov > >>> --- > >>> ext4dev is used to test experimental ext4 code in mutual existance > >>> with production ext4 code on the same system. > >>> > >>> Specifically, ext4 snapshots code is available for testing as a > >>> stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4 > >>> (see http://next3.sf.net). > >>> > >>> v1 -> v2: > >>> - undo change of fsck -t $FSTYP to fsck.$FSTYP > >>> > >>>  common.defrag |    2 +- > >>>  common.quota  |    4 ++-- > >>>  common.rc     |   10 +++++----- > >>>  3 files changed, 8 insertions(+), 8 deletions(-) > >>> > >>> diff --git a/common.defrag b/common.defrag > >>> index 1bcf01d..4850803 100644 > >>> --- a/common.defrag > >>> +++ b/common.defrag > >>> @@ -26,7 +26,7 @@ _require_defrag() > >>>      xfs) > >>>          DEFRAG_PROG=/usr/sbin/xfs_fsr > >>>       ;; > >>> -    ext4) > >>> +    ext4|ext4dev) > >>>          DEFRAG_PROG=/usr/bin/e4defrag > >>>       ;; > >>>      *) > >>> diff --git a/common.quota b/common.quota > >>> index 3c87ce1..b6d5f16 100644 > >>> --- a/common.quota > >>> +++ b/common.quota > >>> @@ -29,7 +29,7 @@ _require_quota() > >>>      [ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed" > >>> > >>>      case $FSTYP in > >>> -    ext2|ext3|ext4|reiserfs) > >>> +    ext2|ext3|ext4|ext4dev|reiserfs) > >>>       if [ ! -d /proc/sys/fs/quota ]; then > >>>           _notrun "Installed kernel does not support quotas" > >>>       fi > >>> @@ -237,7 +237,7 @@ _check_quota_usage() > >>>       # Sync to get delalloc to disk > >>>       sync > >>>       VFS_QUOTA=0 > >>> -     if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "reiserfs" ]; then > >>> +     if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "ext4dev" -o $FSTYP = "reiserfs" ]; then > >>>               VFS_QUOTA=1 > >>>               quotaon -f -u -g $SCRATCH_MNT 2>/dev/null > >>>       fi > >> > >> Perhaps this should be changes to a case statement? > >> > > > > you're making me go to v3 in such a trivial patch, but ok, I'll do it ;-) > > > > I rechecked the fsck -t ext4dev vs. fsck.ext4dev. > fsck -t ext4dev doesn't work for me :-( > Sergey has a newer version of util-linux-ng > see: > > amir@qalab:~/xfstests$ sudo fsck -t ext4dev -nf /dev/sda5 > fsck from util-linux-ng 2.17.2 > e2fsck 1.41.14 (22-Dec-2010) > /dev/sda5 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7 > e2fsck: Get a newer version of e2fsck! > amir@qalab:~/xfstests$ sudo fsck.ext4dev -nf /dev/sda5 > e2fsck 1.41.14-next3-1.0.13-7 (24-May-2011) > Checking snapshots: 1,done > Pass 1: Checking inodes, blocks, and sizes > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity > Pass 4: Checking reference counts > Pass 5: Checking group summary information > /dev/sda5: 6596/6561792 files (3.6% non-contiguous), 1242522/26216064 blocks > amir@qalab:~/xfstests$ > > What do you thing, Dave? > Should xfstests rely on a non-buggy generic fsck util, For filessytems that use the generic fsck multiplexor, yes. > or just > implement it's own > non-buggy generic fsck (invoke fsck.$FSTYP directly) In general, no. XFS is a special case in that fsck.xfs is a no-op - it does no checking at all and only returns values needed for init scripts to work correctly. xfs_repair/xfs_check are for checking the filesystem... > I am running a recent system (Ubuntu 11.4) and I don't thing that upgrading > util-linux should be a requirement for xfstests to work. We do not try to support every buggy piece of crap out there - if a newer version of util-linux has already fixed the problem, then use that and we don't need to do anything special with xfstests at all. If you've got bleeding edge filesystem code that requires using a ext4dev fstyp and a new ext4 userspace, then I think that requiring you to use a non-buggy util-linux is not a big deal.... --- Personally I think that ext4dev shouldn't be supported at all. A special fstyp iwhile ext4 was being developed was, IMO, a stupid thing to do in the first place, and I was happy when it died. It should not be resurrected and propagated. xfstests assumes that you are using a userspace that is current with the version of the filesystem the kernel supports. If you are running a development/special branch of ext4, then you need to be running a userspace that understands it completely. If all you are doing with the ext4dev fstyp is trying to vector to a different fsck program that supports a new set of feature bits, then IMO you are doing it all wrong. Fundamentally, the filesystem is either ext4 or it isn't. If the features are never going to make it into mainline ext4, then you need a completely different fstype and full userspace support for that fstype. Once you have that, you can add the fstype support to xfstests. However, just using a different fstyp just to set a certain set of feature flags is, again IMO, a pretty stupid way of going about this. Cheers, Dave. -- Dave Chinner david@fromorbit.com From amir73il@gmail.com Wed Jun 1 22:49:27 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_43,J_CHICKENPOX_62,J_CHICKENPOX_65,J_CHICKENPOX_66, T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p523nQOI167962 for ; Wed, 1 Jun 2011 22:49:26 -0500 X-ASG-Debug-ID: 1306986564-766100630000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-wy0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B3E77D6D572 for ; Wed, 1 Jun 2011 20:49:24 -0700 (PDT) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by cuda.sgi.com with ESMTP id B6OInfSYv2gxDccv for ; Wed, 01 Jun 2011 20:49:24 -0700 (PDT) Received: by wyi11 with SMTP id 11so347242wyi.26 for ; Wed, 01 Jun 2011 20:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CQFfjgVkVVi0dKVCO8UFiDoVa+8E8C9YRYtQmME7f70=; b=gszMZhxeXPzgZvoptXW7HFAv3gkrvhEy9zw750vL6gp4FfmMJzMtEeumN6hThcgmC2 /bO3+zHi9tG7UkUiTwCw8ffOr3y47RqKwerNnGo0r/3YSg4o++EhYLurSbnPb/3Q3QJw C7XAPdhzEagIeX831uZ6lXtr7KURSewwV5JFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=oY/jfeDcY4ZseypF8zsYiqAMu8DSmqs/MVgawxNNm5UbcJTmPrkXpa1VGYTuFrHPcg ms06Jx7YqDGdM8atu0sFPMw54NllWGlnHUKEwPmxKtp/PnRGPFh+i/F7VXh/nvHYyrwT wa/lnWdecyyqtmKM8kAhFNH/K77QFs9pi4WJQ= MIME-Version: 1.0 Received: by 10.216.81.69 with SMTP id l47mr5427555wee.78.1306986560478; Wed, 01 Jun 2011 20:49:20 -0700 (PDT) Sender: amir73il@gmail.com Received: by 10.216.221.135 with HTTP; Wed, 1 Jun 2011 20:49:20 -0700 (PDT) In-Reply-To: <20110602030802.GR561@dastard> References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <20110602030802.GR561@dastard> Date: Thu, 2 Jun 2011 06:49:20 +0300 X-Google-Sender-Auth: VmcM15HFCcB3MsbC5kq9DIjsjoo Message-ID: X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP From: "Amir G." To: Dave Chinner Cc: xfs@oss.sgi.com, sandeen@redhat.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-wy0-f181.google.com[74.125.82.181] X-Barracuda-Start-Time: 1306986565 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65353 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 2, 2011 at 6:08 AM, Dave Chinner wrote: > On Thu, Jun 02, 2011 at 05:33:34AM +0300, Amir G. wrote: >> On Thu, Jun 2, 2011 at 5:16 AM, Amir G. = wrote: >> > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner wro= te: >> >> On Wed, Jun 01, 2011 at 03:56:52PM +0300, amir73il@users.sourceforge.= net wrote: >> >>> From: Amir Goldstein >> >>> >> >>> From: Amir Goldstein >> >>> >> >>> blkid knows to identify the ext4dev FSTYP of a partition that was >> >>> formatted with mkfs.ext4dev. >> >>> quota tools and various util-linux utils are also aware of ext4dev, >> >>> so ext4dev shares the same capabilities as ext4. >> >>> >> >>> Signed-off-by: Amir Goldstein >> >>> Tested-by: Sergey Ivanov >> >>> --- >> >>> ext4dev is used to test experimental ext4 code in mutual existance >> >>> with production ext4 code on the same system. >> >>> >> >>> Specifically, ext4 snapshots code is available for testing as a >> >>> stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4 >> >>> (see http://next3.sf.net). >> >>> >> >>> v1 -> v2: >> >>> - undo change of fsck -t $FSTYP to fsck.$FSTYP >> >>> >> >>> =A0common.defrag | =A0 =A02 +- >> >>> =A0common.quota =A0| =A0 =A04 ++-- >> >>> =A0common.rc =A0 =A0 | =A0 10 +++++----- >> >>> =A03 files changed, 8 insertions(+), 8 deletions(-) >> >>> >> >>> diff --git a/common.defrag b/common.defrag >> >>> index 1bcf01d..4850803 100644 >> >>> --- a/common.defrag >> >>> +++ b/common.defrag >> >>> @@ -26,7 +26,7 @@ _require_defrag() >> >>> =A0 =A0 =A0xfs) >> >>> =A0 =A0 =A0 =A0 =A0DEFRAG_PROG=3D/usr/sbin/xfs_fsr >> >>> =A0 =A0 =A0 ;; >> >>> - =A0 =A0ext4) >> >>> + =A0 =A0ext4|ext4dev) >> >>> =A0 =A0 =A0 =A0 =A0DEFRAG_PROG=3D/usr/bin/e4defrag >> >>> =A0 =A0 =A0 ;; >> >>> =A0 =A0 =A0*) >> >>> diff --git a/common.quota b/common.quota >> >>> index 3c87ce1..b6d5f16 100644 >> >>> --- a/common.quota >> >>> +++ b/common.quota >> >>> @@ -29,7 +29,7 @@ _require_quota() >> >>> =A0 =A0 =A0[ -n $QUOTA_PROG ] || _notrun "Quota user tools not insta= lled" >> >>> >> >>> =A0 =A0 =A0case $FSTYP in >> >>> - =A0 =A0ext2|ext3|ext4|reiserfs) >> >>> + =A0 =A0ext2|ext3|ext4|ext4dev|reiserfs) >> >>> =A0 =A0 =A0 if [ ! -d /proc/sys/fs/quota ]; then >> >>> =A0 =A0 =A0 =A0 =A0 _notrun "Installed kernel does not support quota= s" >> >>> =A0 =A0 =A0 fi >> >>> @@ -237,7 +237,7 @@ _check_quota_usage() >> >>> =A0 =A0 =A0 # Sync to get delalloc to disk >> >>> =A0 =A0 =A0 sync >> >>> =A0 =A0 =A0 VFS_QUOTA=3D0 >> >>> - =A0 =A0 if [ $FSTYP =3D "ext2" -o $FSTYP =3D "ext3" -o $FSTYP =3D = "ext4" -o $FSTYP =3D "reiserfs" ]; then >> >>> + =A0 =A0 if [ $FSTYP =3D "ext2" -o $FSTYP =3D "ext3" -o $FSTYP =3D = "ext4" -o $FSTYP =3D "ext4dev" -o $FSTYP =3D "reiserfs" ]; then >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 VFS_QUOTA=3D1 >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 quotaon -f -u -g $SCRATCH_MNT 2>/dev/nul= l >> >>> =A0 =A0 =A0 fi >> >> >> >> Perhaps this should be changes to a case statement? >> >> >> > >> > you're making me go to v3 in such a trivial patch, but ok, I'll do it = ;-) >> > >> >> I rechecked the fsck -t ext4dev vs. fsck.ext4dev. >> fsck -t ext4dev doesn't work for me :-( >> Sergey has a newer version of =A0util-linux-ng >> see: >> >> amir@qalab:~/xfstests$ sudo fsck -t ext4dev -nf /dev/sda5 >> fsck from util-linux-ng 2.17.2 >> e2fsck 1.41.14 (22-Dec-2010) >> /dev/sda5 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7 >> e2fsck: Get a newer version of e2fsck! >> amir@qalab:~/xfstests$ sudo fsck.ext4dev -nf /dev/sda5 >> e2fsck 1.41.14-next3-1.0.13-7 (24-May-2011) >> Checking snapshots: 1,done >> Pass 1: Checking inodes, blocks, and sizes >> Pass 2: Checking directory structure >> Pass 3: Checking directory connectivity >> Pass 4: Checking reference counts >> Pass 5: Checking group summary information >> /dev/sda5: 6596/6561792 files (3.6% non-contiguous), 1242522/26216064 bl= ocks >> amir@qalab:~/xfstests$ >> >> What do you thing, Dave? >> Should xfstests rely on a non-buggy generic fsck util, > > For filessytems that use the generic fsck multiplexor, yes. > >> or just >> implement it's own >> non-buggy generic fsck (invoke fsck.$FSTYP directly) > > In general, no. XFS is a special case in that fsck.xfs is a no-op - > it does no checking at all and only returns values needed for init > scripts to work correctly. xfs_repair/xfs_check are for checking the > filesystem... > >> I am running a recent system (Ubuntu 11.4) and I don't thing that upgrad= ing >> util-linux should be a requirement for xfstests to work. > > We do not try to support every buggy piece of crap out there - if a > newer version of util-linux has already fixed the problem, then use > that and we don't need to do anything special with xfstests at all. > If you've got bleeding edge filesystem code that requires using a > ext4dev fstyp and a new ext4 userspace, then I think that requiring > you to use a non-buggy util-linux is not a big deal.... > no. not a big deal at all. > --- > > Personally I think that ext4dev shouldn't be supported at all. A > special fstyp iwhile ext4 was being developed was, IMO, a stupid > thing to do in the first place, and I was happy when it died. It > should not be resurrected and propagated. > > xfstests assumes that you are using a userspace that is current with > the version of the filesystem the kernel supports. If you are > running a development/special branch of ext4, then you need to be > running a userspace that understands it completely. If all you are > doing with the ext4dev fstyp is trying to vector to a different fsck > program that supports a new set of feature bits, then IMO you are > doing it all wrong. > > Fundamentally, the filesystem is either ext4 or it isn't. If the > features are never going to make it into mainline ext4, then you > need a completely different fstype and full userspace support for > that fstype. Once you have that, you can add the fstype support to > xfstests. However, just using a different fstyp just to set a > certain set of feature flags is, again IMO, a pretty stupid way of > going about this. > The features are going into mainline, but are not there yet. I did not invent the ext4dev standard, which is pretty well supported by all relevant tools, but I find it very convenient for the testing. Especially, when I expect my testers to be running a stable distro release (i.e. F15 or Ubuntu 11.4) and be able to install my experimental ext4dev module and utils, without it affecting their (most likely) root ext4/ext3 fs. > Cheers, > > Dave. > > -- > Dave Chinner > david@fromorbit.com > From tytso@thunk.org Wed Jun 1 23:01:12 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5241BIq168441 for ; Wed, 1 Jun 2011 23:01:12 -0500 X-ASG-Debug-ID: 1306987270-0e5f01b60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from test.thunk.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 091D1495EB5 for ; Wed, 1 Jun 2011 21:01:10 -0700 (PDT) Received: from test.thunk.org (li9-11.members.linode.com [67.18.176.11]) by cuda.sgi.com with ESMTP id maNjylzvYsQONeGL for ; Wed, 01 Jun 2011 21:01:10 -0700 (PDT) Received: from root (helo=tytso-glaptop) by test.thunk.org with local-esmtp (Exim 4.69) (envelope-from ) id 1QRz5o-0004WJ-MN; Thu, 02 Jun 2011 04:01:08 +0000 Received: from tytso by tytso-glaptop with local (Exim 4.71) (envelope-from ) id 1QRx0E-0004e0-JR; Wed, 01 Jun 2011 21:47:14 -0400 Date: Wed, 1 Jun 2011 21:47:04 -0400 From: "Ted Ts'o" To: Eric Sandeen Cc: Amir Goldstein , XFS , Sergey Ivanov , Ext4 Developers List , linux-fsdevel X-ASG-Orig-Subj: Re: [PATCH] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH] xfstests: add support for ext4dev FSTYP Message-ID: <20110602014704.GA16306@thunk.org> References: <4DE5C1FE.8080006@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE5C1FE.8080006@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on test.thunk.org); SAEximRunCond expanded to false X-Barracuda-Connect: li9-11.members.linode.com[67.18.176.11] X-Barracuda-Start-Time: 1306987271 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65354 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, May 31, 2011 at 11:37:18PM -0500, Eric Sandeen wrote: > > I'm less certain of the change from fsck -t $FSTYP to fsck.$FSTYP > > What issue are you avoiding? wouldn't fsck -t ext4dev invoke > fsck.ext4dev anyway? This is a change I make locally when I've been debugging my bigalloc code as well. There reason for that is because I want to override the fsck.ext4 that would get used by using path hacking. The problem was that fsck -t ext4 will look for /sbin/fsck.ext4, where as I wanted it to use the fsck.ext4 that was first in the PATH. So I changed "/sbin/fsck -t $FSTYP" to "fsck.$FSTYP" and made sure /sbin was tacked onto the path. It might be that the right answer is that fsck should have an environment variable or some other way of controlling the search path it uses to find the fsck.XXX binary. - Ted From amir73il@gmail.com Wed Jun 1 23:17:22 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_62,J_CHICKENPOX_65,J_CHICKENPOX_66,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p524HMPq168930 for ; Wed, 1 Jun 2011 23:17:22 -0500 X-ASG-Debug-ID: 1306988240-138803d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ww0-f51.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 975B81E3B1AF for ; Wed, 1 Jun 2011 21:17:20 -0700 (PDT) Received: from mail-ww0-f51.google.com (mail-ww0-f51.google.com [74.125.82.51]) by cuda.sgi.com with ESMTP id lSOsKeIgYFxKI7Jr for ; Wed, 01 Jun 2011 21:17:20 -0700 (PDT) Received: by wwf26 with SMTP id 26so388746wwf.32 for ; Wed, 01 Jun 2011 21:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:from:to:cc:subject:date:message-id :x-mailer; bh=DGi29fUZf0Fa93Dph6k24e7QBMVvlFLJcVEg2AGOMC4=; b=KyF7xMbIQnLxPUMqMpUdUY5FZapE5pHdkiGzkYdI0+pz2o0ptmUqD8Du7BR7MeEPI+ xaJwo9/kMH+okFZpZbqbtbO3da6UenJWergVhuqVSqYXw+FpWvRvui9qX/BW1zdIVlbT ioXEzPsjGE3un2ZSPuzRVly8u3MrpSEes0Es4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:cc:subject:date:message-id:x-mailer; b=rfJU31kqD/I8bzAbCSg7obyIdDKwx3VA71IoPS/JH2SGKQj6oq3GqROVIFVVdkq1mr E6zOOV7T+OTp/ZtLrMW1lfxVlck2YnihXwqJ9RgLuLmZTpmzlVA3OB2VNvjCYqH3rrQ+ YjdVC3BjDhqr3X6LZwu4dNmR0nBV2Nb6RoRXk= Received: by 10.216.64.209 with SMTP id c59mr3709149wed.41.1306988239228; Wed, 01 Jun 2011 21:17:19 -0700 (PDT) Received: from localhost.localdomain (bzq-218-153-66.cablep.bezeqint.net [81.218.153.66]) by mx.google.com with ESMTPS id w58sm92641weq.1.2011.06.01.21.17.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 21:17:18 -0700 (PDT) Sender: Amir Goldstein From: amir73il@users.sourceforge.net To: xfs@oss.sgi.com Cc: sandeen@redhat.com, sergey57@gmail.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, Amir Goldstein X-ASG-Orig-Subj: [PATCH v3] xfstests: add support for ext4dev FSTYP Subject: [PATCH v3] xfstests: add support for ext4dev FSTYP Date: Thu, 2 Jun 2011 07:17:01 +0300 Message-Id: <1306988221-3543-1-git-send-email-amir73il@users.sourceforge.net> X-Mailer: git-send-email 1.7.4.1 X-Barracuda-Connect: mail-ww0-f51.google.com[74.125.82.51] X-Barracuda-Start-Time: 1306988241 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, MAILTO_TO_SPAM_ADDR, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65354 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Amir Goldstein blkid knows to identify the ext4dev FSTYP of a partition that was formatted with mkfs.ext4dev. quota tools and various util-linux utils are also aware of ext4dev, so ext4dev shares the same capabilities as ext4. Signed-off-by: Amir Goldstein Tested-by: Sergey Ivanov --- ext4dev is used to test experimental ext4 code in mutual existance with production ext4 code on the same system. Specifically, ext4 snapshots code is available for testing as a stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4 (see http://next3.sf.net). v2 -> v3: - change if to case statement v1 -> v2: - undo change of fsck -t $FSTYP to fsck.$FSTYP common.defrag | 2 +- common.quota | 10 +++++++--- common.rc | 10 +++++----- 3 files changed, 13 insertions(+), 9 deletions(-) diff --git a/common.defrag b/common.defrag index 1bcf01d..4850803 100644 --- a/common.defrag +++ b/common.defrag @@ -26,7 +26,7 @@ _require_defrag() xfs) DEFRAG_PROG=/usr/sbin/xfs_fsr ;; - ext4) + ext4|ext4dev) DEFRAG_PROG=/usr/bin/e4defrag ;; *) diff --git a/common.quota b/common.quota index 3c87ce1..9736306 100644 --- a/common.quota +++ b/common.quota @@ -29,7 +29,7 @@ _require_quota() [ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed" case $FSTYP in - ext2|ext3|ext4|reiserfs) + ext2|ext3|ext4|ext4dev|reiserfs) if [ ! -d /proc/sys/fs/quota ]; then _notrun "Installed kernel does not support quotas" fi @@ -237,10 +237,14 @@ _check_quota_usage() # Sync to get delalloc to disk sync VFS_QUOTA=0 - if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "reiserfs" ]; then + case $FSTYP in + ext2|ext3|ext4|ext4dev|reiserfs) VFS_QUOTA=1 quotaon -f -u -g $SCRATCH_MNT 2>/dev/null - fi + ;; + *) + ;; + esac repquota -u -n $SCRATCH_MNT | grep -v "^#0" | _filter_scratch | sort >$tmp.user.orig repquota -g -n $SCRATCH_MNT | grep -v "^#0" | _filter_scratch | diff --git a/common.rc b/common.rc index e634fbb..c510c66 100644 --- a/common.rc +++ b/common.rc @@ -65,7 +65,7 @@ _mount_opts() nfs) export MOUNT_OPTIONS=$NFS_MOUNT_OPTIONS ;; - ext2|ext3|ext4) + ext2|ext3|ext4|ext4dev) # acls & xattrs aren't turned on by default on ext$FOO export MOUNT_OPTIONS="-o acl,user_xattr $EXT_MOUNT_OPTIONS" ;; @@ -110,7 +110,7 @@ _mkfs_opts() _fsck_opts() { case $FSTYP in - ext2|ext3|ext4) + ext2|ext3|ext4|ext4dev) export FSCK_OPTIONS="-nf" ;; reiserfs) @@ -326,10 +326,10 @@ _scratch_mkfs_sized() xfs) _scratch_mkfs_xfs -d size=$fssize -b size=$blocksize ;; - ext2|ext3|ext4) + ext2|ext3|ext4|ext4dev) /sbin/mkfs.$FSTYP $MKFS_OPTIONS -b $blocksize $SCRATCH_DEV $blocks ;; - btrfs) + btrfs) /sbin/mkfs.$FSTYP $MKFS_OPTIONS $SCRATCH_DEV -b $fssize ;; *) @@ -354,7 +354,7 @@ _scratch_mkfs_geom() xfs) MKFS_OPTIONS+=" -b size=$blocksize, -d su=$sunit_bytes,sw=$swidth_mult" ;; - ext4) + ext4|ext4dev) MKFS_OPTIONS+=" -b $blocksize -E stride=$sunit_blocks,stripe_width=$swidth_blocks" ;; *) -- 1.7.4.1 From david@fromorbit.com Thu Jun 2 01:40:47 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p526elGN176921 for ; Thu, 2 Jun 2011 01:40:47 -0500 X-ASG-Debug-ID: 1306996844-75bd00340000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 53EFC15DAC27 for ; Wed, 1 Jun 2011 23:40:45 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id 1SIewnZTWFEhtcCA for ; Wed, 01 Jun 2011 23:40:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUDALAu5015LCoegWdsb2JhbABTpjAVAQEWJiWIcb5BDoYTBKAp Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:10:42 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QS1aC-0007YM-8u; Thu, 02 Jun 2011 16:40:40 +1000 Date: Thu, 2 Jun 2011 16:40:40 +1000 From: Dave Chinner To: "Amir G." Cc: xfs@oss.sgi.com, sandeen@redhat.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Message-ID: <20110602064040.GS561@dastard> References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <20110602030802.GR561@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306996846 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65365 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 02, 2011 at 06:49:20AM +0300, Amir G. wrote: > On Thu, Jun 2, 2011 at 6:08 AM, Dave Chinner wrote: > > On Thu, Jun 02, 2011 at 05:33:34AM +0300, Amir G. wrote: > >> On Thu, Jun 2, 2011 at 5:16 AM, Amir G. wrote: > >> > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner wrote: > > Personally I think that ext4dev shouldn't be supported at all. A > > special fstyp iwhile ext4 was being developed was, IMO, a stupid > > thing to do in the first place, and I was happy when it died. It > > should not be resurrected and propagated. > > > > xfstests assumes that you are using a userspace that is current with > > the version of the filesystem the kernel supports. If you are > > running a development/special branch of ext4, then you need to be > > running a userspace that understands it completely. If all you are > > doing with the ext4dev fstyp is trying to vector to a different fsck > > program that supports a new set of feature bits, then IMO you are > > doing it all wrong. > > > > Fundamentally, the filesystem is either ext4 or it isn't. If the > > features are never going to make it into mainline ext4, then you > > need a completely different fstype and full userspace support for > > that fstype. Once you have that, you can add the fstype support to > > xfstests. However, just using a different fstyp just to set a > > certain set of feature flags is, again IMO, a pretty stupid way of > > going about this. > > > > The features are going into mainline, but are not there yet. So using feature bits as they were intended is the right thing to do, isn't it? > I did not invent the ext4dev standard, which is pretty well supported > by all relevant tools, but I find it very convenient for the testing. As I understand it, ext4dev is deprecated and should not be used for any new filesystems. When did that status change? Or did you just start using it because it's convenient for your purposes? What happens when someone else decides to use ext4dev for testing incompatible development features because it is convenient for them? > Especially, when I expect my testers to be running a stable > distro release (i.e. F15 or Ubuntu 11.4) and be able to install > my experimental ext4dev module and utils, without it affecting > their (most likely) root ext4/ext3 fs. So get them to use an ext3, XFS, reiser or JFS root filesystem if that's your major concern. That's long been a best practice for configuring a filesystem test box - don't use the same filesystem for your root/stable filesystems as the filesytsem you are testing. e.g. If you pick ext3 for the root filesystem, then you can test ext4, btrfs, xfs, etc changes without having to worry about whether the development module being tested is going to affect your root filesystem.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From dave@fromorbit.com Thu Jun 2 02:01:22 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,LOCAL_GNU_PATCH autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271Lxe180466 for ; Thu, 2 Jun 2011 02:01:21 -0500 X-ASG-Debug-ID: 1306998079-75bf01060000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7478915DACF1 for ; Thu, 2 Jun 2011 00:01:19 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id snjbPSq9aVnNR9Qy for ; Thu, 02 Jun 2011 00:01:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUDAAky5015LCoegWdsb2JhbABTpjAVAQEWJiXHUIYhBKAp Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:18 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1u9-0007aU-9z; Thu, 02 Jun 2011 17:01:17 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1u2-0007Cv-Dx; Thu, 02 Jun 2011 17:01:10 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 02/12] vmscan: shrinker->nr updates race and go wrong Subject: [PATCH 02/12] vmscan: shrinker->nr updates race and go wrong Date: Thu, 2 Jun 2011 17:00:57 +1000 Message-Id: <1306998067-27659-3-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998080 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65365 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner shrink_slab() allows shrinkers to be called in parallel so the struct shrinker can be updated concurrently. It does not provide any exclusio for such updates, so we can get the shrinker->nr value increasing or decreasing incorrectly. As a result, when a shrinker repeatedly returns a value of -1 (e.g. a VFS shrinker called w/ GFP_NOFS), the shrinker->nr goes haywire, sometimes updating with the scan count that wasn't used, sometimes losing it altogether. Worse is when a shrinker does work and that update is lost due to racy updates, which means the shrinker will do the work again! Fix this by making the total_scan calculations independent of shrinker->nr, and making the shrinker->nr updates atomic w.r.t. to other updates via cmpxchg loops. Signed-off-by: Dave Chinner --- include/trace/events/vmscan.h | 26 ++++++++++++++---------- mm/vmscan.c | 43 ++++++++++++++++++++++++++++++---------- 2 files changed, 47 insertions(+), 22 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index c798cd7..6147b4e 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -311,12 +311,13 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, ); TRACE_EVENT(mm_shrink_slab_start, - TP_PROTO(struct shrinker *shr, struct shrink_control *sc, + TP_PROTO(struct shrinker *shr, struct shrink_control *sc, long shr_nr, unsigned long pgs_scanned, unsigned long lru_pgs, unsigned long cache_items, unsigned long long delta, unsigned long total_scan), - TP_ARGS(shr, sc, pgs_scanned, lru_pgs, cache_items, delta, total_scan), + TP_ARGS(shr, sc, shr_nr, pgs_scanned, lru_pgs, + cache_items, delta, total_scan), TP_STRUCT__entry( __field(struct shrinker *, shr) @@ -331,7 +332,7 @@ TRACE_EVENT(mm_shrink_slab_start, TP_fast_assign( __entry->shr = shr; - __entry->shr_nr = shr->nr; + __entry->shr_nr = shr_nr; __entry->gfp_flags = sc->gfp_mask; __entry->pgs_scanned = pgs_scanned; __entry->lru_pgs = lru_pgs; @@ -353,27 +354,30 @@ TRACE_EVENT(mm_shrink_slab_start, TRACE_EVENT(mm_shrink_slab_end, TP_PROTO(struct shrinker *shr, int shrinker_ret, - unsigned long total_scan), + long old_nr, long new_nr), - TP_ARGS(shr, shrinker_ret, total_scan), + TP_ARGS(shr, shrinker_ret, old_nr, new_nr), TP_STRUCT__entry( __field(struct shrinker *, shr) - __field(long, shr_nr) + __field(long, old_nr) + __field(long, new_nr) __field(int, shrinker_ret) - __field(unsigned long, total_scan) + __field(long, total_scan) ), TP_fast_assign( __entry->shr = shr; - __entry->shr_nr = shr->nr; + __entry->old_nr = old_nr; + __entry->new_nr = new_nr; __entry->shrinker_ret = shrinker_ret; - __entry->total_scan = total_scan; + __entry->total_scan = new_nr - old_nr; ), - TP_printk("shrinker %p: nr %ld total_scan %ld return val %d", + TP_printk("shrinker %p: old_nr %ld new_nr %ld total_scan %ld return val %d", __entry->shr, - __entry->shr_nr, + __entry->old_nr, + __entry->new_nr, __entry->total_scan, __entry->shrinker_ret) ); diff --git a/mm/vmscan.c b/mm/vmscan.c index 48e3fbd..dce2767 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -251,17 +251,29 @@ unsigned long shrink_slab(struct shrink_control *shrink, unsigned long total_scan; unsigned long max_pass; int shrink_ret = 0; + long nr; + long new_nr; + /* + * copy the current shrinker scan count into a local variable + * and zero it so that other concurrent shrinker invocations + * don't also do this scanning work. + */ + do { + nr = shrinker->nr; + } while (cmpxchg(&shrinker->nr, nr, 0) != nr); + + total_scan = nr; max_pass = do_shrinker_shrink(shrinker, shrink, 0); delta = (4 * nr_pages_scanned) / shrinker->seeks; delta *= max_pass; do_div(delta, lru_pages + 1); - shrinker->nr += delta; - if (shrinker->nr < 0) { + total_scan += delta; + if (total_scan < 0) { printk(KERN_ERR "shrink_slab: %pF negative objects to " "delete nr=%ld\n", - shrinker->shrink, shrinker->nr); - shrinker->nr = max_pass; + shrinker->shrink, total_scan); + total_scan = max_pass; } /* @@ -269,13 +281,11 @@ unsigned long shrink_slab(struct shrink_control *shrink, * never try to free more than twice the estimate number of * freeable entries. */ - if (shrinker->nr > max_pass * 2) - shrinker->nr = max_pass * 2; + if (total_scan > max_pass * 2) + total_scan = max_pass * 2; - total_scan = shrinker->nr; - shrinker->nr = 0; - trace_mm_shrink_slab_start(shrinker, shrink, nr_pages_scanned, + trace_mm_shrink_slab_start(shrinker, shrink, nr, nr_pages_scanned, lru_pages, max_pass, delta, total_scan); while (total_scan >= SHRINK_BATCH) { @@ -295,8 +305,19 @@ unsigned long shrink_slab(struct shrink_control *shrink, cond_resched(); } - shrinker->nr += total_scan; - trace_mm_shrink_slab_end(shrinker, shrink_ret, total_scan); + /* + * move the unused scan count back into the shrinker in a + * manner that handles concurrent updates. If we exhausted the + * scan, there is no need to do an update. + */ + do { + nr = shrinker->nr; + new_nr = total_scan + nr; + if (total_scan <= 0) + break; + } while (cmpxchg(&shrinker->nr, nr, new_nr) != nr); + + trace_mm_shrink_slab_end(shrinker, shrink_ret, nr, new_nr); } up_read(&shrinker_rwsem); out: -- 1.7.5.1 From dave@fromorbit.com Thu Jun 2 02:01:23 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,LOCAL_GNU_PATCH autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271MV6180476 for ; Thu, 2 Jun 2011 02:01:23 -0500 X-ASG-Debug-ID: 1306998079-75bf01060001-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E52E915DACF1 for ; Thu, 2 Jun 2011 00:01:20 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id iu526RXOhQdHAVGd for ; Thu, 02 Jun 2011 00:01:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUDAAky5015LCoegWdsb2JhbABTpjAVAQEWJiXHUIYhBKAp Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:18 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1u9-0007af-JP; Thu, 02 Jun 2011 17:01:17 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1u2-0007D6-Lk; Thu, 02 Jun 2011 17:01:10 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 06/12] inode: Make unused inode LRU per superblock Subject: [PATCH 06/12] inode: Make unused inode LRU per superblock Date: Thu, 2 Jun 2011 17:01:01 +1000 Message-Id: <1306998067-27659-7-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998081 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65365 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner The inode unused list is currently a global LRU. This does not match the other global filesystem cache - the dentry cache - which uses per-superblock LRU lists. Hence we have related filesystem object types using different LRU reclaimation schemes. To enable a per-superblock filesystem cache shrinker, both of these caches need to have per-sb unused object LRU lists. Hence this patch converts the global inode LRU to per-sb LRUs. The patch only does rudimentary per-sb propotioning in the shrinker infrastructure, as this gets removed when the per-sb shrinker callouts are introduced later on. Signed-off-by: Dave Chinner --- fs/inode.c | 91 +++++++++++++++++++++++++++++++++++++++++++++------ fs/super.c | 1 + include/linux/fs.h | 4 ++ 3 files changed, 85 insertions(+), 11 deletions(-) diff --git a/fs/inode.c b/fs/inode.c index 17fea5b..e039115 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -34,7 +34,7 @@ * inode->i_lock protects: * inode->i_state, inode->i_hash, __iget() * inode_lru_lock protects: - * inode_lru, inode->i_lru + * inode->i_sb->s_inode_lru, inode->i_lru * inode_sb_list_lock protects: * sb->s_inodes, inode->i_sb_list * inode_wb_list_lock protects: @@ -64,7 +64,6 @@ static unsigned int i_hash_shift __read_mostly; static struct hlist_head *inode_hashtable __read_mostly; static __cacheline_aligned_in_smp DEFINE_SPINLOCK(inode_hash_lock); -static LIST_HEAD(inode_lru); static DEFINE_SPINLOCK(inode_lru_lock); __cacheline_aligned_in_smp DEFINE_SPINLOCK(inode_sb_list_lock); @@ -345,7 +344,8 @@ static void inode_lru_list_add(struct inode *inode) { spin_lock(&inode_lru_lock); if (list_empty(&inode->i_lru)) { - list_add(&inode->i_lru, &inode_lru); + list_add(&inode->i_lru, &inode->i_sb->s_inode_lru); + inode->i_sb->s_nr_inodes_unused++; this_cpu_inc(nr_unused); } spin_unlock(&inode_lru_lock); @@ -356,6 +356,7 @@ static void inode_lru_list_del(struct inode *inode) spin_lock(&inode_lru_lock); if (!list_empty(&inode->i_lru)) { list_del_init(&inode->i_lru); + inode->i_sb->s_nr_inodes_unused--; this_cpu_dec(nr_unused); } spin_unlock(&inode_lru_lock); @@ -621,21 +622,20 @@ static int can_unuse(struct inode *inode) * LRU does not have strict ordering. Hence we don't want to reclaim inodes * with this flag set because they are the inodes that are out of order. */ -static void prune_icache(int nr_to_scan) +static void shrink_icache_sb(struct super_block *sb, int *nr_to_scan) { LIST_HEAD(freeable); int nr_scanned; unsigned long reap = 0; - down_read(&iprune_sem); spin_lock(&inode_lru_lock); - for (nr_scanned = 0; nr_scanned < nr_to_scan; nr_scanned++) { + for (nr_scanned = *nr_to_scan; nr_scanned >= 0; nr_scanned--) { struct inode *inode; - if (list_empty(&inode_lru)) + if (list_empty(&sb->s_inode_lru)) break; - inode = list_entry(inode_lru.prev, struct inode, i_lru); + inode = list_entry(sb->s_inode_lru.prev, struct inode, i_lru); /* * we are inverting the inode_lru_lock/inode->i_lock here, @@ -643,7 +643,7 @@ static void prune_icache(int nr_to_scan) * inode to the back of the list so we don't spin on it. */ if (!spin_trylock(&inode->i_lock)) { - list_move(&inode->i_lru, &inode_lru); + list_move(&inode->i_lru, &sb->s_inode_lru); continue; } @@ -655,6 +655,7 @@ static void prune_icache(int nr_to_scan) (inode->i_state & ~I_REFERENCED)) { list_del_init(&inode->i_lru); spin_unlock(&inode->i_lock); + sb->s_nr_inodes_unused--; this_cpu_dec(nr_unused); continue; } @@ -662,7 +663,7 @@ static void prune_icache(int nr_to_scan) /* recently referenced inodes get one more pass */ if (inode->i_state & I_REFERENCED) { inode->i_state &= ~I_REFERENCED; - list_move(&inode->i_lru, &inode_lru); + list_move(&inode->i_lru, &sb->s_inode_lru); spin_unlock(&inode->i_lock); continue; } @@ -676,7 +677,7 @@ static void prune_icache(int nr_to_scan) iput(inode); spin_lock(&inode_lru_lock); - if (inode != list_entry(inode_lru.next, + if (inode != list_entry(sb->s_inode_lru.next, struct inode, i_lru)) continue; /* wrong inode or list_empty */ /* avoid lock inversions with trylock */ @@ -692,6 +693,7 @@ static void prune_icache(int nr_to_scan) spin_unlock(&inode->i_lock); list_move(&inode->i_lru, &freeable); + sb->s_nr_inodes_unused--; this_cpu_dec(nr_unused); } if (current_is_kswapd()) @@ -699,8 +701,75 @@ static void prune_icache(int nr_to_scan) else __count_vm_events(PGINODESTEAL, reap); spin_unlock(&inode_lru_lock); + *nr_to_scan = nr_scanned; dispose_list(&freeable); +} + +static void prune_icache(int count) +{ + struct super_block *sb, *p = NULL; + int w_count; + int unused = inodes_stat.nr_unused; + int prune_ratio; + int pruned; + + if (unused == 0 || count == 0) + return; + down_read(&iprune_sem); + if (count >= unused) + prune_ratio = 1; + else + prune_ratio = unused / count; + spin_lock(&sb_lock); + list_for_each_entry(sb, &super_blocks, s_list) { + if (list_empty(&sb->s_instances)) + continue; + if (sb->s_nr_inodes_unused == 0) + continue; + sb->s_count++; + /* Now, we reclaim unused dentrins with fairness. + * We reclaim them same percentage from each superblock. + * We calculate number of dentries to scan on this sb + * as follows, but the implementation is arranged to avoid + * overflows: + * number of dentries to scan on this sb = + * count * (number of dentries on this sb / + * number of dentries in the machine) + */ + spin_unlock(&sb_lock); + if (prune_ratio != 1) + w_count = (sb->s_nr_inodes_unused / prune_ratio) + 1; + else + w_count = sb->s_nr_inodes_unused; + pruned = w_count; + /* + * We need to be sure this filesystem isn't being unmounted, + * otherwise we could race with generic_shutdown_super(), and + * end up holding a reference to an inode while the filesystem + * is unmounted. So we try to get s_umount, and make sure + * s_root isn't NULL. + */ + if (down_read_trylock(&sb->s_umount)) { + if ((sb->s_root != NULL) && + (!list_empty(&sb->s_dentry_lru))) { + shrink_icache_sb(sb, &w_count); + pruned -= w_count; + } + up_read(&sb->s_umount); + } + spin_lock(&sb_lock); + if (p) + __put_super(p); + count -= pruned; + p = sb; + /* more work left to do? */ + if (count <= 0) + break; + } + if (p) + __put_super(p); + spin_unlock(&sb_lock); up_read(&iprune_sem); } diff --git a/fs/super.c b/fs/super.c index c755939..ef7caf7 100644 --- a/fs/super.c +++ b/fs/super.c @@ -77,6 +77,7 @@ static struct super_block *alloc_super(struct file_system_type *type) INIT_HLIST_BL_HEAD(&s->s_anon); INIT_LIST_HEAD(&s->s_inodes); INIT_LIST_HEAD(&s->s_dentry_lru); + INIT_LIST_HEAD(&s->s_inode_lru); init_rwsem(&s->s_umount); mutex_init(&s->s_lock); lockdep_set_class(&s->s_umount, &type->s_umount_key); diff --git a/include/linux/fs.h b/include/linux/fs.h index c55d6b7..a96071d 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1393,6 +1393,10 @@ struct super_block { struct list_head s_dentry_lru; /* unused dentry lru */ int s_nr_dentry_unused; /* # of dentry on lru */ + /* inode_lru_lock protects s_inode_lru and s_nr_inodes_unused */ + struct list_head s_inode_lru; /* unused inode lru */ + int s_nr_inodes_unused; /* # of inodes on lru */ + struct block_device *s_bdev; struct backing_dev_info *s_bdi; struct mtd_info *s_mtd; -- 1.7.5.1 From dave@fromorbit.com Thu Jun 2 02:01:24 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271Oc2180485 for ; Thu, 2 Jun 2011 02:01:24 -0500 X-ASG-Debug-ID: 1306998081-08f101710000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 125274963B5 for ; Thu, 2 Jun 2011 00:01:21 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id g5jfBVQm8sHAbx1e for ; Thu, 02 Jun 2011 00:01:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYDAAky5015LCoegWdsb2JhbABTG4QuoWcVAQEWJiW2bpBigSuDbIEKBKAp Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:18 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1u9-0007aS-7v; Thu, 02 Jun 2011 17:01:17 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1u2-0007Cr-A1; Thu, 02 Jun 2011 17:01:10 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 0/12] Per superblock cache reclaim Subject: [PATCH 0/12] Per superblock cache reclaim Date: Thu, 2 Jun 2011 17:00:55 +1000 Message-Id: <1306998067-27659-1-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998083 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65366 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This series converts the VFS cache shrinkers to a per-superblock shrinker, and provides a callout from the superblock shrinker to allow the filesystem to shrink internal caches proportionally to the amount of reclaim done to the VFS caches. The motivation for this work is that the VFS caches are dependent caches - dentries pin inodes, and inodes often pin other filesystem specific structures. The caches can grow quite large and it is easy for them to get unbalanced when they are shrunk independently. Reclaim is also focussed on sharing reclaim batches across all superblocks rather than within a superblock, so often reclaim calls only remove a few objects from each superblock at a time. This means that we touch lots of superblocks and LRUs one every shrinker call, and we have to traverse the superblock list all the time. This leads to life-cycle issues - we have to ensure that the superblock we are trying to work on is active and won't go away, and also ensure that the unmount process synchronises correctly with active shrinkers. This is complex and the locks involved cause issues with lockdep refularly reporting false positive lock inversions. Firstly, however, there are several longstanding bugs in the VM shrinker infrastructure that need to be fixed. Firstly, we need to add tracepoints so we can observe the behaviour of the shrinker calculations. Secondly, the shrinker scan calculations are not SMP safe and that is causing shrinkers to either miss work they should be doing, or doing a lot more work than they should. With these fixes in place, I found the reason that I was not able to balance system behaviour on my first attempt at per-sb shrinkers. When a shrinker repeatedly returns "-1" to avoid deadlocks, like will happen when a filesystem is doing GFP_NOFS memory allocations during transactions (and that happens *a lot* during filesystem intensive workloads), then the work is delayed by adding it to shrinker->nr for the next shrinker call to do. This causes the shrinker->nr to increase until it is 2x the number of objects in the cache, and so when the shrinker is finally able to do work, it is effectively told to shrink the entire cache to zero. Twice over. You'll never guess how I found it - the tracepoints I added, perhaps? This problem is fixed by only allowing the shrinker->nr to wind up to half the size of the cache when there are lots of little additions caused by deadlock avoidance. This is sufficient to maintain current levels of performance whilst avoiding the cache trashing problem. So, back to the VFS cache shrinkers. To avoid all the above problems, we can use the per-shrinker context infrastructure that was introduced recently for XFS. By adding a shrinker context to each superblock and registering the shrinker after the superblock is created and unregistering it early in the unmount process we avoid the need for specific unmount synchronisation between the shrinker and the unmount process. Goodbye iprune_sem. Further, by having per-superblock shrinker callouts, we no longer need to walk the superblock list on every shrinker call for both the dentry and inode caches, nor do we need to proportion reclaim between superblocks. That simplifies the cache shrinking implementation significantly. However, to take advantage of this, the first thing we need to do is convert the inode cache LRU to a per-superblock LRU. This is trivial to do - it's just a copy of the dentry cache infrastructure. The inode cache LRU can also be trivially converted to a lock per superblock as well, so that is done at the same time. [ Note that it looks like the same change can be made to the dentry cache LRU, but the simple conversion from the global dcache_lru_lock to per-sb locks results in occasional, strange ENOENT errors during path lookups. So that patch is on hold. ] With a single shrinker - prune_super() - that can address both the per-sb dentry and inode LRUs, it is a simple matter of proportioning the reclaim batch between them. This is done simply by the ratio of objects in the two caches, and the dentry cache is pruned first so that it unpins inodes before the inode cache is pruned. Now that we have prune_super(), reclaiming hundreds of thousands or millions of dentries and inodes in batches of 128 objects does not make much sense. The VM shrinker infrastructure uses a batch size of 128 so that it can regularly reschedule if necessary. The dentry cache pruner already has reschedule checks, and it is trivial to add them to the VFS and XFS inode cache pruners. With that done, there is no reason why we can't use a much larger reclaim batch size and remove more objects from each cache on each visit to them. To do this, add a per-shrinker batch size configuration field, and configure prune_super() to use a larger batch size of 1024 objects. This reduces the number of times we need to make calculations, traffic locks and structures, and means we spend more time in cache specific loops than we would with a smaller batch size. This reduces the overhead of cache shrinking. Overall, the changes result in steady state cache ratios on XFS, ext4 and btrfs of 1 dentry : 3 inodes. The state ratio is 1 inused inode : 2 free inodes (the in-use inode is pinned by the dentry). The following chart demonstrateÑ• ext4 (left) and btrfs (right) cache ratios under steady state 8-way file creation conditions. http://userweb.kernel.org/~dgc/shrinker/ext4-btrfs-cache-ratio.png For XFS, however, the situation is slightly more complex. XFS maintains it's own inode cache (the VFS inode cache is a subset of the XFS cache), and so needs to be able to keep that synchronised with the VFS caches. Hence a filesystem specific callout is added to the superblock pruning method that is proportioned with the VFS dentry and inode caches. Implementing these methods is optional, and this is done for XFS in the last patch in the series. XFS behaviour at different stages of the patch series can be seen in the following chart: http://userweb.kernel.org/~dgc/shrinker/per-sb-shrinker-comparison.png The left-most traces are from a kernel with just the VM shrink_slab() fixes. The middle trace is the same 8-way create workload, but with the inode cache LRU changes and the per-sb superblock shrinker addressing just the VFS dentry and inode caches. The right-most (partial) workload trace is the full series with the XFS inode cache shrinker being called from prune_super(). You can see from the top chart that the cache behaviour has much less variance in the middle trace with the per-sb shrinkers compared to the left-most trace. Also, you can see that the XFS inode cache size follows the VFS inode cache residency much more closely in the right-most trace as a result of using the prune_super() filesystem callout. Yes, these XFS traces are much more variable that the ext4 and btrfs charts, but XFS is putting significantly more pressure on the caches and most allocations are GFP_NOFS, hence triggering the wind-up problems described above. It is, however, much better behaved than the existing shrinker behaviour (worse than the left-most trace with the VM fixes) and much better than the previous (aborted) per-sb shrinker attempts: http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc4-per-sb-basic-16x500-xfs.png http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc4-per-sb-balance-16x500-xfs.png http://userweb.kernel.org/~dgc/shrinker-2.6.36/fs_mark-2.6.35-rc4-per-sb-proportional-16x500-xfs.png --- The following changes since commit c7427d23f7ed695ac226dbe3a84d7f19091d34ce: autofs4: bogus dentry_unhash() added in ->unlink() (2011-05-30 01:50:53 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/people/dgc/xfsdev.git per-sb-shrinker Dave Chinner (12): vmscan: add shrink_slab tracepoints vmscan: shrinker->nr updates race and go wrong vmscan: reduce wind up shrinker->nr when shrinker can't do work vmscan: add customisable shrinker batch size inode: convert inode_stat.nr_unused to per-cpu counters inode: Make unused inode LRU per superblock inode: move to per-sb LRU locks superblock: introduce per-sb cache shrinker infrastructure inode: remove iprune_sem superblock: add filesystem shrinker operations vfs: increase shrinker batch size xfs: make use of new shrinker callout for the inode cache Documentation/filesystems/vfs.txt | 21 ++++++ fs/dcache.c | 121 ++++-------------------------------- fs/inode.c | 124 ++++++++++++------------------------- fs/super.c | 79 +++++++++++++++++++++++- fs/xfs/linux-2.6/xfs_super.c | 26 +++++--- fs/xfs/linux-2.6/xfs_sync.c | 71 ++++++++------------- fs/xfs/linux-2.6/xfs_sync.h | 5 +- include/linux/fs.h | 14 ++++ include/linux/mm.h | 1 + include/trace/events/vmscan.h | 71 +++++++++++++++++++++ mm/vmscan.c | 70 ++++++++++++++++----- 11 files changed, 337 insertions(+), 266 deletions(-) From dave@fromorbit.com Thu Jun 2 02:01:42 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271gaY180519 for ; Thu, 2 Jun 2011 02:01:42 -0500 X-ASG-Debug-ID: 1306998100-6c1b03390000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A69D44963BE for ; Thu, 2 Jun 2011 00:01:40 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id skQyoF9FLaF1r6Cn for ; Thu, 02 Jun 2011 00:01:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYDAAky5015LCoegWdsb2JhbABThEmhZxUBARYmJbZukGKBK4NsgQoEmDKHdw Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:39 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1u9-0007aT-8K; Thu, 02 Jun 2011 17:01:17 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1u2-0007Ct-C7; Thu, 02 Jun 2011 17:01:10 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 01/12] vmscan: add shrink_slab tracepoints Subject: [PATCH 01/12] vmscan: add shrink_slab tracepoints Date: Thu, 2 Jun 2011 17:00:56 +1000 Message-Id: <1306998067-27659-2-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998101 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65366 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner Іt is impossible to understand what the shrinkers are actually doing without instrumenting the code, so add a some tracepoints to allow insight to be gained. Signed-off-by: Dave Chinner --- include/trace/events/vmscan.h | 67 +++++++++++++++++++++++++++++++++++++++++ mm/vmscan.c | 6 +++- 2 files changed, 72 insertions(+), 1 deletions(-) diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h index ea422aa..c798cd7 100644 --- a/include/trace/events/vmscan.h +++ b/include/trace/events/vmscan.h @@ -310,6 +310,73 @@ TRACE_EVENT(mm_vmscan_lru_shrink_inactive, show_reclaim_flags(__entry->reclaim_flags)) ); +TRACE_EVENT(mm_shrink_slab_start, + TP_PROTO(struct shrinker *shr, struct shrink_control *sc, + unsigned long pgs_scanned, unsigned long lru_pgs, + unsigned long cache_items, unsigned long long delta, + unsigned long total_scan), + + TP_ARGS(shr, sc, pgs_scanned, lru_pgs, cache_items, delta, total_scan), + + TP_STRUCT__entry( + __field(struct shrinker *, shr) + __field(long, shr_nr) + __field(gfp_t, gfp_flags) + __field(unsigned long, pgs_scanned) + __field(unsigned long, lru_pgs) + __field(unsigned long, cache_items) + __field(unsigned long long, delta) + __field(unsigned long, total_scan) + ), + + TP_fast_assign( + __entry->shr = shr; + __entry->shr_nr = shr->nr; + __entry->gfp_flags = sc->gfp_mask; + __entry->pgs_scanned = pgs_scanned; + __entry->lru_pgs = lru_pgs; + __entry->cache_items = cache_items; + __entry->delta = delta; + __entry->total_scan = total_scan; + ), + + TP_printk("shrinker %p: nr %ld gfp_flags %s pgs_scanned %ld lru_pgs %ld cache items %ld delta %lld total_scan %ld", + __entry->shr, + __entry->shr_nr, + show_gfp_flags(__entry->gfp_flags), + __entry->pgs_scanned, + __entry->lru_pgs, + __entry->cache_items, + __entry->delta, + __entry->total_scan) +); + +TRACE_EVENT(mm_shrink_slab_end, + TP_PROTO(struct shrinker *shr, int shrinker_ret, + unsigned long total_scan), + + TP_ARGS(shr, shrinker_ret, total_scan), + + TP_STRUCT__entry( + __field(struct shrinker *, shr) + __field(long, shr_nr) + __field(int, shrinker_ret) + __field(unsigned long, total_scan) + ), + + TP_fast_assign( + __entry->shr = shr; + __entry->shr_nr = shr->nr; + __entry->shrinker_ret = shrinker_ret; + __entry->total_scan = total_scan; + ), + + TP_printk("shrinker %p: nr %ld total_scan %ld return val %d", + __entry->shr, + __entry->shr_nr, + __entry->total_scan, + __entry->shrinker_ret) +); #endif /* _TRACE_VMSCAN_H */ diff --git a/mm/vmscan.c b/mm/vmscan.c index faa0a08..48e3fbd 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -250,6 +250,7 @@ unsigned long shrink_slab(struct shrink_control *shrink, unsigned long long delta; unsigned long total_scan; unsigned long max_pass; + int shrink_ret = 0; max_pass = do_shrinker_shrink(shrinker, shrink, 0); delta = (4 * nr_pages_scanned) / shrinker->seeks; @@ -274,9 +275,11 @@ unsigned long shrink_slab(struct shrink_control *shrink, total_scan = shrinker->nr; shrinker->nr = 0; + trace_mm_shrink_slab_start(shrinker, shrink, nr_pages_scanned, + lru_pages, max_pass, delta, total_scan); + while (total_scan >= SHRINK_BATCH) { long this_scan = SHRINK_BATCH; - int shrink_ret; int nr_before; nr_before = do_shrinker_shrink(shrinker, shrink, 0); @@ -293,6 +296,7 @@ unsigned long shrink_slab(struct shrink_control *shrink, } shrinker->nr += total_scan; + trace_mm_shrink_slab_end(shrinker, shrink_ret, total_scan); } up_read(&shrinker_rwsem); out: -- 1.7.5.1 From dave@fromorbit.com Thu Jun 2 02:01:43 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271hSc180529 for ; Thu, 2 Jun 2011 02:01:43 -0500 X-ASG-Debug-ID: 1306998100-6c1b03390001-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B59B44963C0 for ; Thu, 2 Jun 2011 00:01:41 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id 5WeyqZcvQR1BSsoY for ; Thu, 02 Jun 2011 00:01:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAAky5015LCoegWdsb2JhbABTmBiOGBUBARYmJcdQhiEEmDKHdw Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:39 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1uJ-0007an-Fh; Thu, 02 Jun 2011 17:01:27 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1u2-0007D3-K1; Thu, 02 Jun 2011 17:01:10 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 05/12] inode: convert inode_stat.nr_unused to per-cpu counters Subject: [PATCH 05/12] inode: convert inode_stat.nr_unused to per-cpu counters Date: Thu, 2 Jun 2011 17:01:00 +1000 Message-Id: <1306998067-27659-6-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998102 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65366 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner Before we split up the inode_lru_lock, the unused inode counter needs to be made independent of the global inode_lru_lock. Convert it to per-cpu counters to do this. Signed-off-by: Dave Chinner --- fs/inode.c | 16 +++++++++++----- 1 files changed, 11 insertions(+), 5 deletions(-) diff --git a/fs/inode.c b/fs/inode.c index 0f7e88a..17fea5b 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -95,6 +95,7 @@ EXPORT_SYMBOL(empty_aops); struct inodes_stat_t inodes_stat; static DEFINE_PER_CPU(unsigned int, nr_inodes); +static DEFINE_PER_CPU(unsigned int, nr_unused); static struct kmem_cache *inode_cachep __read_mostly; @@ -109,7 +110,11 @@ static int get_nr_inodes(void) static inline int get_nr_inodes_unused(void) { - return inodes_stat.nr_unused; + int i; + int sum = 0; + for_each_possible_cpu(i) + sum += per_cpu(nr_unused, i); + return sum < 0 ? 0 : sum; } int get_nr_dirty_inodes(void) @@ -127,6 +132,7 @@ int proc_nr_inodes(ctl_table *table, int write, void __user *buffer, size_t *lenp, loff_t *ppos) { inodes_stat.nr_inodes = get_nr_inodes(); + inodes_stat.nr_unused = get_nr_inodes_unused(); return proc_dointvec(table, write, buffer, lenp, ppos); } #endif @@ -340,7 +346,7 @@ static void inode_lru_list_add(struct inode *inode) spin_lock(&inode_lru_lock); if (list_empty(&inode->i_lru)) { list_add(&inode->i_lru, &inode_lru); - inodes_stat.nr_unused++; + this_cpu_inc(nr_unused); } spin_unlock(&inode_lru_lock); } @@ -350,7 +356,7 @@ static void inode_lru_list_del(struct inode *inode) spin_lock(&inode_lru_lock); if (!list_empty(&inode->i_lru)) { list_del_init(&inode->i_lru); - inodes_stat.nr_unused--; + this_cpu_dec(nr_unused); } spin_unlock(&inode_lru_lock); } @@ -649,7 +655,7 @@ static void prune_icache(int nr_to_scan) (inode->i_state & ~I_REFERENCED)) { list_del_init(&inode->i_lru); spin_unlock(&inode->i_lock); - inodes_stat.nr_unused--; + this_cpu_dec(nr_unused); continue; } @@ -686,7 +692,7 @@ static void prune_icache(int nr_to_scan) spin_unlock(&inode->i_lock); list_move(&inode->i_lru, &freeable); - inodes_stat.nr_unused--; + this_cpu_dec(nr_unused); } if (current_is_kswapd()) __count_vm_events(KSWAPD_INODESTEAL, reap); -- 1.7.5.1 From dave@fromorbit.com Thu Jun 2 02:01:44 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271iBM180537 for ; Thu, 2 Jun 2011 02:01:44 -0500 X-ASG-Debug-ID: 1306998102-76f902870000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 808A11ED18EE for ; Thu, 2 Jun 2011 00:01:42 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id BVnfx74hwhde5ET5 for ; Thu, 02 Jun 2011 00:01:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYDAAky5015LCoegWdsb2JhbABThEmhZxUBARYmJbZukGKBK4NsgQoEoCk Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:39 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1uJ-0007al-Da; Thu, 02 Jun 2011 17:01:27 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1u2-0007Cx-Fi; Thu, 02 Jun 2011 17:01:10 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 03/12] vmscan: reduce wind up shrinker->nr when shrinker can't do work Subject: [PATCH 03/12] vmscan: reduce wind up shrinker->nr when shrinker can't do work Date: Thu, 2 Jun 2011 17:00:58 +1000 Message-Id: <1306998067-27659-4-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998103 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3076 1.0000 -0.3163 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.32 X-Barracuda-Spam-Status: No, SCORE=-0.32 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65366 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner When a shrinker returns -1 to shrink_slab() to indicate it cannot do any work given the current memory reclaim requirements, it adds the entire total_scan count to shrinker->nr. The idea ehind this is that whenteh shrinker is next called and can do work, it will do the work of the previously aborted shrinker call as well. However, if a filesystem is doing lots of allocation with GFP_NOFS set, then we get many, many more aborts from the shrinkers than we do successful calls. The result is that shrinker->nr winds up to it's maximum permissible value (twice the current cache size) and then when the next shrinker call that can do work is issued, it has enough scan count built up to free the entire cache twice over. This manifests itself in the cache going from full to empty in a matter of seconds, even when only a small part of the cache is needed to be emptied to free sufficient memory. Under metadata intensive workloads on ext4 and XFS, I'm seeing the VFS caches increase memory consumption up to 75% of memory (no page cache pressure) over a period of 30-60s, and then the shrinker empties them down to zero in the space of 2-3s. This cycle repeats over and over again, with the shrinker completely trashing the Ñ–node and dentry caches every minute or so the workload continues. This behaviour was made obvious by the shrink_slab tracepoints added earlier in the series, and made worse by the patch that corrected the concurrent accounting of shrinker->nr. To avoid this problem, stop repeated small increments of the total scan value from winding shrinker->nr up to a value that can cause the entire cache to be freed. We still need to allow it to wind up, so use the delta as the "large scan" threshold check - if the delta is more than a quarter of the entire cache size, then it is a large scan and allowed to cause lots of windup because we are clearly needing to free lots of memory. If it isn't a large scan then limit the total scan to half the size of the cache so that windup never increases to consume the whole cache. Reducing the total scan limit further does not allow enough wind-up to maintain the current levels of performance, whilst a higher threshold does not prevent the windup from freeing the entire cache under sustained workloads. Signed-off-by: Dave Chinner --- mm/vmscan.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index dce2767..3688f47 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -277,6 +277,20 @@ unsigned long shrink_slab(struct shrink_control *shrink, } /* + * Avoid excessive windup on fielsystem shrinkers due to large + * numbers of GFP_NOFS allocations causing the shrinkers to + * return -1 all the time. This results in a large nr being + * built up so when a shrink that can do some work comes along + * it empties the entire cache due to nr >>> max_pass. This is + * bad for sustaining a working set in memory. + * + * Hence only allow nr to go large when a large delta is + * calculated. + */ + if (delta < max_pass / 4) + total_scan = min(total_scan, max_pass / 2); + + /* * Avoid risking looping forever due to too large nr value: * never try to free more than twice the estimate number of * freeable entries. -- 1.7.5.1 From dave@fromorbit.com Thu Jun 2 02:01:47 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271lQn180561 for ; Thu, 2 Jun 2011 02:01:47 -0500 X-ASG-Debug-ID: 1306998102-76f902870001-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A59F01ED1906 for ; Thu, 2 Jun 2011 00:01:45 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id GfV4XkKcn2mHXBRp for ; Thu, 02 Jun 2011 00:01:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAAky5015LCoegWdsb2JhbABTmBiOGBUBARYmJcdQhiEEoCk Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:39 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1uJ-0007b1-Rk; Thu, 02 Jun 2011 17:01:27 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1uC-0007DM-Vc; Thu, 02 Jun 2011 17:01:20 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 11/12] vfs: increase shrinker batch size Subject: [PATCH 11/12] vfs: increase shrinker batch size Date: Thu, 2 Jun 2011 17:01:06 +1000 Message-Id: <1306998067-27659-12-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998106 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65366 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner Now that the per-sb shrinker is responsible for shrinking 2 or more caches, increase the batch size to keep econmies of scale for shrinking each cache. Increase the shrinker batch size to 1024 objects. To allow for a large increase in batch size, add a conditional reschedule to prune_icache_sb() so that we don't hold the LRU spin lock for too long. This mirrors the behaviour of the __shrink_dcache_sb(), and allows us to increase the batch size without needing to worry about problems caused by long lock hold times. To ensure that filesystems using the per-sb shrinker callouts don't cause problems, document that the object freeing method must reschedule appropriately inside loops. Signed-off-by: Dave Chinner --- Documentation/filesystems/vfs.txt | 5 +++++ fs/super.c | 1 + 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index dc732d2..2e26973 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -317,6 +317,11 @@ or bottom half). the VM is trying to reclaim under GFP_NOFS conditions, hence this method does not need to handle that situation itself. + Implementations must include conditional reschedule calls inside any + scanning loop that is done. This allows the VFS to determine + appropriate scan batch sizes without having to worry about whether + implementations will cause holdoff problems due ot large batch sizes. + Whoever sets up the inode is responsible for filling in the "i_op" field. This is a pointer to a "struct inode_operations" which describes the methods that can be performed on individual inodes. diff --git a/fs/super.c b/fs/super.c index b55f968..323a63e 100644 --- a/fs/super.c +++ b/fs/super.c @@ -184,6 +184,7 @@ static struct super_block *alloc_super(struct file_system_type *type) s->s_shrink.seeks = DEFAULT_SEEKS; s->s_shrink.shrink = prune_super; + s->s_shrink.batch = 1024; } out: return s; -- 1.7.5.1 From dave@fromorbit.com Thu Jun 2 02:01:47 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271kqv180558 for ; Thu, 2 Jun 2011 02:01:46 -0500 X-ASG-Debug-ID: 1306998100-6c1b03390002-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3AB014963D3 for ; Thu, 2 Jun 2011 00:01:43 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id 5qMrbIUQZt5VvZmV for ; Thu, 02 Jun 2011 00:01:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAAky5015LCoegWdsb2JhbABTmBiOGBUBARYmJcdQhiEEoCk Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:39 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1uJ-0007am-FY; Thu, 02 Jun 2011 17:01:27 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1u2-0007D0-IB; Thu, 02 Jun 2011 17:01:10 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 04/12] vmscan: add customisable shrinker batch size Subject: [PATCH 04/12] vmscan: add customisable shrinker batch size Date: Thu, 2 Jun 2011 17:00:59 +1000 Message-Id: <1306998067-27659-5-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998106 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65366 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner For shrinkers that have their own cond_resched* calls, having shrink_slab break the work down into small batches is not paticularly efficient. Add a custom batchsize field to the struct shrinker so that shrinkers can use a larger batch size if they desire. A value of zero (uninitialised) means "use the default", so behaviour is unchanged by this patch. Signed-off-by: Dave Chinner --- include/linux/mm.h | 1 + mm/vmscan.c | 11 ++++++----- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 9670f71..9b9777a 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1150,6 +1150,7 @@ struct shrink_control { struct shrinker { int (*shrink)(struct shrinker *, struct shrink_control *sc); int seeks; /* seeks to recreate an obj */ + long batch; /* reclaim batch size, 0 = default */ /* These are for internal use */ struct list_head list; diff --git a/mm/vmscan.c b/mm/vmscan.c index 3688f47..a17909f 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -253,6 +253,8 @@ unsigned long shrink_slab(struct shrink_control *shrink, int shrink_ret = 0; long nr; long new_nr; + long batch_size = shrinker->batch ? shrinker->batch + : SHRINK_BATCH; /* * copy the current shrinker scan count into a local variable @@ -302,19 +304,18 @@ unsigned long shrink_slab(struct shrink_control *shrink, trace_mm_shrink_slab_start(shrinker, shrink, nr, nr_pages_scanned, lru_pages, max_pass, delta, total_scan); - while (total_scan >= SHRINK_BATCH) { - long this_scan = SHRINK_BATCH; + while (total_scan >= batch_size) { int nr_before; nr_before = do_shrinker_shrink(shrinker, shrink, 0); shrink_ret = do_shrinker_shrink(shrinker, shrink, - this_scan); + batch_size); if (shrink_ret == -1) break; if (shrink_ret < nr_before) ret += nr_before - shrink_ret; - count_vm_events(SLABS_SCANNED, this_scan); - total_scan -= this_scan; + count_vm_events(SLABS_SCANNED, batch_size); + total_scan -= batch_size; cond_resched(); } -- 1.7.5.1 From dave@fromorbit.com Thu Jun 2 02:01:48 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271l5J180579 for ; Thu, 2 Jun 2011 02:01:48 -0500 X-ASG-Debug-ID: 1306998103-1bb100de0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D3FFD1ED1909 for ; Thu, 2 Jun 2011 00:01:45 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id UaWFcLua5hmuLZsL for ; Thu, 02 Jun 2011 00:01:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUDAAky5015LCoegWdsb2JhbABTpjAVAQEWJiXHUIYhBKAp Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:39 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1uJ-0007ap-Ka; Thu, 02 Jun 2011 17:01:27 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1u2-0007D8-O2; Thu, 02 Jun 2011 17:01:10 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 07/12] inode: move to per-sb LRU locks Subject: [PATCH 07/12] inode: move to per-sb LRU locks Date: Thu, 2 Jun 2011 17:01:02 +1000 Message-Id: <1306998067-27659-8-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998106 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65366 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner With the inode LRUs moving to per-sb structures, there is no longer a need for a global inode_lru_lock. The locking can be made more fine-grained by moving to a per-sb LRU lock, isolating the LRU operations of different filesytsems completely from each other. Signed-off-by: Dave Chinner --- fs/inode.c | 27 +++++++++++++-------------- fs/super.c | 1 + include/linux/fs.h | 3 ++- 3 files changed, 16 insertions(+), 15 deletions(-) diff --git a/fs/inode.c b/fs/inode.c index e039115..667a29c 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -33,7 +33,7 @@ * * inode->i_lock protects: * inode->i_state, inode->i_hash, __iget() - * inode_lru_lock protects: + * inode->i_sb->s_inode_lru_lock protects: * inode->i_sb->s_inode_lru, inode->i_lru * inode_sb_list_lock protects: * sb->s_inodes, inode->i_sb_list @@ -46,7 +46,7 @@ * * inode_sb_list_lock * inode->i_lock - * inode_lru_lock + * inode->i_sb->s_inode_lru_lock * * inode_wb_list_lock * inode->i_lock @@ -64,8 +64,6 @@ static unsigned int i_hash_shift __read_mostly; static struct hlist_head *inode_hashtable __read_mostly; static __cacheline_aligned_in_smp DEFINE_SPINLOCK(inode_hash_lock); -static DEFINE_SPINLOCK(inode_lru_lock); - __cacheline_aligned_in_smp DEFINE_SPINLOCK(inode_sb_list_lock); __cacheline_aligned_in_smp DEFINE_SPINLOCK(inode_wb_list_lock); @@ -342,24 +340,24 @@ EXPORT_SYMBOL(ihold); static void inode_lru_list_add(struct inode *inode) { - spin_lock(&inode_lru_lock); + spin_lock(&inode->i_sb->s_inode_lru_lock); if (list_empty(&inode->i_lru)) { list_add(&inode->i_lru, &inode->i_sb->s_inode_lru); inode->i_sb->s_nr_inodes_unused++; this_cpu_inc(nr_unused); } - spin_unlock(&inode_lru_lock); + spin_unlock(&inode->i_sb->s_inode_lru_lock); } static void inode_lru_list_del(struct inode *inode) { - spin_lock(&inode_lru_lock); + spin_lock(&inode->i_sb->s_inode_lru_lock); if (!list_empty(&inode->i_lru)) { list_del_init(&inode->i_lru); inode->i_sb->s_nr_inodes_unused--; this_cpu_dec(nr_unused); } - spin_unlock(&inode_lru_lock); + spin_unlock(&inode->i_sb->s_inode_lru_lock); } /** @@ -608,7 +606,8 @@ static int can_unuse(struct inode *inode) /* * Scan `goal' inodes on the unused list for freeable ones. They are moved to a - * temporary list and then are freed outside inode_lru_lock by dispose_list(). + * temporary list and then are freed outside sb->s_inode_lru_lock by + * dispose_list(). * * Any inodes which are pinned purely because of attached pagecache have their * pagecache removed. If the inode has metadata buffers attached to @@ -628,7 +627,7 @@ static void shrink_icache_sb(struct super_block *sb, int *nr_to_scan) int nr_scanned; unsigned long reap = 0; - spin_lock(&inode_lru_lock); + spin_lock(&sb->s_inode_lru_lock); for (nr_scanned = *nr_to_scan; nr_scanned >= 0; nr_scanned--) { struct inode *inode; @@ -638,7 +637,7 @@ static void shrink_icache_sb(struct super_block *sb, int *nr_to_scan) inode = list_entry(sb->s_inode_lru.prev, struct inode, i_lru); /* - * we are inverting the inode_lru_lock/inode->i_lock here, + * we are inverting the sb->s_inode_lru_lock/inode->i_lock here, * so use a trylock. If we fail to get the lock, just move the * inode to the back of the list so we don't spin on it. */ @@ -670,12 +669,12 @@ static void shrink_icache_sb(struct super_block *sb, int *nr_to_scan) if (inode_has_buffers(inode) || inode->i_data.nrpages) { __iget(inode); spin_unlock(&inode->i_lock); - spin_unlock(&inode_lru_lock); + spin_unlock(&sb->s_inode_lru_lock); if (remove_inode_buffers(inode)) reap += invalidate_mapping_pages(&inode->i_data, 0, -1); iput(inode); - spin_lock(&inode_lru_lock); + spin_lock(&sb->s_inode_lru_lock); if (inode != list_entry(sb->s_inode_lru.next, struct inode, i_lru)) @@ -700,7 +699,7 @@ static void shrink_icache_sb(struct super_block *sb, int *nr_to_scan) __count_vm_events(KSWAPD_INODESTEAL, reap); else __count_vm_events(PGINODESTEAL, reap); - spin_unlock(&inode_lru_lock); + spin_unlock(&sb->s_inode_lru_lock); *nr_to_scan = nr_scanned; dispose_list(&freeable); diff --git a/fs/super.c b/fs/super.c index ef7caf7..9c3fa1f 100644 --- a/fs/super.c +++ b/fs/super.c @@ -78,6 +78,7 @@ static struct super_block *alloc_super(struct file_system_type *type) INIT_LIST_HEAD(&s->s_inodes); INIT_LIST_HEAD(&s->s_dentry_lru); INIT_LIST_HEAD(&s->s_inode_lru); + spin_lock_init(&s->s_inode_lru_lock); init_rwsem(&s->s_umount); mutex_init(&s->s_lock); lockdep_set_class(&s->s_umount, &type->s_umount_key); diff --git a/include/linux/fs.h b/include/linux/fs.h index a96071d..bbd478e 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1393,7 +1393,8 @@ struct super_block { struct list_head s_dentry_lru; /* unused dentry lru */ int s_nr_dentry_unused; /* # of dentry on lru */ - /* inode_lru_lock protects s_inode_lru and s_nr_inodes_unused */ + /* s_inode_lru_lock protects s_inode_lru and s_nr_inodes_unused */ + spinlock_t s_inode_lru_lock ____cacheline_aligned_in_smp; struct list_head s_inode_lru; /* unused inode lru */ int s_nr_inodes_unused; /* # of inodes on lru */ -- 1.7.5.1 From dave@fromorbit.com Thu Jun 2 02:01:50 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,LOCAL_GNU_PATCH autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271nqA180604 for ; Thu, 2 Jun 2011 02:01:49 -0500 X-ASG-Debug-ID: 1306998102-76f902870002-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 682ED1ED190D for ; Thu, 2 Jun 2011 00:01:46 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id tk2FGOLHYEq8HN7u for ; Thu, 02 Jun 2011 00:01:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYDAAky5015LCoegWdsb2JhbABThEmhZxUBARYmJbZukGKBK4NsgQoEoCk Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:39 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1uJ-0007as-Lz; Thu, 02 Jun 2011 17:01:27 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1u2-0007DA-Qc; Thu, 02 Jun 2011 17:01:10 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: =?UTF-8?q?=5BPATCH=2008/12=5D=20superblock=3A=20introduce=20per-sb=20cache=20shrinker=20infrastructure?= Subject: =?UTF-8?q?=5BPATCH=2008/12=5D=20superblock=3A=20introduce=20per-sb=20cache=20shrinker=20infrastructure?= Date: Thu, 2 Jun 2011 17:01:03 +1000 Message-Id: <1306998067-27659-9-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998108 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65366 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner With context based shrinkers, we can implement a per-superblock shrinker that shrinks the caches attached to the superblock. We currently have global shrinkers for the inode and dentry caches that split up into per-superblock operations via a coarse proportioning method that does not batch very well. The global shrinkers also have a dependency - dentries pin inodes - so we have to be very careful about how we register the global shrinkers so that the implicit call order is always correct. With a per-sb shrinker callout, we can encode this dependency directly into the per-sb shrinker, hence avoiding the need for strictly ordering shrinker registrations. We also have no need for any proportioning code for the shrinker subsystem already provides this functionality across all shrinkers. Allowing the shrinker to operate on a single superblock at a time means that we do less superblock list traversals and locking and reclaim should batch more effectively. This should result in less CPU overhead for reclaim and potentially faster reclaim of items from each filesystem. Signed-off-by: Dave Chinner --- fs/dcache.c | 121 +++++---------------------------------------------- fs/inode.c | 117 ++++---------------------------------------------- fs/super.c | 55 +++++++++++++++++++++++- include/linux/fs.h | 7 +++ 4 files changed, 82 insertions(+), 218 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 37f72ee..f73ef23 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -720,13 +720,11 @@ static void shrink_dentry_list(struct list_head *list) * * If flags contains DCACHE_REFERENCED reference dentries will not be pruned. */ -static void __shrink_dcache_sb(struct super_block *sb, int *count, int flags) +static void __shrink_dcache_sb(struct super_block *sb, int count, int flags) { - /* called from prune_dcache() and shrink_dcache_parent() */ struct dentry *dentry; LIST_HEAD(referenced); LIST_HEAD(tmp); - int cnt = *count; relock: spin_lock(&dcache_lru_lock); @@ -754,7 +752,7 @@ relock: } else { list_move_tail(&dentry->d_lru, &tmp); spin_unlock(&dentry->d_lock); - if (!--cnt) + if (!--count) break; } cond_resched_lock(&dcache_lru_lock); @@ -764,83 +762,22 @@ relock: spin_unlock(&dcache_lru_lock); shrink_dentry_list(&tmp); - - *count = cnt; } /** - * prune_dcache - shrink the dcache - * @count: number of entries to try to free + * prune_dcache_sb - shrink the dcache + * @nr_to_scan: number of entries to try to free * - * Shrink the dcache. This is done when we need more memory, or simply when we - * need to unmount something (at which point we need to unuse all dentries). + * Attempt to shrink the superblock dcache LRU by @nr_to_scan entries. This is + * done when we need more memory an called from the superblock shrinker + * function. * - * This function may fail to free any resources if all the dentries are in use. + * This function may fail to free any resources if all the dentries are in + * use. */ -static void prune_dcache(int count) +void prune_dcache_sb(struct super_block *sb, int nr_to_scan) { - struct super_block *sb, *p = NULL; - int w_count; - int unused = dentry_stat.nr_unused; - int prune_ratio; - int pruned; - - if (unused == 0 || count == 0) - return; - if (count >= unused) - prune_ratio = 1; - else - prune_ratio = unused / count; - spin_lock(&sb_lock); - list_for_each_entry(sb, &super_blocks, s_list) { - if (list_empty(&sb->s_instances)) - continue; - if (sb->s_nr_dentry_unused == 0) - continue; - sb->s_count++; - /* Now, we reclaim unused dentrins with fairness. - * We reclaim them same percentage from each superblock. - * We calculate number of dentries to scan on this sb - * as follows, but the implementation is arranged to avoid - * overflows: - * number of dentries to scan on this sb = - * count * (number of dentries on this sb / - * number of dentries in the machine) - */ - spin_unlock(&sb_lock); - if (prune_ratio != 1) - w_count = (sb->s_nr_dentry_unused / prune_ratio) + 1; - else - w_count = sb->s_nr_dentry_unused; - pruned = w_count; - /* - * We need to be sure this filesystem isn't being unmounted, - * otherwise we could race with generic_shutdown_super(), and - * end up holding a reference to an inode while the filesystem - * is unmounted. So we try to get s_umount, and make sure - * s_root isn't NULL. - */ - if (down_read_trylock(&sb->s_umount)) { - if ((sb->s_root != NULL) && - (!list_empty(&sb->s_dentry_lru))) { - __shrink_dcache_sb(sb, &w_count, - DCACHE_REFERENCED); - pruned -= w_count; - } - up_read(&sb->s_umount); - } - spin_lock(&sb_lock); - if (p) - __put_super(p); - count -= pruned; - p = sb; - /* more work left to do? */ - if (count <= 0) - break; - } - if (p) - __put_super(p); - spin_unlock(&sb_lock); + __shrink_dcache_sb(sb, nr_to_scan, DCACHE_REFERENCED); } /** @@ -1215,42 +1152,10 @@ void shrink_dcache_parent(struct dentry * parent) int found; while ((found = select_parent(parent)) != 0) - __shrink_dcache_sb(sb, &found, 0); + __shrink_dcache_sb(sb, found, 0); } EXPORT_SYMBOL(shrink_dcache_parent); -/* - * Scan `sc->nr_slab_to_reclaim' dentries and return the number which remain. - * - * We need to avoid reentering the filesystem if the caller is performing a - * GFP_NOFS allocation attempt. One example deadlock is: - * - * ext2_new_block->getblk->GFP->shrink_dcache_memory->prune_dcache-> - * prune_one_dentry->dput->dentry_iput->iput->inode->i_sb->s_op->put_inode-> - * ext2_discard_prealloc->ext2_free_blocks->lock_super->DEADLOCK. - * - * In this case we return -1 to tell the caller that we baled. - */ -static int shrink_dcache_memory(struct shrinker *shrink, - struct shrink_control *sc) -{ - int nr = sc->nr_to_scan; - gfp_t gfp_mask = sc->gfp_mask; - - if (nr) { - if (!(gfp_mask & __GFP_FS)) - return -1; - prune_dcache(nr); - } - - return (dentry_stat.nr_unused / 100) * sysctl_vfs_cache_pressure; -} - -static struct shrinker dcache_shrinker = { - .shrink = shrink_dcache_memory, - .seeks = DEFAULT_SEEKS, -}; - /** * d_alloc - allocate a dcache entry * @parent: parent of entry to allocate @@ -3030,8 +2935,6 @@ static void __init dcache_init(void) */ dentry_cache = KMEM_CACHE(dentry, SLAB_RECLAIM_ACCOUNT|SLAB_PANIC|SLAB_MEM_SPREAD); - - register_shrinker(&dcache_shrinker); /* Hash may have been set up in dcache_init_early */ if (!hashdist) diff --git a/fs/inode.c b/fs/inode.c index 667a29c..890d95e 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -73,7 +73,7 @@ __cacheline_aligned_in_smp DEFINE_SPINLOCK(inode_wb_list_lock); * * We don't actually need it to protect anything in the umount path, * but only need to cycle through it to make sure any inode that - * prune_icache took off the LRU list has been fully torn down by the + * prune_icache_sb took off the LRU list has been fully torn down by the * time we are past evict_inodes. */ static DECLARE_RWSEM(iprune_sem); @@ -537,7 +537,7 @@ void evict_inodes(struct super_block *sb) dispose_list(&dispose); /* - * Cycle through iprune_sem to make sure any inode that prune_icache + * Cycle through iprune_sem to make sure any inode that prune_icache_sb * moved off the list before we took the lock has been fully torn * down. */ @@ -605,9 +605,10 @@ static int can_unuse(struct inode *inode) } /* - * Scan `goal' inodes on the unused list for freeable ones. They are moved to a - * temporary list and then are freed outside sb->s_inode_lru_lock by - * dispose_list(). + * Walk the superblock inode LRU for freeable inodes and attempt to free them. + * This is called from the superblock shrinker function with a number of inodes + * to trim from the LRU. Inodes to be freed are moved to a temporary list and + * then are freed outside inode_lock by dispose_list(). * * Any inodes which are pinned purely because of attached pagecache have their * pagecache removed. If the inode has metadata buffers attached to @@ -621,14 +622,15 @@ static int can_unuse(struct inode *inode) * LRU does not have strict ordering. Hence we don't want to reclaim inodes * with this flag set because they are the inodes that are out of order. */ -static void shrink_icache_sb(struct super_block *sb, int *nr_to_scan) +void prune_icache_sb(struct super_block *sb, int nr_to_scan) { LIST_HEAD(freeable); int nr_scanned; unsigned long reap = 0; + down_read(&iprune_sem); spin_lock(&sb->s_inode_lru_lock); - for (nr_scanned = *nr_to_scan; nr_scanned >= 0; nr_scanned--) { + for (nr_scanned = nr_to_scan; nr_scanned >= 0; nr_scanned--) { struct inode *inode; if (list_empty(&sb->s_inode_lru)) @@ -700,111 +702,11 @@ static void shrink_icache_sb(struct super_block *sb, int *nr_to_scan) else __count_vm_events(PGINODESTEAL, reap); spin_unlock(&sb->s_inode_lru_lock); - *nr_to_scan = nr_scanned; dispose_list(&freeable); -} - -static void prune_icache(int count) -{ - struct super_block *sb, *p = NULL; - int w_count; - int unused = inodes_stat.nr_unused; - int prune_ratio; - int pruned; - - if (unused == 0 || count == 0) - return; - down_read(&iprune_sem); - if (count >= unused) - prune_ratio = 1; - else - prune_ratio = unused / count; - spin_lock(&sb_lock); - list_for_each_entry(sb, &super_blocks, s_list) { - if (list_empty(&sb->s_instances)) - continue; - if (sb->s_nr_inodes_unused == 0) - continue; - sb->s_count++; - /* Now, we reclaim unused dentrins with fairness. - * We reclaim them same percentage from each superblock. - * We calculate number of dentries to scan on this sb - * as follows, but the implementation is arranged to avoid - * overflows: - * number of dentries to scan on this sb = - * count * (number of dentries on this sb / - * number of dentries in the machine) - */ - spin_unlock(&sb_lock); - if (prune_ratio != 1) - w_count = (sb->s_nr_inodes_unused / prune_ratio) + 1; - else - w_count = sb->s_nr_inodes_unused; - pruned = w_count; - /* - * We need to be sure this filesystem isn't being unmounted, - * otherwise we could race with generic_shutdown_super(), and - * end up holding a reference to an inode while the filesystem - * is unmounted. So we try to get s_umount, and make sure - * s_root isn't NULL. - */ - if (down_read_trylock(&sb->s_umount)) { - if ((sb->s_root != NULL) && - (!list_empty(&sb->s_dentry_lru))) { - shrink_icache_sb(sb, &w_count); - pruned -= w_count; - } - up_read(&sb->s_umount); - } - spin_lock(&sb_lock); - if (p) - __put_super(p); - count -= pruned; - p = sb; - /* more work left to do? */ - if (count <= 0) - break; - } - if (p) - __put_super(p); - spin_unlock(&sb_lock); up_read(&iprune_sem); } -/* - * shrink_icache_memory() will attempt to reclaim some unused inodes. Here, - * "unused" means that no dentries are referring to the inodes: the files are - * not open and the dcache references to those inodes have already been - * reclaimed. - * - * This function is passed the number of inodes to scan, and it returns the - * total number of remaining possibly-reclaimable inodes. - */ -static int shrink_icache_memory(struct shrinker *shrink, - struct shrink_control *sc) -{ - int nr = sc->nr_to_scan; - gfp_t gfp_mask = sc->gfp_mask; - - if (nr) { - /* - * Nasty deadlock avoidance. We may hold various FS locks, - * and we don't want to recurse into the FS that called us - * in clear_inode() and friends.. - */ - if (!(gfp_mask & __GFP_FS)) - return -1; - prune_icache(nr); - } - return (get_nr_inodes_unused() / 100) * sysctl_vfs_cache_pressure; -} - -static struct shrinker icache_shrinker = { - .shrink = shrink_icache_memory, - .seeks = DEFAULT_SEEKS, -}; - static void __wait_on_freeing_inode(struct inode *inode); /* * Called with the inode lock held. @@ -1684,7 +1586,6 @@ void __init inode_init(void) (SLAB_RECLAIM_ACCOUNT|SLAB_PANIC| SLAB_MEM_SPREAD), init_once); - register_shrinker(&icache_shrinker); /* Hash may have been set up in inode_init_early */ if (!hashdist) diff --git a/fs/super.c b/fs/super.c index 9c3fa1f..f4630d9 100644 --- a/fs/super.c +++ b/fs/super.c @@ -38,6 +38,50 @@ LIST_HEAD(super_blocks); DEFINE_SPINLOCK(sb_lock); +static int prune_super(struct shrinker *shrink, struct shrink_control *sc) +{ + struct super_block *sb; + int count; + + sb = container_of(shrink, struct super_block, s_shrink); + + /* + * Deadlock avoidance. We may hold various FS locks, and we don't want + * to recurse into the FS that called us in clear_inode() and friends.. + */ + if (sc->nr_to_scan && !(sc->gfp_mask & __GFP_FS)) + return -1; + + /* + * if we can't get the umount lock, then there's no point having the + * shrinker try again because the sb is being torn down. + */ + if (!down_read_trylock(&sb->s_umount)) + return -1; + + if (!sb->s_root) { + up_read(&sb->s_umount); + return -1; + } + + if (sc->nr_to_scan) { + /* proportion the scan between the two cacheÑ• */ + int total; + + total = sb->s_nr_dentry_unused + sb->s_nr_inodes_unused + 1; + count = (sc->nr_to_scan * sb->s_nr_dentry_unused) / total; + + /* prune dcache first as icache is pinned by it */ + prune_dcache_sb(sb, count); + prune_icache_sb(sb, sc->nr_to_scan - count); + } + + count = ((sb->s_nr_dentry_unused + sb->s_nr_inodes_unused) / 100) + * sysctl_vfs_cache_pressure; + up_read(&sb->s_umount); + return count; +} + /** * alloc_super - create new superblock * @type: filesystem type superblock should belong to @@ -116,6 +160,9 @@ static struct super_block *alloc_super(struct file_system_type *type) s->s_op = &default_op; s->s_time_gran = 1000000000; s->cleancache_poolid = -1; + + s->s_shrink.seeks = DEFAULT_SEEKS; + s->s_shrink.shrink = prune_super; } out: return s; @@ -278,7 +325,12 @@ void generic_shutdown_super(struct super_block *sb) { const struct super_operations *sop = sb->s_op; - + /* + * shut down the shrinker first so we know that there are no possible + * races when shrinking the dcache or icache. Removes the need for + * external locking to prevent such races. + */ + unregister_shrinker(&sb->s_shrink); if (sb->s_root) { shrink_dcache_for_umount(sb); sync_filesystem(sb); @@ -366,6 +418,7 @@ retry: list_add(&s->s_instances, &type->fs_supers); spin_unlock(&sb_lock); get_filesystem(type); + register_shrinker(&s->s_shrink); return s; } diff --git a/include/linux/fs.h b/include/linux/fs.h index bbd478e..c3b3462 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -391,6 +391,7 @@ struct inodes_stat_t { #include #include #include +#include #include #include @@ -1440,8 +1441,14 @@ struct super_block { * Saved pool identifier for cleancache (-1 means none) */ int cleancache_poolid; + + struct shrinker s_shrink; /* per-sb shrinker handle */ }; +/* superblock cache pruning functions */ +extern void prune_icache_sb(struct super_block *sb, int nr_to_scan); +extern void prune_dcache_sb(struct super_block *sb, int nr_to_scan); + extern struct timespec current_fs_time(struct super_block *sb); /* -- 1.7.5.1 From dave@fromorbit.com Thu Jun 2 02:01:49 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271mdx180591 for ; Thu, 2 Jun 2011 02:01:48 -0500 X-ASG-Debug-ID: 1306998103-1bb100de0001-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 265D51ED1909 for ; Thu, 2 Jun 2011 00:01:47 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id vHd2hKWMEjbvgMP6 for ; Thu, 02 Jun 2011 00:01:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAAky5015LCoegWdsb2JhbABTmBiOGBUBARYmJcdQhiEEmDKHdw Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:46 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1u9-0007ag-Oq; Thu, 02 Jun 2011 17:01:17 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1u2-0007DC-T1; Thu, 02 Jun 2011 17:01:10 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 09/12] inode: remove iprune_sem Subject: [PATCH 09/12] inode: remove iprune_sem Date: Thu, 2 Jun 2011 17:01:04 +1000 Message-Id: <1306998067-27659-10-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998108 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65366 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner Now that we have per-sb shrinkers and they are unregistered before evict_inode() is called, there is not longer any race condition for the iprune_sem to protect against. Hence we can remove it. Signed-off-by: Dave Chinner --- fs/inode.c | 21 --------------------- 1 files changed, 0 insertions(+), 21 deletions(-) diff --git a/fs/inode.c b/fs/inode.c index 890d95e..167adfd 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -68,17 +68,6 @@ __cacheline_aligned_in_smp DEFINE_SPINLOCK(inode_sb_list_lock); __cacheline_aligned_in_smp DEFINE_SPINLOCK(inode_wb_list_lock); /* - * iprune_sem provides exclusion between the icache shrinking and the - * umount path. - * - * We don't actually need it to protect anything in the umount path, - * but only need to cycle through it to make sure any inode that - * prune_icache_sb took off the LRU list has been fully torn down by the - * time we are past evict_inodes. - */ -static DECLARE_RWSEM(iprune_sem); - -/* * Empty aops. Can be used for the cases where the user does not * define any of the address_space operations. */ @@ -535,14 +524,6 @@ void evict_inodes(struct super_block *sb) spin_unlock(&inode_sb_list_lock); dispose_list(&dispose); - - /* - * Cycle through iprune_sem to make sure any inode that prune_icache_sb - * moved off the list before we took the lock has been fully torn - * down. - */ - down_write(&iprune_sem); - up_write(&iprune_sem); } /** @@ -628,7 +609,6 @@ void prune_icache_sb(struct super_block *sb, int nr_to_scan) int nr_scanned; unsigned long reap = 0; - down_read(&iprune_sem); spin_lock(&sb->s_inode_lru_lock); for (nr_scanned = nr_to_scan; nr_scanned >= 0; nr_scanned--) { struct inode *inode; @@ -704,7 +684,6 @@ void prune_icache_sb(struct super_block *sb, int nr_to_scan) spin_unlock(&sb->s_inode_lru_lock); dispose_list(&freeable); - up_read(&iprune_sem); } static void __wait_on_freeing_inode(struct inode *inode); -- 1.7.5.1 From dave@fromorbit.com Thu Jun 2 02:01:48 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271mrE180582 for ; Thu, 2 Jun 2011 02:01:48 -0500 X-ASG-Debug-ID: 1306998100-6c1b03390003-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A7C664963DE for ; Thu, 2 Jun 2011 00:01:46 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id ElZRxZHXDuoAcRng for ; Thu, 02 Jun 2011 00:01:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYDAAky5015LCoegWdsb2JhbABThEmhZxUBARYmJbZukGKBK4FwgXyBCgSgKQ Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:39 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1uJ-0007az-QG; Thu, 02 Jun 2011 17:01:27 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1uC-0007DF-Tk; Thu, 02 Jun 2011 17:01:20 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: =?UTF-8?q?=5BPATCH=2010/12=5D=20superblock=3A=20add=20filesystem=20shrinker=20operations?= Subject: =?UTF-8?q?=5BPATCH=2010/12=5D=20superblock=3A=20add=20filesystem=20shrinker=20operations?= Date: Thu, 2 Jun 2011 17:01:05 +1000 Message-Id: <1306998067-27659-11-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998107 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65366 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner Now we have a per-superblock shrinker implementation, we can add a filesystem specific callout to it to allow filesystem internal caches to be shrunk by the superblock shrinker. Rather than perpetuate the multipurpose shrinker callback API (i.e. nr_to_scan == 0 meaning "tell me how many objects freeable in the cache), two operations will be added. The first will return the number of objects that are freeable, the second is the actual shrinker call. Signed-off-by: Dave Chinner --- Documentation/filesystems/vfs.txt | 16 +++++++++++++ fs/super.c | 43 +++++++++++++++++++++++++++--------- include/linux/fs.h | 2 + 3 files changed, 50 insertions(+), 11 deletions(-) diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 88b9f55..dc732d2 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -229,6 +229,8 @@ struct super_operations { ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t); ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t); + int (*nr_cached_objects)(struct super_block *); + void (*free_cached_objects)(struct super_block *, int); }; All methods are called without any locks being held, unless otherwise @@ -301,6 +303,20 @@ or bottom half). quota_write: called by the VFS to write to filesystem quota file. + nr_cached_objects: called by the sb cache shrinking function for the + filesystem to return the number of freeable cached objects it contains. + Optional. + + free_cache_objects: called by the sb cache shrinking function for the + filesystem to scan the number of objects indicated to try to free them. + Optional, but any filesystem implementing this method needs to also + implement ->nr_cached_objects for it to be called correctly. + + We can't do anything with any errors that the filesystem might + encountered, hence the void return type. This will never be called if + the VM is trying to reclaim under GFP_NOFS conditions, hence this + method does not need to handle that situation itself. + Whoever sets up the inode is responsible for filling in the "i_op" field. This is a pointer to a "struct inode_operations" which describes the methods that can be performed on individual inodes. diff --git a/fs/super.c b/fs/super.c index f4630d9..b55f968 100644 --- a/fs/super.c +++ b/fs/super.c @@ -41,7 +41,8 @@ DEFINE_SPINLOCK(sb_lock); static int prune_super(struct shrinker *shrink, struct shrink_control *sc) { struct super_block *sb; - int count; + int fs_objects = 0; + int total_objects; sb = container_of(shrink, struct super_block, s_shrink); @@ -64,22 +65,42 @@ static int prune_super(struct shrinker *shrink, struct shrink_control *sc) return -1; } - if (sc->nr_to_scan) { - /* proportion the scan between the two cacheÑ• */ - int total; + if (sb->s_op && sb->s_op->nr_cached_objects) + fs_objects = sb->s_op->nr_cached_objects(sb); + + total_objects = sb->s_nr_dentry_unused + + sb->s_nr_inodes_unused + fs_objects + 1; - total = sb->s_nr_dentry_unused + sb->s_nr_inodes_unused + 1; - count = (sc->nr_to_scan * sb->s_nr_dentry_unused) / total; + if (sc->nr_to_scan) { + int dentries; + int inodes; + + /* proportion the scan between the cacheÑ• */ + dentries = (sc->nr_to_scan * sb->s_nr_dentry_unused) / + total_objects; + inodes = (sc->nr_to_scan * sb->s_nr_inodes_unused) / + total_objects; + if (fs_objects) + fs_objects = (sc->nr_to_scan * fs_objects) / + total_objects; + /* + * prune the dcache first as the icache is pinned by it, then + * prune the icache, followed by the filesystem specific caches + */ + prune_dcache_sb(sb, dentries); + prune_icache_sb(sb, inodes); - /* prune dcache first as icache is pinned by it */ - prune_dcache_sb(sb, count); - prune_icache_sb(sb, sc->nr_to_scan - count); + if (fs_objects && sb->s_op->free_cached_objects) { + sb->s_op->free_cached_objects(sb, fs_objects); + fs_objects = sb->s_op->nr_cached_objects(sb); + } + total_objects = sb->s_nr_dentry_unused + + sb->s_nr_inodes_unused + fs_objects; } - count = ((sb->s_nr_dentry_unused + sb->s_nr_inodes_unused) / 100) - * sysctl_vfs_cache_pressure; + total_objects = (total_objects / 100) * sysctl_vfs_cache_pressure; up_read(&sb->s_umount); - return count; + return total_objects; } /** diff --git a/include/linux/fs.h b/include/linux/fs.h index c3b3462..4f0ed0a 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1654,6 +1654,8 @@ struct super_operations { ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t); #endif int (*bdev_try_to_free_page)(struct super_block*, struct page*, gfp_t); + int (*nr_cached_objects)(struct super_block *); + void (*free_cached_objects)(struct super_block *, int); }; /* -- 1.7.5.1 From dave@fromorbit.com Thu Jun 2 02:01:51 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5271pes180621 for ; Thu, 2 Jun 2011 02:01:51 -0500 X-ASG-Debug-ID: 1306998102-76f902870003-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6DC021ED190E for ; Thu, 2 Jun 2011 00:01:49 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id vP1kHukR05NyRpFF for ; Thu, 02 Jun 2011 00:01:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUDAAky5015LCoegWdsb2JhbABTpjAVAQEWJiXHUIYhBKAp Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Jun 2011 16:31:48 +0930 Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.72) (envelope-from ) id 1QS1uZ-0007bX-15; Thu, 02 Jun 2011 17:01:43 +1000 Received: from dave by disappointment with local (Exim 4.76) (envelope-from ) id 1QS1uD-0007DP-17; Thu, 02 Jun 2011 17:01:21 +1000 From: Dave Chinner To: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 12/12] xfs: make use of new shrinker callout for the inode cache Subject: [PATCH 12/12] xfs: make use of new shrinker callout for the inode cache Date: Thu, 2 Jun 2011 17:01:07 +1000 Message-Id: <1306998067-27659-13-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.5.1 In-Reply-To: <1306998067-27659-1-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1306998110 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65366 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner Convert the inode reclaim shrinker to use the new per-sb shrinker operations. This allows much bigger reclaim batches to be used, and allows the XFS inode cache to be shrunk in proportion with the VFS dentry and inode caches. This avoids the problem of the VFS caches being shrunk significantly before the XFS inode cache is shrunk resulting in imbalances in the caches during reclaim. Signed-off-by: Dave Chinner --- fs/xfs/linux-2.6/xfs_super.c | 26 ++++++++++----- fs/xfs/linux-2.6/xfs_sync.c | 71 ++++++++++++++++-------------------------- fs/xfs/linux-2.6/xfs_sync.h | 5 +-- 3 files changed, 46 insertions(+), 56 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_super.c b/fs/xfs/linux-2.6/xfs_super.c index 1e3a7ce..b133b69 100644 --- a/fs/xfs/linux-2.6/xfs_super.c +++ b/fs/xfs/linux-2.6/xfs_super.c @@ -1087,11 +1087,6 @@ xfs_fs_put_super( { struct xfs_mount *mp = XFS_M(sb); - /* - * Unregister the memory shrinker before we tear down the mount - * structure so we don't have memory reclaim racing with us here. - */ - xfs_inode_shrinker_unregister(mp); xfs_syncd_stop(mp); /* @@ -1491,8 +1486,6 @@ xfs_fs_fill_super( if (error) goto out_filestream_unmount; - xfs_inode_shrinker_register(mp); - error = xfs_mountfs(mp); if (error) goto out_syncd_stop; @@ -1515,7 +1508,6 @@ xfs_fs_fill_super( return 0; out_syncd_stop: - xfs_inode_shrinker_unregister(mp); xfs_syncd_stop(mp); out_filestream_unmount: xfs_filestream_unmount(mp); @@ -1540,7 +1532,6 @@ xfs_fs_fill_super( } fail_unmount: - xfs_inode_shrinker_unregister(mp); xfs_syncd_stop(mp); /* @@ -1566,6 +1557,21 @@ xfs_fs_mount( return mount_bdev(fs_type, flags, dev_name, data, xfs_fs_fill_super); } +static int +xfs_fs_nr_cached_objects( + struct super_block *sb) +{ + return xfs_reclaim_inodes_count(XFS_M(sb)); +} + +static void +xfs_fs_free_cached_objects( + struct super_block *sb, + int nr_to_scan) +{ + xfs_reclaim_inodes_nr(XFS_M(sb), nr_to_scan); +} + static const struct super_operations xfs_super_operations = { .alloc_inode = xfs_fs_alloc_inode, .destroy_inode = xfs_fs_destroy_inode, @@ -1579,6 +1585,8 @@ static const struct super_operations xfs_super_operations = { .statfs = xfs_fs_statfs, .remount_fs = xfs_fs_remount, .show_options = xfs_fs_show_options, + .nr_cached_objects = xfs_fs_nr_cached_objects, + .free_cached_objects = xfs_fs_free_cached_objects, }; static struct file_system_type xfs_fs_type = { diff --git a/fs/xfs/linux-2.6/xfs_sync.c b/fs/xfs/linux-2.6/xfs_sync.c index 8ecad5f..9bd7e89 100644 --- a/fs/xfs/linux-2.6/xfs_sync.c +++ b/fs/xfs/linux-2.6/xfs_sync.c @@ -179,6 +179,8 @@ restart: if (error == EFSCORRUPTED) break; + cond_resched(); + } while (nr_found && !done); if (skipped) { @@ -986,6 +988,8 @@ restart: *nr_to_scan -= XFS_LOOKUP_BATCH; + cond_resched(); + } while (nr_found && !done && *nr_to_scan > 0); if (trylock && !done) @@ -1003,7 +1007,7 @@ restart: * ensure that when we get more reclaimers than AGs we block rather * than spin trying to execute reclaim. */ - if (trylock && skipped && *nr_to_scan > 0) { + if (skipped && (flags & SYNC_WAIT) && *nr_to_scan > 0) { trylock = 0; goto restart; } @@ -1021,44 +1025,38 @@ xfs_reclaim_inodes( } /* - * Inode cache shrinker. + * Scan a certain number of inodes for reclaim. * * When called we make sure that there is a background (fast) inode reclaim in - * progress, while we will throttle the speed of reclaim via doiing synchronous + * progress, while we will throttle the speed of reclaim via doing synchronous * reclaim of inodes. That means if we come across dirty inodes, we wait for * them to be cleaned, which we hope will not be very long due to the * background walker having already kicked the IO off on those dirty inodes. */ -static int -xfs_reclaim_inode_shrink( - struct shrinker *shrink, - struct shrink_control *sc) +void +xfs_reclaim_inodes_nr( + struct xfs_mount *mp, + int nr_to_scan) { - struct xfs_mount *mp; - struct xfs_perag *pag; - xfs_agnumber_t ag; - int reclaimable; - int nr_to_scan = sc->nr_to_scan; - gfp_t gfp_mask = sc->gfp_mask; - - mp = container_of(shrink, struct xfs_mount, m_inode_shrink); - if (nr_to_scan) { - /* kick background reclaimer and push the AIL */ - xfs_syncd_queue_reclaim(mp); - xfs_ail_push_all(mp->m_ail); + /* kick background reclaimer and push the AIL */ + xfs_syncd_queue_reclaim(mp); + xfs_ail_push_all(mp->m_ail); - if (!(gfp_mask & __GFP_FS)) - return -1; + xfs_reclaim_inodes_ag(mp, SYNC_TRYLOCK | SYNC_WAIT, &nr_to_scan); +} - xfs_reclaim_inodes_ag(mp, SYNC_TRYLOCK | SYNC_WAIT, - &nr_to_scan); - /* terminate if we don't exhaust the scan */ - if (nr_to_scan > 0) - return -1; - } +/* + * Return the number of reclaimable inodes in the filesystem for + * the shrinker to determine how much to reclaim. + */ +int +xfs_reclaim_inodes_count( + struct xfs_mount *mp) +{ + struct xfs_perag *pag; + xfs_agnumber_t ag = 0; + int reclaimable = 0; - reclaimable = 0; - ag = 0; while ((pag = xfs_perag_get_tag(mp, ag, XFS_ICI_RECLAIM_TAG))) { ag = pag->pag_agno + 1; reclaimable += pag->pag_ici_reclaimable; @@ -1067,18 +1065,3 @@ xfs_reclaim_inode_shrink( return reclaimable; } -void -xfs_inode_shrinker_register( - struct xfs_mount *mp) -{ - mp->m_inode_shrink.shrink = xfs_reclaim_inode_shrink; - mp->m_inode_shrink.seeks = DEFAULT_SEEKS; - register_shrinker(&mp->m_inode_shrink); -} - -void -xfs_inode_shrinker_unregister( - struct xfs_mount *mp) -{ - unregister_shrinker(&mp->m_inode_shrink); -} diff --git a/fs/xfs/linux-2.6/xfs_sync.h b/fs/xfs/linux-2.6/xfs_sync.h index e3a6ad2..2e15685 100644 --- a/fs/xfs/linux-2.6/xfs_sync.h +++ b/fs/xfs/linux-2.6/xfs_sync.h @@ -43,6 +43,8 @@ void xfs_quiesce_attr(struct xfs_mount *mp); void xfs_flush_inodes(struct xfs_inode *ip); int xfs_reclaim_inodes(struct xfs_mount *mp, int mode); +int xfs_reclaim_inodes_count(struct xfs_mount *mp); +void xfs_reclaim_inodes_nr(struct xfs_mount *mp, int nr_to_scan); void xfs_inode_set_reclaim_tag(struct xfs_inode *ip); void __xfs_inode_set_reclaim_tag(struct xfs_perag *pag, struct xfs_inode *ip); @@ -54,7 +56,4 @@ int xfs_inode_ag_iterator(struct xfs_mount *mp, int (*execute)(struct xfs_inode *ip, struct xfs_perag *pag, int flags), int flags); -void xfs_inode_shrinker_register(struct xfs_mount *mp); -void xfs_inode_shrinker_unregister(struct xfs_mount *mp); - #endif -- 1.7.5.1 From amir73il@gmail.com Thu Jun 2 02:11:45 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p527BjII181056 for ; Thu, 2 Jun 2011 02:11:45 -0500 X-ASG-Debug-ID: 1306998703-76f702c10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ww0-f51.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AC7F31ED1ED6 for ; Thu, 2 Jun 2011 00:11:43 -0700 (PDT) Received: from mail-ww0-f51.google.com (mail-ww0-f51.google.com [74.125.82.51]) by cuda.sgi.com with ESMTP id NISbf3XJK6qPVBSB for ; Thu, 02 Jun 2011 00:11:43 -0700 (PDT) Received: by wwf26 with SMTP id 26so455579wwf.32 for ; Thu, 02 Jun 2011 00:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dL8QxmGZ6VCG4aUhYiToq7L3nTMbjdXvPBvEUtWBGT4=; b=pOBXHOLTd5Z+G6j4bFBa+PLU9AaDzbYRut7uoQ8rNK9YB+2wjELEnPh+cJVuxcDHzl /xmm/OE5C7P5JW/MIskoYBLa2wNMP5tZuKJsTZ14Pn5GIU/8AkZYJzr2oYtezfZ0btNI 9V/kceNks7/Y7A3UUtSUnaDM7kPdWQ+ZJmIGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=gb3VzPKiiSDgGd4YnyCuTj6zljZDiKAeJ4WiwoTZ4yECpYcYBqcjoaOSuuNDMk3jXM XycXsZDCI4t6lWStKFqn5w0ZKKJTnwu2P74Y5IvwKgWMV2CPwtO0clzsN0FGzcBGgfAE OXemI86dexZQvXDhmJuBbtNf7LenYQ6wjxMio= MIME-Version: 1.0 Received: by 10.216.58.207 with SMTP id q57mr341351wec.63.1306998703278; Thu, 02 Jun 2011 00:11:43 -0700 (PDT) Sender: amir73il@gmail.com Received: by 10.216.221.135 with HTTP; Thu, 2 Jun 2011 00:11:43 -0700 (PDT) In-Reply-To: <20110602064040.GS561@dastard> References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <20110602030802.GR561@dastard> <20110602064040.GS561@dastard> Date: Thu, 2 Jun 2011 10:11:43 +0300 X-Google-Sender-Auth: rIoKrke668ApguAmniO_Roldo-E Message-ID: X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP From: "Amir G." To: Dave Chinner Cc: xfs@oss.sgi.com, sandeen@redhat.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-ww0-f51.google.com[74.125.82.51] X-Barracuda-Start-Time: 1306998704 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65366 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 2, 2011 at 9:40 AM, Dave Chinner wrote: > On Thu, Jun 02, 2011 at 06:49:20AM +0300, Amir G. wrote: >> On Thu, Jun 2, 2011 at 6:08 AM, Dave Chinner wrote= : >> > On Thu, Jun 02, 2011 at 05:33:34AM +0300, Amir G. wrote: >> >> On Thu, Jun 2, 2011 at 5:16 AM, Amir G. wrote: >> >> > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner = wrote: >> > Personally I think that ext4dev shouldn't be supported at all. A >> > special fstyp iwhile ext4 was being developed was, IMO, a stupid >> > thing to do in the first place, and I was happy when it died. It >> > should not be resurrected and propagated. >> > >> > xfstests assumes that you are using a userspace that is current with >> > the version of the filesystem the kernel supports. If you are >> > running a development/special branch of ext4, then you need to be >> > running a userspace that understands it completely. If all you are >> > doing with the ext4dev fstyp is trying to vector to a different fsck >> > program that supports a new set of feature bits, then IMO you are >> > doing it all wrong. >> > >> > Fundamentally, the filesystem is either ext4 or it isn't. If the >> > features are never going to make it into mainline ext4, then you >> > need a completely different fstype and full userspace support for >> > that fstype. Once you have that, you can add the fstype support to >> > xfstests. However, just using a different fstyp just to set a >> > certain set of feature flags is, again IMO, a pretty stupid way of >> > going about this. >> > >> >> The features are going into mainline, but are not there yet. > > So using feature bits as they were intended is the right thing to > do, isn't it? I am not sure what you mean by that. The fact that to this day fsck.ext2/3/4 have always been the same file (hence support the same feature set) does not mean that they have to be that way by design. on my test system fsck.ext4dev must be used to test ext4dev, which has newer features than ext4. I fail to see the problem with that. > >> I did not invent the ext4dev standard, which is pretty well supported >> by all relevant tools, but I find it very convenient for the testing. > > As I understand it, ext4dev is deprecated and should not be used for > any new filesystems. When did that status change? > > Or did you just start using it because it's convenient for your > purposes? =A0What happens when someone else decides to use ext4dev for > testing incompatible development features because it is convenient > for them? > The way I see it, ext4dev is a tool for ext4 developers (and testers). Anyone can use it for their own needs and it would be convenient for everyo= ne. I never suggested that Fedora push my ext4dev utils as a standard package. But me and my group can use it to test the snapshots feature and Ted and his group can use it to test the allocation clusters feature. >> Especially, when I expect my testers to be running a stable >> distro release (i.e. F15 or Ubuntu 11.4) and be able to install >> my experimental ext4dev module and utils, without it affecting >> their (most likely) root ext4/ext3 fs. > > So get them to use an ext3, XFS, reiser or JFS root filesystem if > that's your major concern. That's long been a best practice for > configuring a filesystem test box - don't use the same filesystem > for your root/stable filesystems as the filesytsem you are testing. > > e.g. If you pick ext3 for the root filesystem, then you can test > ext4, btrfs, xfs, etc changes without having to worry about whether > the development module being tested is going to affect your root > filesystem.... You make it sound as if I have a flock of testers out there waiting for me to feed them with use cases to test and who abide to my setup instructions. Wake up call! this is not the case for me and for most developers. If I'm lucky, I can get a e few testers who will say: OK, if all I have to do is download this package and run 'make test' I can spare an hour to play with it. So, yes, it's true. There are other ways to accomplish what I am doing, but I am going out of my way to try to make the life of developers and test= ers easier and you are doing the exact opposite by raising objections to a rath= er trivial and harmless patch. Let me ask you this: which FSTYP will be useful to more developers ext4dev or reiserfs? > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > From amir73il@gmail.com Thu Jun 2 02:16:51 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_62,J_CHICKENPOX_65,J_CHICKENPOX_66,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p527GoZe181299 for ; Thu, 2 Jun 2011 02:16:51 -0500 X-ASG-Debug-ID: 1306999008-615a026a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ww0-f51.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F229F15DAB52 for ; Thu, 2 Jun 2011 00:16:48 -0700 (PDT) Received: from mail-ww0-f51.google.com (mail-ww0-f51.google.com [74.125.82.51]) by cuda.sgi.com with ESMTP id cOEGgbVnwF9MMFbi for ; Thu, 02 Jun 2011 00:16:48 -0700 (PDT) Received: by wwf26 with SMTP id 26so458122wwf.32 for ; Thu, 02 Jun 2011 00:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ndzUcD+J+Y063EdSku+q83J+cxevrK/zWStWkiBeVN4=; b=AtKRnm5+OWkaRxtyaq5McOLZEyt6MI8DemVE3zdss/kyIcpsRL6un1ft73F7LJOgQk Hm6D4jXTRIntXDOif5Dk+GlleJkVl9Q3fxcpIL5hHL/KdiS7Qx7Ry6+ngB8d4leYA3IJ +Pgk21atNhIX2aMqzC4m9yQcx+vKlINZ20WF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=QbcZpeNebxKX4sc7dfbkrrx/Zi1B7veiANmjj+yN8WtsbLFlfVviSUvkIcG4BK29hy Vrke6tVNlTDuZRpdInsN9ymCLoC4YjXmc8AvxnNg4FcNs1U0O/IJYgUacd2DRRLylQ1a /3H8dAEXbJaF8LY/yGAPUzCmIpc+L4WHglCJI= MIME-Version: 1.0 Received: by 10.216.232.146 with SMTP id n18mr340977weq.93.1306999008167; Thu, 02 Jun 2011 00:16:48 -0700 (PDT) Sender: amir73il@gmail.com Received: by 10.216.221.135 with HTTP; Thu, 2 Jun 2011 00:16:48 -0700 (PDT) In-Reply-To: References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> Date: Thu, 2 Jun 2011 10:16:48 +0300 X-Google-Sender-Auth: o3t7vBnIRy7BlEMrQH41g73Dv6k Message-ID: X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP From: "Amir G." To: Dave Chinner Cc: xfs@oss.sgi.com, sandeen@redhat.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-ww0-f51.google.com[74.125.82.51] X-Barracuda-Start-Time: 1306999009 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65367 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 2, 2011 at 5:33 AM, Amir G. wr= ote: > On Thu, Jun 2, 2011 at 5:16 AM, Amir G. = wrote: >> On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner wrote= : >>> On Wed, Jun 01, 2011 at 03:56:52PM +0300, amir73il@users.sourceforge.ne= t wrote: >>>> From: Amir Goldstein >>>> >>>> From: Amir Goldstein >>>> >>>> blkid knows to identify the ext4dev FSTYP of a partition that was >>>> formatted with mkfs.ext4dev. >>>> quota tools and various util-linux utils are also aware of ext4dev, >>>> so ext4dev shares the same capabilities as ext4. >>>> >>>> Signed-off-by: Amir Goldstein >>>> Tested-by: Sergey Ivanov >>>> --- >>>> ext4dev is used to test experimental ext4 code in mutual existance >>>> with production ext4 code on the same system. >>>> >>>> Specifically, ext4 snapshots code is available for testing as a >>>> stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4 >>>> (see http://next3.sf.net). >>>> >>>> v1 -> v2: >>>> - undo change of fsck -t $FSTYP to fsck.$FSTYP >>>> >>>> =A0common.defrag | =A0 =A02 +- >>>> =A0common.quota =A0| =A0 =A04 ++-- >>>> =A0common.rc =A0 =A0 | =A0 10 +++++----- >>>> =A03 files changed, 8 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/common.defrag b/common.defrag >>>> index 1bcf01d..4850803 100644 >>>> --- a/common.defrag >>>> +++ b/common.defrag >>>> @@ -26,7 +26,7 @@ _require_defrag() >>>> =A0 =A0 =A0xfs) >>>> =A0 =A0 =A0 =A0 =A0DEFRAG_PROG=3D/usr/sbin/xfs_fsr >>>> =A0 =A0 =A0 ;; >>>> - =A0 =A0ext4) >>>> + =A0 =A0ext4|ext4dev) >>>> =A0 =A0 =A0 =A0 =A0DEFRAG_PROG=3D/usr/bin/e4defrag >>>> =A0 =A0 =A0 ;; >>>> =A0 =A0 =A0*) >>>> diff --git a/common.quota b/common.quota >>>> index 3c87ce1..b6d5f16 100644 >>>> --- a/common.quota >>>> +++ b/common.quota >>>> @@ -29,7 +29,7 @@ _require_quota() >>>> =A0 =A0 =A0[ -n $QUOTA_PROG ] || _notrun "Quota user tools not install= ed" >>>> >>>> =A0 =A0 =A0case $FSTYP in >>>> - =A0 =A0ext2|ext3|ext4|reiserfs) >>>> + =A0 =A0ext2|ext3|ext4|ext4dev|reiserfs) >>>> =A0 =A0 =A0 if [ ! -d /proc/sys/fs/quota ]; then >>>> =A0 =A0 =A0 =A0 =A0 _notrun "Installed kernel does not support quotas" >>>> =A0 =A0 =A0 fi >>>> @@ -237,7 +237,7 @@ _check_quota_usage() >>>> =A0 =A0 =A0 # Sync to get delalloc to disk >>>> =A0 =A0 =A0 sync >>>> =A0 =A0 =A0 VFS_QUOTA=3D0 >>>> - =A0 =A0 if [ $FSTYP =3D "ext2" -o $FSTYP =3D "ext3" -o $FSTYP =3D "e= xt4" -o $FSTYP =3D "reiserfs" ]; then >>>> + =A0 =A0 if [ $FSTYP =3D "ext2" -o $FSTYP =3D "ext3" -o $FSTYP =3D "e= xt4" -o $FSTYP =3D "ext4dev" -o $FSTYP =3D "reiserfs" ]; then >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 VFS_QUOTA=3D1 >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 quotaon -f -u -g $SCRATCH_MNT 2>/dev/null >>>> =A0 =A0 =A0 fi >>> >>> Perhaps this should be changes to a case statement? >>> >> >> you're making me go to v3 in such a trivial patch, but ok, I'll do it ;-= ) >> > > I rechecked the fsck -t ext4dev vs. fsck.ext4dev. > fsck -t ext4dev doesn't work for me :-( > Sergey has a newer version of =A0util-linux-ng > see: > > amir@qalab:~/xfstests$ sudo fsck -t ext4dev -nf /dev/sda5 > fsck from util-linux-ng 2.17.2 > e2fsck 1.41.14 (22-Dec-2010) > /dev/sda5 has unsupported feature(s): FEATURE_C7 FEATURE_C8 FEATURE_R7 > e2fsck: Get a newer version of e2fsck! OK, after upgrading to newer util-linux and building it from git, which also didn't help, I finally found who to blame - me. I had an old (noauto) entry in /etc/fstab which claimed that /dev/sda5 is e= xt4. fsck was picking up that entry and insisting that /dev/sda5 is ext4 (regardless of what it really is) blkid isn't doing that silly thing. Amir From ahatch@psdschools.org Thu Jun 2 03:47:47 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.1 required=5.0 tests=BAYES_50,HTML_MESSAGE, MIME_8BIT_HEADER autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p528lkuk185114 for ; Thu, 2 Jun 2011 03:47:47 -0500 X-ASG-Debug-ID: 1307004464-1bb203700000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from psdschools.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A7A38167B3CF for ; Thu, 2 Jun 2011 01:47:45 -0700 (PDT) Received: from psdschools.org (mailcluster.psdschools.org [164.104.65.30]) by cuda.sgi.com with ESMTP id 0gsD1pu2qneHcjt5 for ; Thu, 02 Jun 2011 01:47:45 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from oss.sgi.com ([164.104.196.45]) by sw01.psdschools.org for ; Thu, 02 Jun 2011 02:47:45 -0600 Received: from ([164.104.196.58]) by im01.psdschools.org with ESMTP with TLS id 9ST19K1.53795755; Thu, 02 Jun 2011 02:45:23 -0600 Received: from EXCH2.psdschools.org (164.104.196.52) by EDGE1.psdschools.org (164.104.196.58) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 2 Jun 2011 02:45:09 -0600 Received: from EXCHSTAFF.psdschools.org ([fe80::dd62:5dac:7107:f0d2]) by EXCH2.psdschools.org ([2002:a468:c434::a468:c434]) with mapi; Thu, 2 Jun 2011 02:45:22 -0600 From: "Hatch, Amy - FCH" To: "info@webmail.org" Date: Thu, 2 Jun 2011 02:45:21 -0600 X-ASG-Orig-Subj: =?windows-1256?Q?Keeping_track_of_your_usage=FE?= Subject: =?windows-1256?Q?Keeping_track_of_your_usage=FE?= Thread-Topic: =?windows-1256?Q?Keeping_track_of_your_usage=FE?= Thread-Index: AQHMIQFoqNJ25t0qlUiYRfOPktyiFQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F7C87F511A5C4541A4A981058ECF1F02019DF7B3EEC9EXCHSTAFFps_" MIME-Version: 1.0 X-Barracuda-Connect: mailcluster.psdschools.org[164.104.65.30] X-Barracuda-Start-Time: 1307004465 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --_000_F7C87F511A5C4541A4A981058ECF1F02019DF7B3EEC9EXCHSTAFFps_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable A Computer Database Maintenance is currently going on our Web mail Message Center. Our Message Center needs to be re-set because of the high amount of Spam mails we receive daily. A Quarantine Maintenance will help us prevent this everyday dilemma. To re-validate your mailbox Please: Click Here Failure to re-validate your mailbox will render your e-mail in-active from our database. Thanks System Administrator --_000_F7C87F511A5C4541A4A981058ECF1F02019DF7B3EEC9EXCHSTAFFps_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
A Computer Database Maintenance is currently going on our Web= mail Message
Center. Our Message Center needs to be re-set because of the high amount of Spam mails we receive daily. A Quarantine Maintenance will help us
prevent this everyday dilemma.
To re-validate your mailbox Please:

Click Here

Failure to re-validate your mailbox will render your e-mail in-active from<= br> our database.
Thanks
System Administrator
--_000_F7C87F511A5C4541A4A981058ECF1F02019DF7B3EEC9EXCHSTAFFps_-- From nikai@nikai.net Thu Jun 2 04:31:12 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p529VCqf186667 for ; Thu, 2 Jun 2011 04:31:12 -0500 X-ASG-Debug-ID: 1307007070-4a1c032b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from webhosting01.bon.m2soft.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DD7D44964E4 for ; Thu, 2 Jun 2011 02:31:10 -0700 (PDT) Received: from webhosting01.bon.m2soft.com (webhosting01.bon.m2soft.com [195.38.20.32]) by cuda.sgi.com with ESMTP id 2Jv6X7A2eVBNO4i6 for ; Thu, 02 Jun 2011 02:31:10 -0700 (PDT) Received: from absol.kitzblitz (85-127-38-186.dynamic.xdsl-line.inode.at [85.127.38.186]) (authenticated bits=0) by webhosting01.bon.m2soft.com (8.13.8/8.13.8) with ESMTP id p529MmQ8002561; Thu, 2 Jun 2011 11:22:49 +0200 Date: Thu, 2 Jun 2011 11:30:26 +0200 From: Nicolas Kaiser To: Dave Chinner Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 11/12] vfs: increase shrinker batch size Subject: Re: [PATCH 11/12] vfs: increase shrinker batch size Message-ID: <20110602113026.7291b1a7@absol.kitzblitz> In-Reply-To: <1306998067-27659-12-git-send-email-david@fromorbit.com> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> <1306998067-27659-12-git-send-email-david@fromorbit.com> Organization: - Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAAAXNSR0IArs4c6QAAAAZQTFRF AJnV/f/88sgWwwAAAKNJREFUGNM10LENwyAQheFHKCgZgTVSRHI2gy5reROTDSiREvnyHhdXnwXS+ T+ACJgBYTiGSmDDOTdR7XDeTi9ksxEcoKFcTOCJLO7kC5SWFjPZCR69nI9+x5u6OJM1RN5UYUiNKa ZRpHHUoqh1v8hKEZ1FSGCrYOvgVmxd9DIXcSJwLTycm7bj0e4wkJGB48w/FckAwUKl/OGDZAcqItk BU+wHXLqKsjYyPeMAAAAASUVORK5CYII= X-Mailer: Claws Mail (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Barracuda-Connect: webhosting01.bon.m2soft.com[195.38.20.32] X-Barracuda-Start-Time: 1307007070 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65376 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Just noticed below two typos. * Dave Chinner : > From: Dave Chinner > > Now that the per-sb shrinker is responsible for shrinking 2 or more > caches, increase the batch size to keep econmies of scale for economies (..) > Documentation/filesystems/vfs.txt | 5 +++++ > fs/super.c | 1 + > 2 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt > index dc732d2..2e26973 100644 > --- a/Documentation/filesystems/vfs.txt > +++ b/Documentation/filesystems/vfs.txt > @@ -317,6 +317,11 @@ or bottom half). > the VM is trying to reclaim under GFP_NOFS conditions, hence this > method does not need to handle that situation itself. > > + Implementations must include conditional reschedule calls inside any > + scanning loop that is done. This allows the VFS to determine > + appropriate scan batch sizes without having to worry about whether > + implementations will cause holdoff problems due ot large batch sizes. due to Best regards, Nicolas Kaiser From lczerner@redhat.com Thu Jun 2 07:10:24 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p52CANtC197044 for ; Thu, 2 Jun 2011 07:10:24 -0500 X-ASG-Debug-ID: 1307016622-0483030f0000-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 708BC167E5AE for ; Thu, 2 Jun 2011 05:10:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id hIFU3Jp2kR3kwKgT for ; Thu, 02 Jun 2011 05:10:22 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p52CAFZ2026454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 08:10:15 -0400 Received: from dhcp-1-233.brq.redhat.com (dhcp-1-233.brq.redhat.com [10.34.1.233]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p52CABTM004550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 08:10:12 -0400 Date: Thu, 2 Jun 2011 14:10:11 +0200 (CEST) From: Lukas Czerner X-X-Sender: lukas@dhcp-27-109.brq.redhat.com To: "Amir G." cc: Dave Chinner , xfs@oss.sgi.com, sandeen@redhat.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP In-Reply-To: Message-ID: References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <20110602030802.GR561@dastard> <20110602064040.GS561@dastard> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-854799617-1307016615=:3931" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1307016623 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-854799617-1307016615=:3931 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 2 Jun 2011, Amir G. wrote: > On Thu, Jun 2, 2011 at 9:40 AM, Dave Chinner wrote: > > On Thu, Jun 02, 2011 at 06:49:20AM +0300, Amir G. wrote: > >> On Thu, Jun 2, 2011 at 6:08 AM, Dave Chinner wrote: > >> > On Thu, Jun 02, 2011 at 05:33:34AM +0300, Amir G. wrote: > >> >> On Thu, Jun 2, 2011 at 5:16 AM, Amir G. wrote: > >> >> > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner wrote: > >> > Personally I think that ext4dev shouldn't be supported at all. A > >> > special fstyp iwhile ext4 was being developed was, IMO, a stupid > >> > thing to do in the first place, and I was happy when it died. It > >> > should not be resurrected and propagated. > >> > > >> > xfstests assumes that you are using a userspace that is current with > >> > the version of the filesystem the kernel supports. If you are > >> > running a development/special branch of ext4, then you need to be > >> > running a userspace that understands it completely. If all you are > >> > doing with the ext4dev fstyp is trying to vector to a different fsck > >> > program that supports a new set of feature bits, then IMO you are > >> > doing it all wrong. > >> > > >> > Fundamentally, the filesystem is either ext4 or it isn't. If the > >> > features are never going to make it into mainline ext4, then you > >> > need a completely different fstype and full userspace support for > >> > that fstype. Once you have that, you can add the fstype support to > >> > xfstests. However, just using a different fstyp just to set a > >> > certain set of feature flags is, again IMO, a pretty stupid way of > >> > going about this. > >> > > >> > >> The features are going into mainline, but are not there yet. > > > > So using feature bits as they were intended is the right thing to > > do, isn't it? > > I am not sure what you mean by that. > The fact that to this day fsck.ext2/3/4 have always been the same > file (hence support the same feature set) does not mean that they have > to be that way by design. > > on my test system fsck.ext4dev must be used to test ext4dev, which has > newer features than ext4. And that's perfectly fine, you can use whatever you want on you system. > I fail to see the problem with that. > > > > >> I did not invent the ext4dev standard, which is pretty well supported > >> by all relevant tools, but I find it very convenient for the testing. > > > > As I understand it, ext4dev is deprecated and should not be used for > > any new filesystems. When did that status change? > > > > Or did you just start using it because it's convenient for your > > purposes?  What happens when someone else decides to use ext4dev for > > testing incompatible development features because it is convenient > > for them? > > > > The way I see it, ext4dev is a tool for ext4 developers (and testers). > Anyone can use it for their own needs and it would be convenient for everyone. > I never suggested that Fedora push my ext4dev utils as a standard package. > But me and my group can use it to test the snapshots feature and Ted > and his group can use it to test the allocation clusters feature. ext4dev is not a tool for ext4 developers. It has been deprecated and does not exist anymore, looking at kernel config there is nothing like that. If you do not want to have different filesystem for your system to be able to test ext4 without breaking your system ,than it is perfectly fine to write yourself such helpers. But I do not see any reason for pushing this stuff to other tools. In fact it should have been removed from everywhere, since it does not exist anymore ... or has something changed ? Are we resurrecting ext4dev ? Then we should start somewhere else do not you think ? > > > >> Especially, when I expect my testers to be running a stable > >> distro release (i.e. F15 or Ubuntu 11.4) and be able to install > >> my experimental ext4dev module and utils, without it affecting > >> their (most likely) root ext4/ext3 fs. > > > > So get them to use an ext3, XFS, reiser or JFS root filesystem if > > that's your major concern. That's long been a best practice for > > configuring a filesystem test box - don't use the same filesystem > > for your root/stable filesystems as the filesytsem you are testing. > > > > e.g. If you pick ext3 for the root filesystem, then you can test > > ext4, btrfs, xfs, etc changes without having to worry about whether > > the development module being tested is going to affect your root > > filesystem.... > > You make it sound as if I have a flock of testers out there waiting for > me to feed them with use cases to test and who abide to my setup > instructions. > > Wake up call! this is not the case for me and for most developers. > If I'm lucky, I can get a e few testers who will say: > OK, if all I have to do is download this package and run 'make test' > I can spare an hour to play with it. > > So, yes, it's true. There are other ways to accomplish what I am doing, > but I am going out of my way to try to make the life of developers and testers > easier and you are doing the exact opposite by raising objections to a rather > trivial and harmless patch. What is easier for testers and developers ? I fail to see the reason for including non-existing FSTYP into xfstests while it should be forgotten by now. Just provide sources with whatever fs name you choose (or just patches for ext4 preferably), provide patches to e2fsprogs and patches to xfstests if you want people to test with it. And it should be easy for every tester, or developer to use it, shouldn't it ? Is that a problem ? -Lukas > > Let me ask you this: which FSTYP will be useful to more developers > ext4dev or reiserfs? > > > > > Cheers, > > > > Dave. > > -- > > Dave Chinner > > david@fromorbit.com > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > --8323328-854799617-1307016615=:3931-- From zohar@linux.vnet.ibm.com Thu Jun 2 07:25:48 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p52CPlrA197690 for ; Thu, 2 Jun 2011 07:25:48 -0500 X-ASG-Debug-ID: 1307017546-017200840000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e4.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6A20B1660240 for ; Thu, 2 Jun 2011 05:25:46 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by cuda.sgi.com with ESMTP id oYwJEJwGCfkECbMZ for ; Thu, 02 Jun 2011 05:25:46 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p52C4RlA006003 for ; Thu, 2 Jun 2011 08:04:27 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p52CPePN092752 for ; Thu, 2 Jun 2011 08:25:40 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p528PRhH019067 for ; Thu, 2 Jun 2011 05:25:28 -0300 Received: from localhost.localdomain.com (sig-9-65-99-133.mts.ibm.com [9.65.99.133]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p528NwCP011471; Thu, 2 Jun 2011 05:25:27 -0300 From: Mimi Zohar To: linux-security-module@vger.kernel.org Cc: Mimi Zohar , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, James Morris , David Safford , Andrew Morton , Greg KH , Dmitry Kasatkin , Alex Elder , xfs@oss.sgi.com, Mimi Zohar X-ASG-Orig-Subj: [PATCH v6 15/20] evm: add evm_inode_post_init call in xfs Subject: [PATCH v6 15/20] evm: add evm_inode_post_init call in xfs Date: Thu, 2 Jun 2011 08:23:38 -0400 Message-Id: <1307017423-15093-16-git-send-email-zohar@linux.vnet.ibm.com> X-Mailer: git-send-email 1.7.3.4 In-Reply-To: <1307017423-15093-1-git-send-email-zohar@linux.vnet.ibm.com> References: <1307017423-15093-1-git-send-email-zohar@linux.vnet.ibm.com> X-Barracuda-Connect: e4.ny.us.ibm.com[32.97.182.144] X-Barracuda-Start-Time: 1307017547 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean After creating the initial LSM security extended attribute, call evm_inode_post_init_security() to create the 'security.evm' extended attribute. Signed-off-by: Mimi Zohar --- fs/xfs/linux-2.6/xfs_iops.c | 27 +++++++++++++++++++-------- 1 files changed, 19 insertions(+), 8 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_iops.c b/fs/xfs/linux-2.6/xfs_iops.c index dd21784..01b354d 100644 --- a/fs/xfs/linux-2.6/xfs_iops.c +++ b/fs/xfs/linux-2.6/xfs_iops.c @@ -46,6 +46,7 @@ #include #include #include +#include #include #include @@ -106,23 +107,33 @@ xfs_init_security( const struct qstr *qstr) { struct xfs_inode *ip = XFS_I(inode); - size_t length; - void *value; - unsigned char *name; + struct xattr lsm_xattr; + struct xattr evm_xattr; int error; - error = security_inode_init_security(inode, dir, qstr, (char **)&name, - &value, &length); + error = security_inode_init_security(inode, dir, qstr, &lsm_xattr.name, + &lsm_xattr.value, + &lsm_xattr.value_len); if (error) { if (error == -EOPNOTSUPP) return 0; return -error; } - error = xfs_attr_set(ip, name, value, length, ATTR_SECURE); + error = xfs_attr_set(ip, lsm_xattr.name, lsm_xattr.value, + lsm_xattr.value_len, ATTR_SECURE); + if (error) + goto out; - kfree(name); - kfree(value); + error = evm_inode_post_init_security(inode, &lsm_xattr, &evm_xattr); + if (error) + goto out; + error = xfs_attr_set(ip, evm_xattr.name, evm_xattr.value, + evm_xattr.value_len, ATTR_SECURE); + kfree(evm_xattr.value); +out: + kfree(lsm_xattr.name); + kfree(lsm_xattr.value); return error; } -- 1.7.3.4 From amir73il@gmail.com Thu Jun 2 08:17:58 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_62,J_CHICKENPOX_65,J_CHICKENPOX_66,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p52DHwim199626 for ; Thu, 2 Jun 2011 08:17:58 -0500 X-ASG-Debug-ID: 1307020675-5aff025c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-wy0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E0E731ED3E78 for ; Thu, 2 Jun 2011 06:17:55 -0700 (PDT) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by cuda.sgi.com with ESMTP id 1vYYncIXngl0xz4N for ; Thu, 02 Jun 2011 06:17:55 -0700 (PDT) Received: by wyi11 with SMTP id 11so655273wyi.26 for ; Thu, 02 Jun 2011 06:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+6BZLm3XTZ1ffNi/M5xiJs7rNzlblniqBaJv8in/rFA=; b=kJzPkS3WcWczjKpWKkwzhEF0AVrsCbACA1eFkf9vDbkT6Lms4J4eNI/MXdwaAIW55/ aXdzooZtcJJX8hztZ//xTJkMnfr3J7xBTc2n05QWIgTAn78JZsLLpDPCTspvKRgyYZww yB4vcnbQlpVEZ3kAqii5JscrY3Jco+hsrjqdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=lDib5Z4afWY44S7T4PngKr8gkNev2qxUlaHUqHh57kNSKOxTpqo80WN9Sa+tuA3FfC LhijPB4nwSpx7xPBYDQNnyMIuNltOY/4rf55NUgVfuARL1xc3zfHeF5qIUURQquW2knA kJjTE9oD1OF8x0jEu4b6bWyiKZhaTEY6PTk2M= MIME-Version: 1.0 Received: by 10.216.232.146 with SMTP id n18mr694333weq.93.1307020674383; Thu, 02 Jun 2011 06:17:54 -0700 (PDT) Sender: amir73il@gmail.com Received: by 10.216.221.135 with HTTP; Thu, 2 Jun 2011 06:17:54 -0700 (PDT) In-Reply-To: References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <20110602030802.GR561@dastard> <20110602064040.GS561@dastard> Date: Thu, 2 Jun 2011 16:17:54 +0300 X-Google-Sender-Auth: C_lfWCKcQhwzAxetBOANqTEJO3g Message-ID: X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP From: "Amir G." To: Lukas Czerner Cc: Dave Chinner , xfs@oss.sgi.com, sandeen@redhat.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Theodore Tso Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-wy0-f181.google.com[74.125.82.181] X-Barracuda-Start-Time: 1307020676 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0206 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65390 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 2, 2011 at 3:10 PM, Lukas Czerner wrote: > On Thu, 2 Jun 2011, Amir G. wrote: > >> On Thu, Jun 2, 2011 at 9:40 AM, Dave Chinner wrote= : >> > On Thu, Jun 02, 2011 at 06:49:20AM +0300, Amir G. wrote: >> >> On Thu, Jun 2, 2011 at 6:08 AM, Dave Chinner wr= ote: >> >> > On Thu, Jun 02, 2011 at 05:33:34AM +0300, Amir G. wrote: >> >> >> On Thu, Jun 2, 2011 at 5:16 AM, Amir G. wrote: >> >> >> > On Thu, Jun 2, 2011 at 2:28 AM, Dave Chinner wrote: >> >> > Personally I think that ext4dev shouldn't be supported at all. A >> >> > special fstyp iwhile ext4 was being developed was, IMO, a stupid >> >> > thing to do in the first place, and I was happy when it died. It >> >> > should not be resurrected and propagated. >> >> > >> >> > xfstests assumes that you are using a userspace that is current wit= h >> >> > the version of the filesystem the kernel supports. If you are >> >> > running a development/special branch of ext4, then you need to be >> >> > running a userspace that understands it completely. If all you are >> >> > doing with the ext4dev fstyp is trying to vector to a different fsc= k >> >> > program that supports a new set of feature bits, then IMO you are >> >> > doing it all wrong. >> >> > >> >> > Fundamentally, the filesystem is either ext4 or it isn't. If the >> >> > features are never going to make it into mainline ext4, then you >> >> > need a completely different fstype and full userspace support for >> >> > that fstype. Once you have that, you can add the fstype support to >> >> > xfstests. However, just using a different fstyp just to set a >> >> > certain set of feature flags is, again IMO, a pretty stupid way of >> >> > going about this. >> >> > >> >> >> >> The features are going into mainline, but are not there yet. >> > >> > So using feature bits as they were intended is the right thing to >> > do, isn't it? >> >> I am not sure what you mean by that. >> The fact that to this day fsck.ext2/3/4 have always been the same >> file (hence support the same feature set) does not mean that they have >> to be that way by design. >> >> on my test system fsck.ext4dev must be used to test ext4dev, which has >> newer features than ext4. > > And that's perfectly fine, you can use whatever you want on you system. > >> I fail to see the problem with that. >> >> > >> >> I did not invent the ext4dev standard, which is pretty well supported >> >> by all relevant tools, but I find it very convenient for the testing. >> > >> > As I understand it, ext4dev is deprecated and should not be used for >> > any new filesystems. When did that status change? >> > >> > Or did you just start using it because it's convenient for your >> > purposes? =A0What happens when someone else decides to use ext4dev for >> > testing incompatible development features because it is convenient >> > for them? >> > >> >> The way I see it, ext4dev is a tool for ext4 developers (and testers). >> Anyone can use it for their own needs and it would be convenient for eve= ryone. >> I never suggested that Fedora push my ext4dev utils as a standard packag= e. >> But me and my group can use it to test the snapshots feature and Ted >> and his group can use it to test the allocation clusters feature. > > ext4dev is not a tool for ext4 developers. It has been deprecated and > does not exist anymore, looking at kernel config there is nothing like > that. If you do not want to have different filesystem for your system > to be able to test ext4 without breaking your system ,than it is perfectl= y > fine to write yourself such helpers. But I do not see any reason for > pushing this stuff to other tools. In fact it should have been removed > from everywhere, since it does not exist anymore ... or has something > changed ? Are we resurrecting ext4dev ? Then we should start somewhere > else do not you think ? > Ted actually brought this up in our ext4 developers meeting on LSF. He said we could register an ext4 module with the ext4dev external symbols and it would be useful for testing, since we already have all those tools t= hat are aware of ext4dev. I am still using a more low-tech method of cloning ext4 (sed) to build a standalone ext4dev module for testing, but it's the same principle. >> >> >> >> Especially, when I expect my testers to be running a stable >> >> distro release (i.e. F15 or Ubuntu 11.4) and be able to install >> >> my experimental ext4dev module and utils, without it affecting >> >> their (most likely) root ext4/ext3 fs. >> > >> > So get them to use an ext3, XFS, reiser or JFS root filesystem if >> > that's your major concern. That's long been a best practice for >> > configuring a filesystem test box - don't use the same filesystem >> > for your root/stable filesystems as the filesytsem you are testing. >> > >> > e.g. If you pick ext3 for the root filesystem, then you can test >> > ext4, btrfs, xfs, etc changes without having to worry about whether >> > the development module being tested is going to affect your root >> > filesystem.... >> >> You make it sound as if I have a flock of testers out there waiting for >> me to feed them with use cases to test and who abide to my setup >> instructions. >> >> Wake up call! this is not the case for me and for most developers. >> If I'm lucky, I can get a e few testers who will say: >> OK, if all I have to do is download this package and run 'make test' >> I can spare an hour to play with it. >> >> So, yes, it's true. There are other ways to accomplish what I am doing, >> but I am going out of my way to try to make the life of developers and t= esters >> easier and you are doing the exact opposite by raising objections to a r= ather >> trivial and harmless patch. > > What is easier for testers and developers ? I fail to see the reason for > including non-existing FSTYP into xfstests while it should be forgotten > by now. Just provide sources with whatever fs name you choose (or just > patches for ext4 preferably), provide patches to e2fsprogs and patches to > xfstests if you want people to test with it. And it should be easy for ev= ery > tester, or developer to use it, shouldn't it ? Is that a problem ? Yes, it is a problem. You are thinking in terms of a developer who builds new kernels on a daily basis. Back in the time, when I developed next3, I asked some friend and people in the community if they could test it. It turned out that they don't even know how to build a kernel and they don't want to invest the time in doing that. This is when I realized that to get to a wider audience of testers, I need to make the testing process E A S Y ! And by E A S Y, I mean: 1. Take a Fedora 15 system 2. download http://next3.sourceforge.net/files/1.0.13/ext4dev_snapshots-1.0= .13-x86_64.tar.gz 3. tar xfz ext4dev_snapshots-1.0.13-x86_64.tar.gz && cd ext4dev_snapshots-1= .0.13 4. make && sudo make install && sudo make test That's it! it takes no more than 5 minutes and your system remains unaffect= ed by installed tools. Now, if the patch in question is accepted to xfstests, testing the experimental fs would be as E A S Y as: 5. sudo mkfs.ext4dev -O has_snapshot /dev/sda5 6. sudo mount /dev/sda5 /mnt/test 7. cd ~/xfstests && sudo ./check (assuming those are your TEST_DEV/TEST_DIR above) Seriously, guys! This thread is becoming ridiculous. xfstests is not a tools for an obscure target market - it's for us. It should be used by developers to test their patches. Why make it so difficult if I state very clearly that it helps me??? Can I get at least one Yay here? Ted? Eric? Anyone? And look at the patch for heaven's sake (which was left behind in the heat of the discussion) , it's miserably harmless. Amir. >From da25ccc0910847b0aaddac1b01f223890244f223 Mon Sep 17 00:00:00 2001 From: Amir Goldstein Date: Tue, 31 May 2011 18:43:17 +0300 Subject: [PATCH v3] xfstests: add support for ext4dev FSTYP blkid knows to identify the ext4dev FSTYP of a partition that was formatted with mkfs.ext4dev. quota tools and various util-linux utils are also aware of ext4dev, so ext4dev shares the same capabilities as ext4. Signed-off-by: Amir Goldstein Tested-by: Sergey Ivanov --- ext4dev is used to test experimental ext4 code in mutual existance with production ext4 code on the same system. Specifically, ext4 snapshots code is available for testing as a stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4 (see http://next3.sf.net). v2 -> v3: - change if to case statement v1 -> v2: - undo change of fsck -t $FSTYP to fsck.$FSTYP common.defrag | 2 +- common.quota | 10 +++++++--- common.rc | 10 +++++----- 3 files changed, 13 insertions(+), 9 deletions(-) diff --git a/common.defrag b/common.defrag index 1bcf01d..4850803 100644 --- a/common.defrag +++ b/common.defrag @@ -26,7 +26,7 @@ _require_defrag() xfs) DEFRAG_PROG=3D/usr/sbin/xfs_fsr ;; - ext4) + ext4|ext4dev) DEFRAG_PROG=3D/usr/bin/e4defrag ;; *) diff --git a/common.quota b/common.quota index 3c87ce1..9736306 100644 --- a/common.quota +++ b/common.quota @@ -29,7 +29,7 @@ _require_quota() [ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed" case $FSTYP in - ext2|ext3|ext4|reiserfs) + ext2|ext3|ext4|ext4dev|reiserfs) if [ ! -d /proc/sys/fs/quota ]; then _notrun "Installed kernel does not support quotas" fi @@ -237,10 +237,14 @@ _check_quota_usage() # Sync to get delalloc to disk sync VFS_QUOTA=3D0 - if [ $FSTYP =3D "ext2" -o $FSTYP =3D "ext3" -o $FSTYP =3D "ext4" -o $FSTY= P =3D "reiserfs" ]; then + case $FSTYP in + ext2|ext3|ext4|ext4dev|reiserfs) VFS_QUOTA=3D1 quotaon -f -u -g $SCRATCH_MNT 2>/dev/null - fi + ;; + *) + ;; + esac repquota -u -n $SCRATCH_MNT | grep -v "^#0" | _filter_scratch | sort >$tmp.user.orig repquota -g -n $SCRATCH_MNT | grep -v "^#0" | _filter_scratch | diff --git a/common.rc b/common.rc index e634fbb..c510c66 100644 --- a/common.rc +++ b/common.rc @@ -65,7 +65,7 @@ _mount_opts() nfs) export MOUNT_OPTIONS=3D$NFS_MOUNT_OPTIONS ;; - ext2|ext3|ext4) + ext2|ext3|ext4|ext4dev) # acls & xattrs aren't turned on by default on ext$FOO export MOUNT_OPTIONS=3D"-o acl,user_xattr $EXT_MOUNT_OPTIONS" ;; @@ -110,7 +110,7 @@ _mkfs_opts() _fsck_opts() { case $FSTYP in - ext2|ext3|ext4) + ext2|ext3|ext4|ext4dev) export FSCK_OPTIONS=3D"-nf" ;; reiserfs) @@ -326,10 +326,10 @@ _scratch_mkfs_sized() xfs) _scratch_mkfs_xfs -d size=3D$fssize -b size=3D$blocksize ;; - ext2|ext3|ext4) + ext2|ext3|ext4|ext4dev) /sbin/mkfs.$FSTYP $MKFS_OPTIONS -b $blocksize $SCRATCH_DEV $blocks ;; - btrfs) + btrfs) /sbin/mkfs.$FSTYP $MKFS_OPTIONS $SCRATCH_DEV -b $fssize ;; *) @@ -354,7 +354,7 @@ _scratch_mkfs_geom() xfs) MKFS_OPTIONS+=3D" -b size=3D$blocksize, -d su=3D$sunit_bytes,sw=3D$swidth= _mult" ;; - ext4) + ext4|ext4dev) MKFS_OPTIONS+=3D" -b $blocksize -E stride=3D$sunit_blocks,stripe_width=3D$swidth_blocks" ;; *) --=20 1.7.4.1 From powool@gmail.com Thu Jun 2 09:42:49 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p52EgnqL203753 for ; Thu, 2 Jun 2011 09:42:49 -0500 X-ASG-Debug-ID: 1307025767-6f39036e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ww0-f51.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 190E51235F25 for ; Thu, 2 Jun 2011 07:42:47 -0700 (PDT) Received: from mail-ww0-f51.google.com (mail-ww0-f51.google.com [74.125.82.51]) by cuda.sgi.com with ESMTP id KLUJyOFvnw4DBXlG for ; Thu, 02 Jun 2011 07:42:47 -0700 (PDT) Received: by wwf26 with SMTP id 26so752669wwf.32 for ; Thu, 02 Jun 2011 07:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=IiWYSqeNGWX3Dm9KiozEWGeTW6UB3k7LLjyKxGFmvZ4=; b=KO85SfFakkf2o6FG7douPnP3KMSmbPqCTJfOJmpVKXdsjIKVyg2ceEBs21/+O0CVt0 dGmZRBcN++kc/GEZmkSIIlfTq6SEPm9MmCwtALp40OUUge8YMZzZLr/OviZzq7Ut/OYX tqd4e7AFIub0wklvcQf0p+BllkvpopgVv55Eo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=piHqOFZjyI9MuKoWoC5VNlLxBmew2Y2QiE6ONoO9IuBKebufmHsj7AcUCqyLLtyFnW roiDJm2mc+pfk/cEDbFrt7+87nLgMkal2KTLaCy3YxhinsF6KSpLHQdXzJ4kQBmAq1SM uDEWA5lyGRIGB9Qud4zr8N8CsCf8ZH1ahHkXs= MIME-Version: 1.0 Received: by 10.216.230.138 with SMTP id j10mr6250143weq.46.1307025766839; Thu, 02 Jun 2011 07:42:46 -0700 (PDT) Sender: powool@gmail.com Received: by 10.216.137.202 with HTTP; Thu, 2 Jun 2011 07:42:46 -0700 (PDT) Date: Thu, 2 Jun 2011 10:42:46 -0400 X-Google-Sender-Auth: zpXwmt-RpRG-04lFUuJMKztk6Es Message-ID: X-ASG-Orig-Subj: I/O hang, possibly XFS, possibly general Subject: I/O hang, possibly XFS, possibly general From: Paul Anderson To: xfs-oss Content-Type: text/plain; charset=ISO-8859-1 X-Barracuda-Connect: mail-ww0-f51.google.com[74.125.82.51] X-Barracuda-Start-Time: 1307025768 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65397 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This morning, I had a symptom of a I/O throughput problem in which dirty pages appeared to be taking a long time to write to disk. The system is a large x64 192GiB dell 810 server running 2.6.38.5 from kernel.org - the basic workload was data intensive - concurrent large NFS (with high metadata/low filesize), rsync/lftp (with low metadata/high file size) all working in a 200TiB XFS volume on a software MD raid0 on top of 7 software MD raid6, each w/18 drives. I had mounted the filesystem with inode64,largeio,logbufs=8,noatime. The specific symptom was that 'sync' hung, a dpkg command hung (presumably trying to issue fsync), and experimenting with "killall -STOP" or "kill -STOP" of the workload jobs didn't let the system drain I/O enough to finish the sync. I probably did not wait long enough, however. So here's what I did to diagnose: when all workloads were stopped, there was still low rate I/O from kflush->md array jobs. No CPU starvation, but the I/O rate was low - 5-30MiB/second (the array can readily do >1000MiB/second for big I/O). Mind you, one "md5sum --check" job was able to run at >200MiB/second without trouble - turn it off or on and the aggregate I/O load shoots right up or down along with it, so I'm fairly confident in the underlying physical arrays as well as XFS large data I/O. I did "echo 3 > /proc/sys/vm/drop_caches" repeatedly and noticed that according to top, the total amount of cached data would drop down rapidly (first time had the big drop), but still be stuck at around 8-10Gigabytes. While continuing to do this, I noticed finally that the cached data value was in fact dropping slowly (at the rate of 5-30MiB/second), and in fact finally dropped down to approximately 60Megabytes at which point the stuck dpkg command finished, and I was again able to issue sync commands that finished instantly. My guess is that I've done something to fill the buffer pool with slow to flush metadata - and prior to rebooting the machine a few minutes ago, I removed the largeio option in /etc/fstab. I can't say this is an XFS bug specifically, but more likely how I am using it - are there other tools I can use to better diagnose what is going on? I do know it will happen again, since we will have 5 of these machines running at very high rates soon. Also, any suggestions for better metadata or log management are very welcome. This particular machine is probably our worst, since it has the widest variation in offered file I/O load (tens of millions of small files, thousands of >1GB files). If this workload is pushing XFS too hard, I can deploy new hardware to split the workload across different filesystems. Thanks very much for any thoughts or suggestions, Paul Anderson From lczerner@redhat.com Thu Jun 2 09:44:18 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p52EiI65203834 for ; Thu, 2 Jun 2011 09:44:18 -0500 X-ASG-Debug-ID: 1307025857-5b0d03370000-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 C4E15497B93 for ; Thu, 2 Jun 2011 07:44:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id UbvHc636rMoD8xoJ for ; Thu, 02 Jun 2011 07:44:17 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p52EiBOY012676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 10:44:11 -0400 Received: from dhcp-1-233.brq.redhat.com (dhcp-1-233.brq.redhat.com [10.34.1.233]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p52Ei78w008340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 10:44:09 -0400 Date: Thu, 2 Jun 2011 16:44:07 +0200 (CEST) From: Lukas Czerner X-X-Sender: lukas@dhcp-27-109.brq.redhat.com To: "Amir G." cc: Lukas Czerner , Dave Chinner , xfs@oss.sgi.com, sandeen@redhat.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Theodore Tso X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP In-Reply-To: Message-ID: References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <20110602030802.GR561@dastard> <20110602064040.GS561@dastard> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1307025857 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, 2 Jun 2011, Amir G. wrote: --snip-- > > Ted actually brought this up in our ext4 developers meeting on LSF. > He said we could register an ext4 module with the ext4dev external symbols > and it would be useful for testing, since we already have all those tools that > are aware of ext4dev. I know, but my point is still valid. why to introduce non-existing FSTYP into other tools, this is not proper course of action. If the goal is really resurrect ext4dev we should do this first. > > I am still using a more low-tech method of cloning ext4 (sed) to build > a standalone ext4dev module for testing, but it's the same principle. > > >> > >> --snip-- > >> > >> So, yes, it's true. There are other ways to accomplish what I am doing, > >> but I am going out of my way to try to make the life of developers and testers > >> easier and you are doing the exact opposite by raising objections to a rather > >> trivial and harmless patch. > > > > What is easier for testers and developers ? I fail to see the reason for > > including non-existing FSTYP into xfstests while it should be forgotten > > by now. Just provide sources with whatever fs name you choose (or just > > patches for ext4 preferably), provide patches to e2fsprogs and patches to > > xfstests if you want people to test with it. And it should be easy for every > > tester, or developer to use it, shouldn't it ? Is that a problem ? > > Yes, it is a problem. You are thinking in terms of a developer who builds > new kernels on a daily basis. > Back in the time, when I developed next3, I asked some friend and > people in the community > if they could test it. > It turned out that they don't even know how to build a kernel and they > don't want > to invest the time in doing that. > This is when I realized that to get to a wider audience of testers, I > need to make the testing > process E A S Y ! > > And by E A S Y, I mean: > 1. Take a Fedora 15 system > 2. download http://next3.sourceforge.net/files/1.0.13/ext4dev_snapshots-1.0.13-x86_64.tar.gz > 3. tar xfz ext4dev_snapshots-1.0.13-x86_64.tar.gz && cd ext4dev_snapshots-1.0.13 > 4. make && sudo make install && sudo make test So you're saying that you can not patch xfstests (and other) sources in the make time ?? Thanks! -Lukas From sandeen@redhat.com Thu Jun 2 09:59:44 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p52ExhVg207219 for ; Thu, 2 Jun 2011 09:59:43 -0500 X-ASG-Debug-ID: 1307026782-5b1303e30000-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 7C69B497847 for ; Thu, 2 Jun 2011 07:59:42 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Cwh5zeQII5auWMHa for ; Thu, 02 Jun 2011 07:59:42 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p52ExbcQ018312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 10:59:37 -0400 Received: from liberator.sandeen.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p52ExZ9C031358 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 10:59:36 -0400 Message-ID: <4DE7A557.9040608@redhat.com> Date: Thu, 02 Jun 2011 09:59:35 -0500 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Amir G." CC: Dave Chinner , xfs@oss.sgi.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1307026783 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/2/11 2:16 AM, Amir G. wrote: > OK, after upgrading to newer util-linux and building it from git, > which also didn't help, I finally found who to blame - me. > I had an old (noauto) entry in /etc/fstab which claimed that /dev/sda5 is ext4. > fsck was picking up that entry and insisting that /dev/sda5 is ext4 > (regardless of what it really is) > blkid isn't doing that silly thing. > > Amir So where are we at with all this? I don't really mind adding ext4dev to FSTYP case statements, it -is- something which blkid could, in theory, still return, and making xfstests cope with that and try to invoke fsck -t ext4dev doesn't bother me too much. It is sadly an fs type embedded into a few tools. But other than that, I don't think we should be making changes to upstream projects based on your current development hacks (I don't mean hack in a bad way, just that running sed across ext4 to create your custom filesystem for testing should not require upstream projects to change...) So I'm ok with sprinkling "ext4|ext4dev" around if necessary. Anyone else disagree? -Eric From stan@hardwarefreak.com Thu Jun 2 11:17:22 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p52GHKoe210139 for ; Thu, 2 Jun 2011 11:17:22 -0500 X-ASG-Debug-ID: 1307031439-434c033e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 44E0F14E26B5 for ; Thu, 2 Jun 2011 09:17:19 -0700 (PDT) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id Fx1R9bcrdeU0lxkb for ; Thu, 02 Jun 2011 09:17:19 -0700 (PDT) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id 778216C14A; Thu, 2 Jun 2011 11:17:18 -0500 (CDT) Message-ID: <4DE7B78C.4040608@hardwarefreak.com> Date: Thu, 02 Jun 2011 11:17:16 -0500 From: Stan Hoeppner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Anderson CC: xfs-oss X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-65-41-216-221.sta.embarqhsd.net[65.41.216.221] X-Barracuda-Start-Time: 1307031440 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0017 1.0000 -2.0101 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.31 X-Barracuda-Spam-Status: No, SCORE=-1.31 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65403 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/2/2011 9:42 AM, Paul Anderson wrote: > had mounted the filesystem with inode64,largeio,logbufs=8,noatime. I don't see 'delaylog' in your mount options nor an external log device specified. Delayed logging will dramatically decrease IOPs to the log device via cleverly discarding duplicate metadata write operations and other tricks. Enabling it may solve your problem given your high metadata workload. Delayed logging design document: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/xfs-delayed-logging-design.txt Delaylog was an optional mount option from 2.6.35 to 2.6.38. In 2.6.39 and up it is the default. Give it a go. -- Stan From adilger@dilger.ca Thu Jun 2 12:22:57 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p52HMvjY212325 for ; Thu, 2 Jun 2011 12:22:57 -0500 X-ASG-Debug-ID: 1307035374-7e6500520000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from idcmail-mo2no.shaw.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9D4B3165845F for ; Thu, 2 Jun 2011 10:22:54 -0700 (PDT) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by cuda.sgi.com with ESMTP id v68ynxYl8grEVN2U for ; Thu, 02 Jun 2011 10:22:54 -0700 (PDT) Received: from pd5ml2no-ssvc.prod.shaw.ca ([10.0.153.164]) by pd7mo1no-svcs.prod.shaw.ca with ESMTP; 02 Jun 2011 11:22:54 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=dyVpuHYQJROgCHwBBw1H+I+7e1rgZIKdHwrI0HSbuo4= c=1 sm=1 a=ZVZlOJdrMLoA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=c23vf5CSMVc0QQz9B4a6RA==:17 a=969kFmqUfCub7NDVhSwA:9 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO [IPv6:::1]) ([68.147.195.121]) by pd5ml2no-dmz.prod.shaw.ca with ESMTP; 02 Jun 2011 11:22:54 -0600 X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Andreas Dilger In-Reply-To: <4DE7A557.9040608@redhat.com> Date: Thu, 2 Jun 2011 11:22:53 -0600 Cc: "Amir G." , Dave Chinner , xfs@oss.sgi.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein Content-Transfer-Encoding: quoted-printable Message-Id: <7D3F86FA-5AA9-49B0-9AFE-F597E83C07B4@dilger.ca> References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <4DE7A557.9040608@redhat.com> To: Eric Sandeen X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: idcmail-mo2no.shaw.ca[64.59.134.9] X-Barracuda-Start-Time: 1307035375 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65408 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 2011-06-02, at 8:59 AM, Eric Sandeen wrote: > On 6/2/11 2:16 AM, Amir G. wrote: >> OK, after upgrading to newer util-linux and building it from git, >> which also didn't help, I finally found who to blame - me. >> I had an old (noauto) entry in /etc/fstab which claimed that = /dev/sda5 is ext4. >> fsck was picking up that entry and insisting that /dev/sda5 is ext4 >> (regardless of what it really is) >> blkid isn't doing that silly thing. >=20 > So where are we at with all this? >=20 > I don't really mind adding ext4dev to FSTYP case statements, it -is- = something which blkid could, in theory, still return, and making = xfstests cope with that and try to invoke fsck -t ext4dev doesn't bother = me too much. It is sadly an fs type embedded into a few tools. I'm perfectly OK with using ext4dev as a filesystem type that allows = testing changes to ext4 on a system that is already running ext4 as the root fs. > But other than that, I don't think we should be making changes to = upstream projects based on your current development hacks (I don't mean = hack in a bad way, just that running sed across ext4 to create your = custom filesystem for testing should not require upstream projects to = change...) No, but it's not like this is affecting a lot of tools, just one that is used by filesystem developers. > So I'm ok with sprinkling "ext4|ext4dev" around if necessary. Anyone = else disagree? The other alternative is to change all of the "ext2|ext3|ext4|ext4dev" = case statements to be "ext[2-9]*", or "ext[3-9]*", or "ext[4-9]*" for checks = that are only valid for newer codes and be done with it. It's a lot easier = to read, and we don't have to change it again should we ever get ext5 or = whatever (hopefully btrfs will be ready before that, but who knows). Cheers, Andreas From pg_mh@sabi.co.UK Thu Jun 2 14:06:36 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p52J6YPM218903 for ; Thu, 2 Jun 2011 14:06:36 -0500 X-ASG-Debug-ID: 1307041591-36ca03110000-ps1ADW X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from woodbine.london.02.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A10201660B44 for ; Thu, 2 Jun 2011 12:06:32 -0700 (PDT) Received: from woodbine.london.02.net (woodbine.london.02.net [87.194.255.145]) by cuda.sgi.com with ESMTP id z7TBCSbPD5fS0ndU for ; Thu, 02 Jun 2011 12:06:32 -0700 (PDT) Received: from ty.sabi.co.UK (87.194.99.40) by woodbine.london.02.net (8.5.133) id 4D8CD8C901C52D3C for xfs@OSS.SGI.com; Thu, 2 Jun 2011 20:06:31 +0100 Received: from from [127.0.0.1] (helo=tree.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.71 #1) id 1QSD45-0007SG-VT for ; Thu, 02 Jun 2011 19:56:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19943.56524.969126.59978@tree.ty.sabi.co.UK> Date: Thu, 2 Jun 2011 19:56:12 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general In-Reply-To: References: X-Mailer: VM 8.0.13 under 23.1.1 (x86_64-pc-linux-gnu) From: pg_xf2@xf2.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-Barracuda-Connect: woodbine.london.02.net[87.194.255.145] X-Barracuda-Start-Time: 1307041592 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65415 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean > This morning, I had a symptom of a I/O throughput problem in which > dirty pages appeared to be taking a long time to write to disk. That can happen because of a lot of reasons, like elevator issues (CFQ has serious problems) and even CPU scheduler issues, RAID HA firmware problems (if you are using one, and you seem to be using MD, but then you may be using several in JBOD mode to handle all the disks), or problems with the Linux page cache (read ahead, the abominable plugger) or the flusher (the defaults are not so hot). Sometimes there are odd resonances between the page cache and multiple layers od MD or LVM too. Lots of people have been burned even with much simpler setups than the one you describe below: > The system is a large x64 192GiB dell 810 server running > 2.6.38.5 from kernel.org - the basic workload was data > intensive - concurrent large NFS (with high metadata/low > filesize), Very imaginative. :-) > rsync/lftp (with low metadata/high file size) More suitable, but insignificant compared to this: > all working in a 200TiB XFS volume on a software MD raid0 on > top of 7 software MD raid6, each w/18 drives. That's rather more than imaginative :-). But this is a family oriented mailing list so I can't use appropriate euphemisms, because they no longer look like euphemisms. > [ ... ] (the array can readily do >1000MiB/second for big > I/O). [ ... ] In a very specific narrow case, and you can get that with a lot less disks. You have 126 drives that can each do 130MB/s (outer tracks), so you should be getting 10GB/s :-). Also, your 1000MiB/s set probably is not full yet, so that's outer tracks only, and when it fills up, data gets into the inner tracks, and get a bit churned, then the real performances will "shine" through. > I did "echo 3 > /proc/sys/vm/drop_caches" repeatedly and > noticed that according to top, the total amount of cached data > would drop down rapidly (first time had the big drop), but > still be stuck at around 8-10Gigabytes. You have to watch '/proc/meminfo' to check the dirty pages in the cache. But you seem to have 8-10GiB of dirty pages in your 192GiB system. Extraordinarily imaginative. > While continuing to do this, I noticed finally that the cached > data value was in fact dropping slowly (at the rate of > 5-30MiB/second), and in fact finally dropped down to > approximately 60Megabytes at which point the stuck dpkg > command finished, and I was again able to issue sync commands > that finished instantly. Fantastic stuff, is that cached data or cached and dirty data? Guessing that it is cached and dirty (also because of the "Subject" line), do you really want to have several GiB of cached dirty pages? Do you want these to be zillions of little metadata transactions scattered at random all over the place? How "good" (I hesitate to use the very word in the context) is this more than imaginative RAID60 set at writing widely scattered small transactions? > [ ... ] since we will have 5 of these machines running at > very high rates soon. Look forward to that :-). > Also, any suggestions for better metadata Use some kind of low overhead database if you need a database, else pray :-) > or log management are very welcome. Separate drives/flash SSD/RAM SSD. As previously revealed by a question I asked, Linux MD does full-width stripe updates with RAID6. The wider, the better of course :-). > This particular machine is probably our worst, since it has > the widest variation in offered file I/O load (tens of > millions of small files, thousands of >1GB files). Wide variation is not the problem, and neither is the machine, it is the approach. > If this workload is pushing XFS too hard, XFS is a very good design within a fairly well defined envelope, and often the problems are more with Linux or application issues, but you may be a bit outside that envelope (euphemism alert), and you need to work on the grain of the storage system (understatement of the week). > I can deploy new hardware to split the workload across > different filesystems. My usual recommendation is to default (unless you have extraordinarily good arguments otherwise, and almost nobody does) to use RAID10 sets of at most 10 pairs (of "enterprise" drives of no more than 1TB each), with XFS or JFS depending on workload, as many servers as needed (if at all possible located topologically near to their users to avoid some potentially nasty network syndromes like incast), and forget about having a single large storage pool. Other details as to the flusher (every 1-2 seconds), elevator (deadline or noop), ... can matter a great deal. If you do need a single large storage pool almost the only reasonable way currently (even if I have great hopes for GlusterFS) is Lustre or one of its forks (or much simpler imitators like DPM), and that has its own downsides (it takes a lot of work), but a single large storage pool is almost never needed, at most a single large namespace, and that can be instantiated with an automounter (and Lustre/DPM/.... is in effect a more sophisticated automounter). If you know better go ahead and build 200TB XFS filesystems on top of a 7x(16+2) drive RAID60 and put lots of small files in them (or whatever) and don't even think about 'fsck' because you "know" it will never happen. And what about backing up one of those storage sets to another one? That can happen in the "background" of course, with no extra load :-). Just realized another imaginative detail: a 126 drive RAID60 set delivering 200TB, looks like that you are using 2TB drives. Why am I not surprised? It would be just picture-perfect if they were low cost "eco" drives, and only a bit less so if they were ordinary drives without ERC. Indeed cost conscious budget heroes can only suggest using 2TB drives in a 126-drive RAID60 set even for a small-file metadata intensive workload, because IOPS and concurrent RW are obsolete concepts in many parts of the world. Disclaimer: some smart people I know built knowingly a similar and fortunately much smaller collection of RAID6 sets because that was the least worst option for them, and since they know that it will not fill up before they can replace it, they are effectively short-stroking all those 2TB drives (I still would have bought ERC ones if possible) so it's cooler than it looks. > Thanks very much for any thoughts or suggestions, * Don't expect to slap together a lot of stuff at random and it working just like that. But then if you didn't expect that you wouldn't have done any of the above. * "My usual recommendation" above is freely given yet often worth more than months/years of very expensive consultants. * This mailing list is continuing proof that the "let's bang it together, it will just work" club is large. From powool@gmail.com Thu Jun 2 16:24:44 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p52LOiq1223195 for ; Thu, 2 Jun 2011 16:24:44 -0500 X-ASG-Debug-ID: 1307049879-3c3f02be0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ew0-f53.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id ED588499227 for ; Thu, 2 Jun 2011 14:24:39 -0700 (PDT) Received: from mail-ew0-f53.google.com (mail-ew0-f53.google.com [209.85.215.53]) by cuda.sgi.com with ESMTP id qC58SSEOu2E3SR3v for ; Thu, 02 Jun 2011 14:24:39 -0700 (PDT) Received: by ewy8 with SMTP id 8so548989ewy.26 for ; Thu, 02 Jun 2011 14:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IBwTU/8ah4dk+8rnTsxin1Fetmtmy6sGyu8oh9Anjxg=; b=ZTKE3PTvKf0Ejbwy0jICjGLCE77npvjCrX54XFbfFgMwhSGCMmWbrOvXBZt29FlE/F T9XzgUN1+DVC5GCO6UcpUCmysFZPLE5usBN4x0KzjqUNR5jHam+lcKlrAarYL26ObAlh 3ZN6Tg8QkGTOJhoDSiL1feb4jE0xcwRwREWWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ZIa6aw4VWcv8vAT/Q46abLh8KHDVprmIEJTZzNLlE2CVVEMTWHrKypA8NSMoeTpYu7 Jr+eWN2tvi1Dy1/VgkLWWKGiRIvKYItWVhopgwIiWHlUz//dNgsfYrokNRWMatIqx72c s0vW4acmrznUw9OWu/WNt/rt/3olA0SEVfk0s= MIME-Version: 1.0 Received: by 10.216.230.138 with SMTP id j10mr6565073weq.46.1307049879156; Thu, 02 Jun 2011 14:24:39 -0700 (PDT) Sender: powool@gmail.com Received: by 10.216.137.202 with HTTP; Thu, 2 Jun 2011 14:24:39 -0700 (PDT) In-Reply-To: <19943.56524.969126.59978@tree.ty.sabi.co.UK> References: <19943.56524.969126.59978@tree.ty.sabi.co.UK> Date: Thu, 2 Jun 2011 17:24:39 -0400 X-Google-Sender-Auth: IHd4EG53mK3vfZKKfDNJaq24rss Message-ID: X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general From: Paul Anderson To: Peter Grandi Cc: Linux fs XFS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-ew0-f53.google.com[209.85.215.53] X-Barracuda-Start-Time: 1307049882 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0086 1.0000 -1.9646 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.36 X-Barracuda-Spam-Status: No, SCORE=-1.36 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT, DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65424 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi Peter - I appreciate the feedback! The background for this is that we live in an extreme corner case of the world - our use case is dealing with 1GiB to 100GiB files at present, and in the future probably to 500GiB files (aggregated data from multiple deep sequencing runs). The data itself has very odd lifecycle behavior, as well - since it is research, the different stages are still being sorted out, but some stages are essentially write once, read once, maybe keep, maybe discard, depending on the research scenario. Parenthetically, I will note there are numerous other issues and problems that impose constraints beyond what is noted here - conventional work flow, research problems, budgets, rack space, rack power, time and more. On Thu, Jun 2, 2011 at 2:56 PM, Peter Grandi wr= ote: >> This morning, I had a symptom of a I/O throughput problem in which >> dirty pages appeared to be taking a long time to write to disk. > > That can happen because of a lot of reasons, like elevator > issues (CFQ has serious problems) and even CPU scheduler issues, > RAID HA firmware problems (if you are using one, and you seem to > be using MD, but then you may be using several in JBOD mode to > handle all the disks), or problems with the Linux page cache > (read ahead, the abominable plugger) or the flusher (the > defaults are not so hot). Sometimes there are odd resonances > between the page cache and multiple layers od MD or LVM too. All JBOD chassis (SuperMicro SC 847's)... been experimenting with the flusher, will look at the others. > > Lots of people have been burned even with much simpler setups > than the one you describe below: No doubt. > >> The system is a large x64 192GiB dell 810 server running >> 2.6.38.5 from kernel.org - the basic workload was data >> intensive - concurrent large NFS (with high metadata/low >> filesize), > > Very imaginative. :-) > >> rsync/lftp (with low metadata/high file size) > > More suitable, but insignificant compared to this: The rsync job currently appear to be causing the issue - it was rsyncing around 250,000 files. If the copy had already been done, the rsync is fast (i.e. stat is fast, despite the numbers), but when it starts moving data, the IOPS pegs and seems to be the limiting factor. > >> all working in a 200TiB XFS volume on a software MD raid0 on >> top of 7 software MD raid6, each w/18 drives. > > That's rather more than imaginative :-). But this is a family > oriented mailing list so I can't use appropriate euphemisms, > because they no longer look like euphemisms. We most likely live in different worlds - this is a pure research group with "different" constraints than those you're probably used to. Not my choice, but 4-10X the cost per unit of storage is currently not an option. >> [ ... ] (the array can readily do >1000MiB/second for big >> I/O). [ ... ] > > In a very specific narrow case, and you can get that with a lot > less disks. You have 126 drives that can each do 130MB/s (outer > tracks), so you should be getting 10GB/s :-). The raw hardware will do about 5GiB/sec - near as I can tell, this is saturating the pci-e bus (maybe main memory). With XFS freshly installed, it was doing around 1400MiB/sec write, and around 1900MiB/sec read - 10 parallel high throughput processes read or writing as fast as possible (which actually is our use case). > Also, your 1000MiB/s set probably is not full yet, so that's > outer tracks only, and when it fills up, data gets into the > inner tracks, and get a bit churned, then the real performances > will "shine" through. Yeah - overall, I expect it to drop - perhaps 50%? I dunno. The particular filesystem being discussed is 80% full at the moment. >> I did "echo 3 > /proc/sys/vm/drop_caches" repeatedly and >> noticed that according to top, the total amount of cached data >> would drop down rapidly (first time had the big drop), but >> still be stuck at around 8-10Gigabytes. > > You have to watch '/proc/meminfo' to check the dirty pages in > the cache. But you seem to have 8-10GiB of dirty pages in your > 192GiB system. Extraordinarily imaginative. Will watch that - yes, too many dirty pages in RAM - defaults are far from optimal here. > >> While continuing to do this, I noticed finally that the cached >> data value was in fact dropping slowly (at the rate of >> 5-30MiB/second), and in fact finally dropped down to >> approximately 60Megabytes at which point the stuck dpkg >> command finished, and I was again able to issue sync commands >> that finished instantly. > > Fantastic stuff, is that cached data or cached and dirty data? > Guessing that it is cached and dirty (also because of the > "Subject" line), do you really want to have several GiB of > cached dirty pages? After watching it reach steady state at around 60M, it appears not to be dirty, as a sync command returned immediately and had no effect on that value. No, I do not want lots of dirty pages, however, I'm also aware that if those are just data pages, it represents a few seconds of system operation. > Do you want these to be zillions of little metadata transactions > scattered at random all over the place? =A0How "good" (I hesitate > to use the very word in the context) is this more than imaginative > RAID60 set at writing widely scattered small transactions? >> [ ... ] =A0since we will have 5 of these machines running at >> very high rates soon. > > Look forward to that :-). We are, actually, it is a tremendous improvement over what we've been using= . > >> Also, any suggestions for better metadata > > Use some kind of low overhead database if you need a database, > else pray :-) No database will work that I'm aware of, at least for the end data storage. > >> or log management are very welcome. > > Separate drives/flash SSD/RAM SSD. As previously revealed by a > question I asked, Linux MD does full-width stripe updates with > RAID6. The wider, the better of course :-). > >> This particular machine is probably our worst, since it has >> the widest variation in offered file I/O load (tens of >> millions of small files, thousands of >1GB files). > > Wide variation is not the problem, and neither is the machine, > it is the approach. All other approaches I am aware of cost more. I favor Lustre, but the infrastructure costs alone for a 2-5PB system will tend to be exceptional. Not that we may have much choice - the system we have is well beyond the limits of what we should really be doing - however, the constraints are also exceptional. >> If this workload is pushing XFS too hard, > > XFS is a very good design within a fairly well defined envelope, > and often the problems are more with Linux or application > issues, but you may be a bit outside that envelope (euphemism > alert), and you need to work on the grain of the storage system > (understatement of the week). > >> I can deploy new hardware to split the workload across >> different filesystems. > > My usual recommendation is to default (unless you have > extraordinarily good arguments otherwise, and almost nobody > does) to use RAID10 sets of at most 10 pairs (of "enterprise" > drives of no more than 1TB each), with XFS or JFS depending on > workload, as many servers as needed (if at all possible located > topologically near to their users to avoid some potentially > nasty network syndromes like incast), and forget about having a > single large storage pool. Other details as to the flusher > (every 1-2 seconds), elevator (deadline or noop), ... can matter > a great deal. re RAID10 specifically, I'd love to do something better - however the process is currently severely cost and space constrained. > If you do need a single large storage pool almost the only > reasonable way currently (even if I have great hopes for > GlusterFS) is Lustre or one of its forks (or much simpler > imitators like DPM), and that has its own downsides (it takes a > lot of work), but a single large storage pool is almost never > needed, at most a single large namespace, and that can be > instantiated with an automounter (and Lustre/DPM/.... is in > effect a more sophisticated automounter). "It takes a lot of work" is another reason we aren't readily able to go to other architectures, despite their many advantages. > > If you know better go ahead and build 200TB XFS filesystems on > top of a 7x(16+2) drive RAID60 and put lots of small files in > them (or whatever) and don't even think about 'fsck' because you > "know" it will never happen. And what about backing up one of > those storage sets to another one? That can happen in the > "background" of course, with no extra load :-). fsck happens in less than a day, likewise rebuilding all RAIDs... backups are interesting - it is impossible in the old scenario (our prior generation storage) - possible now due to higher disk and network bandwidth. Keep in mind our ultimate backup is tissue samples. > Just realized another imaginative detail: a 126 drive RAID60 set > delivering 200TB, looks like that you are using 2TB drives. Why > am I not surprised? It would be just picture-perfect if they > were low cost "eco" drives, and only a bit less so if they were > ordinary drives without ERC. Indeed cost conscious budget heroes > can only suggest using 2TB drives in a 126-drive RAID60 set even > for a small-file metadata intensive workload, because IOPS and > concurrent RW are obsolete concepts in many parts of the world. We fortunately are were able to afford reasonably good enterprise drives. 2TB drives are mandatory - there simply isn't enough available space in the data center otherwise. The bulk of the work is not small-file - almost all is large files. > Disclaimer: some smart people I know built knowingly a similar > and fortunately much smaller collection of RAID6 sets because > that was the least worst option for them, and since they know > that it will not fill up before they can replace it, they are > effectively short-stroking all those 2TB drives (I still would > have bought ERC ones if possible) so it's cooler than it looks. That is precisely the situation here - it is the "least worst" option. > >> Thanks very much for any thoughts or suggestions, > > * Don't expect to slap together a lot of stuff at random and it > =A0working just like that. But then if you didn't expect that you > =A0wouldn't have done any of the above. > > * "My usual recommendation" above is freely given yet often > =A0worth more than months/years of very expensive consultants. > > * This mailing list is continuing proof that the "let's bang it > =A0together, it will just work" club is large. Research is research - not my choice of how it is done, either. Paul > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From karn@philkarn.net Thu Jun 2 18:59:31 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p52NxUvm231770 for ; Thu, 2 Jun 2011 18:59:31 -0500 X-ASG-Debug-ID: 1307059169-3ecd01b30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-pw0-f53.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3CD4614E28BD for ; Thu, 2 Jun 2011 16:59:29 -0700 (PDT) Received: from mail-pw0-f53.google.com (mail-pw0-f53.google.com [209.85.160.53]) by cuda.sgi.com with ESMTP id EILo2olvbVNcrBa5 for ; Thu, 02 Jun 2011 16:59:29 -0700 (PDT) Received: by pwj5 with SMTP id 5so792418pwj.26 for ; Thu, 02 Jun 2011 16:59:29 -0700 (PDT) Received: by 10.142.210.5 with SMTP id i5mr217811wfg.8.1307059169195; Thu, 02 Jun 2011 16:59:29 -0700 (PDT) Received: from maggie.qualcomm.com (129-46-76-227.qualcomm.com [129.46.76.227]) by mx.google.com with ESMTPS id o16sm684587wff.1.2011.06.02.16.59.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2011 16:59:28 -0700 (PDT) Message-ID: <4DE823DD.7060600@philkarn.net> Date: Thu, 02 Jun 2011 16:59:25 -0700 From: Phil Karn User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Anderson CC: Peter Grandi , Linux fs XFS X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general References: <19943.56524.969126.59978@tree.ty.sabi.co.UK> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-pw0-f53.google.com[209.85.160.53] X-Barracuda-Start-Time: 1307059170 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0134 1.0000 -1.9339 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.33 X-Barracuda-Spam-Status: No, SCORE=-1.33 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65433 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/2/11 2:24 PM, Paul Anderson wrote: > The data itself has very odd lifecycle behavior, as well - since it is > research, the different stages are still being sorted out, but some > stages are essentially write once, read once, maybe keep, maybe > discard, depending on the research scenario. ... > The bulk of the work is not small-file - almost all is large files. Out of curiosity, do your writers use the fallocate() call? If not, how fragmented do your filesystems get? Even if most of your data isn't read very often, it seems like a good idea to minimize its fragmentation because that also reduces fragmentation of the free list, which makes it easier to keep contiguous other files that *are* heavily read. Also, fewer extents per file means less metadata per file, ergo less metadata and log I/O, etc. When a writer knows in advance how big a file will be, I can't see any downside to having it call fallocate() to let the file system know. Soon after I switched to XFS six months ago I've been running locally patched versions of rsync/tar/cp and so on, and they really do minimize fragmentation with very little effort. From karn@philkarn.net Thu Jun 2 19:06:09 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53069Fk232003 for ; Thu, 2 Jun 2011 19:06:09 -0500 X-ASG-Debug-ID: 1307059568-155801570000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-px0-f174.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F1FEB49968E for ; Thu, 2 Jun 2011 17:06:08 -0700 (PDT) Received: from mail-px0-f174.google.com (mail-px0-f174.google.com [209.85.212.174]) by cuda.sgi.com with ESMTP id 36Cgm6jJf8ypFULg for ; Thu, 02 Jun 2011 17:06:08 -0700 (PDT) Received: by pxi15 with SMTP id 15so911270pxi.5 for ; Thu, 02 Jun 2011 17:06:08 -0700 (PDT) Received: by 10.142.240.9 with SMTP id n9mr216053wfh.104.1307059568105; Thu, 02 Jun 2011 17:06:08 -0700 (PDT) Received: from maggie.qualcomm.com (129-46-76-227.qualcomm.com [129.46.76.227]) by mx.google.com with ESMTPS id l15sm682057wfe.20.2011.06.02.17.06.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2011 17:06:06 -0700 (PDT) Message-ID: <4DE8256C.10706@philkarn.net> Date: Thu, 02 Jun 2011 17:06:04 -0700 From: Phil Karn User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Peter Grandi CC: Linux fs XFS X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general References: <19943.56524.969126.59978@tree.ty.sabi.co.UK> In-Reply-To: <19943.56524.969126.59978@tree.ty.sabi.co.UK> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-px0-f174.google.com[209.85.212.174] X-Barracuda-Start-Time: 1307059568 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65434 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/2/11 11:56 AM, Peter Grandi wrote: > Disclaimer: some smart people I know built knowingly a similar > and fortunately much smaller collection of RAID6 sets because > that was the least worst option for them, and since they know > that it will not fill up before they can replace it, they are > effectively short-stroking all those 2TB drives (I still would > have bought ERC ones if possible) so it's cooler than it looks. What do you mean by "short stroking"? That the data (and head motions) stay in one part of the disk? I haven't been using XFS that long and I'm no expert on it, but I've noticed that it seems to distribute files pretty evenly across an entire disk. Even without the inode64 option, only the inodes are kept at the beginning; the data can be anywhere. The only way I can think of to confine the activity on a lightly-loaded XFS file system to one part of a disk (e.g., to reduce average seek times and to stay in the faster outer area of the drive) is to create partitions that initially span only part of the disk, then grow them later as needed. Is that what you mean? From tytso@thunk.org Thu Jun 2 19:36:23 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_62 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p530aNjl232935 for ; Thu, 2 Jun 2011 19:36:23 -0500 X-ASG-Debug-ID: 1307061382-156201d20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from test.thunk.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 675C849498E for ; Thu, 2 Jun 2011 17:36:22 -0700 (PDT) Received: from test.thunk.org (li9-11.members.linode.com [67.18.176.11]) by cuda.sgi.com with ESMTP id pcKAI1VnjsNCFSZw for ; Thu, 02 Jun 2011 17:36:22 -0700 (PDT) Received: from root (helo=tytso-glaptop) by test.thunk.org with local-esmtp (Exim 4.69) (envelope-from ) id 1QSIN1-0006R1-FN; Fri, 03 Jun 2011 00:36:11 +0000 Received: from tytso by tytso-glaptop with local (Exim 4.71) (envelope-from ) id 1QSIN0-0002cr-EL; Thu, 02 Jun 2011 20:36:10 -0400 Date: Thu, 2 Jun 2011 20:36:10 -0400 From: "Ted Ts'o" To: Andreas Dilger Cc: Eric Sandeen , "Amir G." , Dave Chinner , xfs@oss.sgi.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Message-ID: <20110603003610.GD16306@thunk.org> References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <4DE7A557.9040608@redhat.com> <7D3F86FA-5AA9-49B0-9AFE-F597E83C07B4@dilger.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D3F86FA-5AA9-49B0-9AFE-F597E83C07B4@dilger.ca> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on test.thunk.org); SAEximRunCond expanded to false X-Barracuda-Connect: li9-11.members.linode.com[67.18.176.11] X-Barracuda-Start-Time: 1307061382 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65436 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 02, 2011 at 11:22:53AM -0600, Andreas Dilger wrote: > On 2011-06-02, at 8:59 AM, Eric Sandeen wrote: > > I don't really mind adding ext4dev to FSTYP case statements, it > > -is- something which blkid could, in theory, still return, and > > making xfstests cope with that and try to invoke fsck -t ext4dev > > doesn't bother me too much. It is sadly an fs type embedded into > > a few tools. > > I'm perfectly OK with using ext4dev as a filesystem type that allows testing > changes to ext4 on a system that is already running ext4 as the root fs. My take on this is that way too much time has been spent this subject. Being able to use ext4dev is useful, and given that we have all of this support in our existing system tools, why not use it to make ext4 development more efficient/easy? As a bonus you can build the ext4dev as a module, and that means you the compile/edit/debug cycle can be much faster since you can avoid doing a reboot, for those circumstances where using KVM is not possible/convenient. Personally, I normally use KVM these days, but I can imagine situations where using ext4dev would be a better way to go. For example, I'd probably use KVM on my laptop, but for testing on production servers in a data center, I'd probably use ext4dev, for a variety of local deployment considerations that's not worth going into here. That being said, whether or not we modify xfstests seems to be a moot point. In order for me to do my bigalloc development, I've been patching common.rc so that "/sbin/mkfs.$FSTYP" --> "mkfs.$FSTYP" and "/sbin/fsck -t $FSTYP" --> "fsck.$FSTYP". It's a 3 line change. Not a big deal. I've been making this change using /bin/ed after installing xfstests. So if the XFS folks want to veto this change --- who cares? It's not hard to make the change locally in order to make xfstests. On the other hand, given that xfstests is using "mkfs.$FSTYP", I don't see why it's so important that it clings to "fsck -t $FSTYP" instead of using "fsck.$FSTYP". There's no real benefit to calling the fsck driver; it's just an extra fork and exec, and xfstests is being inconsistent by insisting on the use of the fsck driver, but not using the mkfs driver. But that being said, hacking xfstests is not hard, and if Dave and/or Eric feels strongly about resisting this change, it's not worth a lot of time, one way or another.... - Ted From david@fromorbit.com Thu Jun 2 19:39:12 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p530dC7X233021 for ; Thu, 2 Jun 2011 19:39:12 -0500 X-ASG-Debug-ID: 1307061550-155d01c80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D24C7499A59 for ; Thu, 2 Jun 2011 17:39:10 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id PVvxWMUAgxC8KQkN for ; Thu, 02 Jun 2011 17:39:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIDAMwp6E15LCoegWdsb2JhbABTpjkVAQEWJiWIccB4DoYTBKAw Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Jun 2011 10:09:08 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QSIPr-0000sL-7Y; Fri, 03 Jun 2011 10:39:07 +1000 Date: Fri, 3 Jun 2011 10:39:07 +1000 From: Dave Chinner To: Phil Karn Cc: Paul Anderson , Linux fs XFS X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general Message-ID: <20110603003907.GW561@dastard> References: <19943.56524.969126.59978@tree.ty.sabi.co.UK> <4DE823DD.7060600@philkarn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE823DD.7060600@philkarn.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1307061551 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0020 1.0000 -2.0077 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.41 X-Barracuda-Spam-Status: No, SCORE=-1.41 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65436 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 02, 2011 at 04:59:25PM -0700, Phil Karn wrote: > On 6/2/11 2:24 PM, Paul Anderson wrote: > > > The data itself has very odd lifecycle behavior, as well - since it is > > research, the different stages are still being sorted out, but some > > stages are essentially write once, read once, maybe keep, maybe > > discard, depending on the research scenario. > ... > > The bulk of the work is not small-file - almost all is large files. > > Out of curiosity, do your writers use the fallocate() call? If not, how > fragmented do your filesystems get? > > Even if most of your data isn't read very often, it seems like a good > idea to minimize its fragmentation because that also reduces > fragmentation of the free list, which makes it easier to keep contiguous > other files that *are* heavily read. Also, fewer extents per file means > less metadata per file, ergo less metadata and log I/O, etc. > > When a writer knows in advance how big a file will be, I can't see any > downside to having it call fallocate() to let the file system know. You're ignoring the fact that delayed allocation effectively does this for you without needing to physically allocate the blocks. So when you have files that are short lived, you don't actually do any allocation at all, Further delayed allocation results in allocation order according to writeback order rather than write() order, so I/O patterns are much nicer when using delayed allocation. Basicaly you are removing one of the major IO optimisation capabilities of XFS by preallocating everything like this. > Soon > after I switched to XFS six months ago I've been running locally patched > versions of rsync/tar/cp and so on, and they really do minimize > fragmentation with very little effort. So you don't have any idea of how well XFS minimises fragmentation without needing to use preallocation? Sounds like you have a classic case of premature optimisation. ;) Cheers, Dave. -- Dave Chinner david@fromorbit.com From BATV+e5b82cb630e58a74e26a+2840+infradead.org+hch@bombadil.srs.infradead.org Thu Jun 2 19:42:50 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p530gnkp233132 for ; Thu, 2 Jun 2011 19:42:50 -0500 X-ASG-Debug-ID: 1307061768-156c01c80000-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 DA79B499A88 for ; Thu, 2 Jun 2011 17:42:48 -0700 (PDT) Received: from bombadil.infradead.org (173-166-109-252-newengland.hfc.comcastbusiness.net [173.166.109.252]) by cuda.sgi.com with ESMTP id lYEGr65fNLAM69IE for ; Thu, 02 Jun 2011 17:42:48 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1QSITP-0002RF-LI; Fri, 03 Jun 2011 00:42:47 +0000 Date: Thu, 2 Jun 2011 20:42:47 -0400 From: Christoph Hellwig To: Paul Anderson Cc: xfs-oss X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general Message-ID: <20110603004247.GA28043@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.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: 173-166-109-252-newengland.hfc.comcastbusiness.net[173.166.109.252] X-Barracuda-Start-Time: 1307061768 X-Barracuda-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.32 X-Barracuda-Spam-Status: No, SCORE=-1.32 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65436 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 02, 2011 at 10:42:46AM -0400, Paul Anderson wrote: > This morning, I had a symptom of a I/O throughput problem in which > dirty pages appeared to be taking a long time to write to disk. > > The system is a large x64 192GiB dell 810 server running 2.6.38.5 from > kernel.org - the basic workload was data intensive - concurrent large > NFS (with high metadata/low filesize), rsync/lftp (with low > metadata/high file size) all working in a 200TiB XFS volume on a > software MD raid0 on top of 7 software MD raid6, each w/18 drives. I > had mounted the filesystem with inode64,largeio,logbufs=8,noatime. A few comments on the setup before trying to analze what's going on in detail. I'd absolutely recommend an external log device for this setup, that is buy another two fast but small disks, or take two existing ones and use a RAID 1 for the external log device. This will speed up anything log intensive, which both NFS, and resync workloads are lot. Second thing if you can split the workloads into multiple volumes if you have two such different workloads, so thay they don't interfear with each other. Second a RAID0 on top of RAID6 volumes sounds like a pretty worst case for almost any type of I/O. You end up doing even relatively small I/O to all of the disks in the worst case. I think you'd be much better off with a simple linear concatenation of the RAID6 devices, even if you can split them into multiple filesystems > The specific symptom was that 'sync' hung, a dpkg command hung > (presumably trying to issue fsync), and experimenting with "killall > -STOP" or "kill -STOP" of the workload jobs didn't let the system > drain I/O enough to finish the sync. I probably did not wait long > enough, however. It really sounds like you're simply killloing the MD setup with a log of log I/O that does to all the devices. From david@fromorbit.com Thu Jun 2 20:39:54 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p531dr1F235346 for ; Thu, 2 Jun 2011 20:39:54 -0500 X-ASG-Debug-ID: 1307065191-145d027f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3D8C6D6E2D9 for ; Thu, 2 Jun 2011 18:39:51 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id phGOGRDfYheeYoAx for ; Thu, 02 Jun 2011 18:39:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIDAMc36E15LCoegWdsb2JhbABTpjkVAQEWJiXJXQ6GEwSgMA Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Jun 2011 11:09:50 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QSJMa-0000yf-AF; Fri, 03 Jun 2011 11:39:48 +1000 Date: Fri, 3 Jun 2011 11:39:48 +1000 From: Dave Chinner To: Christoph Hellwig Cc: Paul Anderson , xfs-oss X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general Message-ID: <20110603013948.GX561@dastard> References: <20110603004247.GA28043@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110603004247.GA28043@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1307065192 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65441 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 02, 2011 at 08:42:47PM -0400, Christoph Hellwig wrote: > On Thu, Jun 02, 2011 at 10:42:46AM -0400, Paul Anderson wrote: > > This morning, I had a symptom of a I/O throughput problem in which > > dirty pages appeared to be taking a long time to write to disk. > > > > The system is a large x64 192GiB dell 810 server running 2.6.38.5 from > > kernel.org - the basic workload was data intensive - concurrent large > > NFS (with high metadata/low filesize), rsync/lftp (with low > > metadata/high file size) all working in a 200TiB XFS volume on a > > software MD raid0 on top of 7 software MD raid6, each w/18 drives. I > > had mounted the filesystem with inode64,largeio,logbufs=8,noatime. > > A few comments on the setup before trying to analze what's going on in > detail. I'd absolutely recommend an external log device for this setup, > that is buy another two fast but small disks, or take two existing ones > and use a RAID 1 for the external log device. This will speed up > anything log intensive, which both NFS, and resync workloads are lot. > > Second thing if you can split the workloads into multiple volumes if you > have two such different workloads, so thay they don't interfear with > each other. > > Second a RAID0 on top of RAID6 volumes sounds like a pretty worst case > for almost any type of I/O. You end up doing even relatively small I/O > to all of the disks in the worst case. I think you'd be much better > off with a simple linear concatenation of the RAID6 devices, even if you > can split them into multiple filesystems > > > The specific symptom was that 'sync' hung, a dpkg command hung > > (presumably trying to issue fsync), and experimenting with "killall > > -STOP" or "kill -STOP" of the workload jobs didn't let the system > > drain I/O enough to finish the sync. I probably did not wait long > > enough, however. > > It really sounds like you're simply killloing the MD setup with a > log of log I/O that does to all the devices. And this is one of the reasons why I originally suggested that storage at this scale really should be using hardware RAID with large amounts of BBWC to isolate the backend from such problematic IO patterns. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Thu Jun 2 21:01:33 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5321WcJ236669 for ; Thu, 2 Jun 2011 21:01:32 -0500 X-ASG-Debug-ID: 1307066489-145e02b20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9FE9C1239851 for ; Thu, 2 Jun 2011 19:01:30 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id 73AGp0iCnYD18DOT for ; Thu, 02 Jun 2011 19:01:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMDAOY+6E15LCoegWdsb2JhbABThEmhcBUBARYmJbkSkF8OgR2DbIEKBKAw Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Jun 2011 11:31:29 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QSJhX-00010y-U0; Fri, 03 Jun 2011 12:01:27 +1000 Date: Fri, 3 Jun 2011 12:01:27 +1000 From: Dave Chinner To: Eric Sandeen Cc: "Amir G." , xfs@oss.sgi.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Message-ID: <20110603020127.GY561@dastard> References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <4DE7A557.9040608@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4DE7A557.9040608@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1307066491 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65441 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 02, 2011 at 09:59:35AM -0500, Eric Sandeen wrote: > On 6/2/11 2:16 AM, Amir G. wrote: > > > OK, after upgrading to newer util-linux and building it from > > git, which also didn't help, I finally found who to blame - me. > > I had an old (noauto) entry in /etc/fstab which claimed that > > /dev/sda5 is ext4. fsck was picking up that entry and insisting > > that /dev/sda5 is ext4 (regardless of what it really is) blkid > > isn't doing that silly thing. > > > > Amir > > So where are we at with all this? > > I don't really mind adding ext4dev to FSTYP case statements, it > -is- something which blkid could, in theory, still return, and > making xfstests cope with that and try to invoke fsck -t ext4dev > doesn't bother me too much. It is sadly an fs type embedded into > a few tools. > > But other than that, I don't think we should be making changes to > upstream projects based on your current development hacks (I don't > mean hack in a bad way, just that running sed across ext4 to > create your custom filesystem for testing should not require > upstream projects to change...) > > So I'm ok with sprinkling "ext4|ext4dev" around if necessary. > Anyone else disagree? Іf it is ext4 community decides that ext4dev is not deprecated then I don't have any objection. It won't cause me any PEBKAC problems. ;) Cheers, Dave. -- Dave Chinner david@fromorbit.com From karn@philkarn.net Thu Jun 2 21:11:38 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p532BbJE237156 for ; Thu, 2 Jun 2011 21:11:38 -0500 X-ASG-Debug-ID: 1307067095-5667008c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-vw0-f53.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1CB9CD21084 for ; Thu, 2 Jun 2011 19:11:35 -0700 (PDT) Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com [209.85.212.53]) by cuda.sgi.com with ESMTP id hW7XvZBKaOQqHnVJ for ; Thu, 02 Jun 2011 19:11:35 -0700 (PDT) Received: by vws13 with SMTP id 13so1210687vws.26 for ; Thu, 02 Jun 2011 19:11:35 -0700 (PDT) Received: by 10.52.174.176 with SMTP id bt16mr1938897vdc.282.1307067095084; Thu, 02 Jun 2011 19:11:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.183.105 with HTTP; Thu, 2 Jun 2011 19:11:15 -0700 (PDT) Reply-To: karn@ka9q.net In-Reply-To: <20110603003907.GW561@dastard> References: <19943.56524.969126.59978@tree.ty.sabi.co.UK> <4DE823DD.7060600@philkarn.net> <20110603003907.GW561@dastard> From: Phil Karn Date: Thu, 2 Jun 2011 19:11:15 -0700 Message-ID: X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general To: Dave Chinner Cc: Paul Anderson , Linux fs XFS Content-Type: multipart/alternative; boundary=bcaec51ba1f5e66e2004a4c545ff X-Barracuda-Connect: mail-vw0-f53.google.com[209.85.212.53] X-Barracuda-Start-Time: 1307067096 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65443 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --bcaec51ba1f5e66e2004a4c545ff Content-Type: text/plain; charset=UTF-8 On Thu, Jun 2, 2011 at 5:39 PM, Dave Chinner wrote: > > You're ignoring the fact that delayed allocation effectively does > this for you without needing to physically allocate the blocks. > So when you have files that are short lived, you don't actually do > any allocation at all, Further delayed allocation results in > allocation order according to writeback order rather than write() > order, so I/O patterns are much nicer when using delayed allocation. > Oh, I'm well aware of delayed allocation. I've just noticed that, in my experience, it doesn't seem to work nearly as well as fallocate(). And why should it? If you know in advance how big a file you're writing, how can it hurt to inform your file system? I suppose the FS implementer could always ignore that information if he felt he could somehow do a better job, but it's hard to see how. Isn't it always better to know than to guess? I'm talking here about the genuine fallocate() system call, not the POSIX hack that falls back to first conventionally writing zeroes over the file. The true fallocate() call seems very fast, and if your file system doesn't support it then it will simply fail without harm. I still can't see any reason not to use it. I did know that xfs can avoid the disk allocation and writes entirely when the files are short-lived, but Paul was talking about writing large, long-lived files so that's what I had in mind. And when I use fallocate(), my files are not likely to be short-lived either. Like most people I write the vast majority of my short-lived files to /tmp, which is tmpfs, not xfs. But you do raise an interesting point -- is there any serious performance degradation from using fallocate() on a short-lived file? The written data still lives in the buffer cache for a while, so if you delete the file before it gets flushed the disk writes will still be avoided. The file system may have a little extra work to undo the unnecessary allocation but that doesn't seem to be a big deal. Basicaly you are removing one of the major IO optimisation > capabilities of XFS by preallocating everything like this. > "Remove" it? How is giving it the correct answer worse than letting it guess -- even if it usually guesses correctly? I still rely on preallocation to keep log files and mailboxes from getting too badly fragmented. >So you don't have any idea of how well XFS minimises fragmentation > without needing to use preallocation? Sounds like you have a classic > case of premature optimisation. ;) > > As I said, I've tried it both ways. I found that the simple act of adding fallocate() to rsync (which I use for practically all copying) vastly reduces xfs fragmentation. Just as I expected it would. Maybe I'm a little more sensitive to fragmentation than most because I've been experimenting with storing SHA1 hashes of all my files in external attributes. This grew out of a data deduplication tool; at first I simply cached the hashes so I wouldn't have to recompute them on another run, but then I just added them to every file. This lets me get a warm and fuzzy feeling by periodically verifying that my files haven't been corrupted, especially when I began to use SSDs with trim tools. XFS stores both attributes and extent lists directly in the inode when there's room, and it turns out that a default-sized xfs inode can store my hashes provided that the extent list is small. So I now when I walk through my file system statting everything I can read the hashes too at absolutely no extra cost. This makes deduplication really fast. I haven't experimented to see how many extents a file can have before the attributes get pushed out of the inode, but by keeping most everything contiguous I simply avoid the problem. --bcaec51ba1f5e66e2004a4c545ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 2, 2011 at 5:39 PM, Dave Chinner <david@fromorbit.com> wrote:

You're ignoring the fact that delayed allocation effectively does=
this for you without needing to physically allocate the blocks.
So when you have files that are short lived, you don't actually do
any allocation at all, Further delayed allocation results in
allocation order according to writeback order rather than write()
order, so I/O patterns are much nicer when using delayed allocation.

Oh, I'm well aware of delayed allocation. I've j= ust noticed that, in my experience, it doesn't seem to work nearly as w= ell as fallocate(). And why should it? If you know in advance how big a fil= e you're writing, how can it hurt to inform your file system? I suppose= the FS implementer could always ignore that information if he felt he coul= d somehow do a better job, but it's hard to see how. Isn't it alway= s better to know than to guess?

I'm talking here about the genuine fallocate() system call, not the= POSIX hack that falls back to first conventionally writing zeroes over the= file. The true fallocate() call seems very fast, and if your file system d= oesn't support it then it will simply fail without harm. I still can= 9;t see any reason not to use it.

I did know that xfs can avoid the disk allocation and writes entirely w= hen the files are short-lived, but Paul was talking about writing large, lo= ng-lived files so that's what I had in mind. And when I use fallocate()= , my files are not likely to be short-lived either. Like most people I writ= e the vast majority of my short-lived files to /tmp, which is tmpfs, not xf= s.

But you do raise an interesting point -- is there any serious performan= ce degradation from using fallocate() on a short-lived file? The written da= ta still lives in the buffer cache for a while, so if you delete the file b= efore it gets flushed the disk writes will still be avoided. The file syste= m may have a little extra work to undo the unnecessary allocation but that = doesn't seem to be a big deal.

Basicaly you are removing one of the major IO optimisation
capabilities of XFS by preallocating everything like this.
=

"Remove" it? How is giving it the correct answer worse t= han letting it guess -- even if it usually guesses correctly?

I stil= l rely on preallocation to keep log files and mailboxes from getting too ba= dly fragmented.

>So you don't have any idea of how well XFS minimises fragmentat= ion
without needing to use preallocation? Sounds like you have a classic
case of premature optimisation. ;)


As I said, = I've tried it both ways. I found that the simple act of adding fallocat= e() to rsync (which I use for practically all copying) vastly reduces xfs f= ragmentation. Just as I expected it would.

Maybe I'm a little more sensitive to fragmentation than most becaus= e I've been experimenting with storing SHA1 hashes of all my files in e= xternal attributes. This grew out of a data deduplication tool; at first I = simply cached the hashes so I wouldn't have to recompute them on anothe= r run, but then I just added them to every file. This lets me get a warm an= d fuzzy feeling by periodically verifying that my files haven't been co= rrupted, especially when I began to use SSDs with trim tools.

XFS stores both attributes and extent lists directly in the inode when = there's room, and it turns out that a default-sized xfs inode can store= my hashes provided that the extent list is small. So I now when I walk thr= ough my file system statting everything I can read the hashes too at absolu= tely no extra cost. This makes deduplication really fast.

I haven't experimented to see how many extents a file can have befo= re the attributes get pushed out of the inode, but by keeping most everythi= ng contiguous I simply avoid the problem.



--bcaec51ba1f5e66e2004a4c545ff-- From david@fromorbit.com Thu Jun 2 21:55:23 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p532tMxZ242157 for ; Thu, 2 Jun 2011 21:55:23 -0500 X-ASG-Debug-ID: 1307069719-35fc02610000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0E8221D70514 for ; Thu, 2 Jun 2011 19:55:19 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id jXD1mPyzlW9i3NRw for ; Thu, 02 Jun 2011 19:55:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIDANxM6E15LCoegWdsb2JhbABTpjkVAQEWJiWIccEBDoYTBKAw Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Jun 2011 12:25:01 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QSKXM-00016P-0H; Fri, 03 Jun 2011 12:55:00 +1000 Date: Fri, 3 Jun 2011 12:54:59 +1000 From: Dave Chinner To: karn@ka9q.net Cc: Paul Anderson , Linux fs XFS X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general Message-ID: <20110603025459.GB561@dastard> References: <19943.56524.969126.59978@tree.ty.sabi.co.UK> <4DE823DD.7060600@philkarn.net> <20110603003907.GW561@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1307069721 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0207 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65446 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 02, 2011 at 07:11:15PM -0700, Phil Karn wrote: > On Thu, Jun 2, 2011 at 5:39 PM, Dave Chinner wrote: > > > > > You're ignoring the fact that delayed allocation effectively does > > this for you without needing to physically allocate the blocks. > > So when you have files that are short lived, you don't actually do > > any allocation at all, Further delayed allocation results in > > allocation order according to writeback order rather than write() > > order, so I/O patterns are much nicer when using delayed allocation. > > > > Oh, I'm well aware of delayed allocation. I've just noticed that, in my > experience, it doesn't seem to work nearly as well as fallocate(). And why > should it? If you know in advance how big a file you're writing, how can it > hurt to inform your file system? I suppose the FS implementer could always > ignore that information if he felt he could somehow do a better job, but > it's hard to see how. Isn't it always better to know than to guess? There are definitely cases where it helps for preventing fragmenting, but as a sweeping generalisation it is very, very wrong. > I'm talking here about the genuine fallocate() system call, not the POSIX > hack that falls back to first conventionally writing zeroes over the file. > The true fallocate() call seems very fast, and if your file system doesn't > support it then it will simply fail without harm. I still can't see any > reason not to use it. > > I did know that xfs can avoid the disk allocation and writes entirely when > the files are short-lived, but Paul was talking about writing large, > long-lived files so that's what I had in mind. And when I use fallocate(), > my files are not likely to be short-lived either. Like most people I write > the vast majority of my short-lived files to /tmp, which is tmpfs, not xfs. Do you do that for temporary object files when you build from source? > But you do raise an interesting point -- is there any serious performance > degradation from using fallocate() on a short-lived file? Allocation and freeing has CPU overhead, transaction overhead, log space overhead, can cause free space fragmentation when you have a mix of short- and long-lived files being preallocated at the same time, IO for long lived data does not get packed together closely so requires more seeks to issue which leads to significantly worse IO performance on RAID5/6 storage sub-systems, etc. I could go one for quite some time, but the overal effect of such behaviour is that it speeds up filesystem aging degradation significantly. You might not notice that for 6 months or a year, but when you do.... > The written data > still lives in the buffer cache for a while, so if you delete the file > before it gets flushed the disk writes will still be avoided. The file > system may have a little extra work to undo the unnecessary allocation but > that doesn't seem to be a big deal. > > Basicaly you are removing one of the major IO optimisation > > capabilities of XFS by preallocating everything like this. > > > > "Remove" it? How is giving it the correct answer worse than letting it guess > -- even if it usually guesses correctly? See above. > I still rely on preallocation to keep log files and mailboxes from getting > too badly fragmented. > > >So you don't have any idea of how well XFS minimises fragmentation > > > without needing to use preallocation? Sounds like you have a classic > > case of premature optimisation. ;) > > > > > As I said, I've tried it both ways. I found that the simple act of adding > fallocate() to rsync (which I use for practically all copying) vastly > reduces xfs fragmentation. Just as I expected it would. > > Maybe I'm a little more sensitive to fragmentation than most because I've > been experimenting with storing SHA1 hashes of all my files in external > attributes. This grew out of a data deduplication tool; at first I simply > cached the hashes so I wouldn't have to recompute them on another run, but > then I just added them to every file. This lets me get a warm and fuzzy > feeling by periodically verifying that my files haven't been corrupted, > especially when I began to use SSDs with trim tools. > > XFS stores both attributes and extent lists directly in the inode when > there's room, and it turns out that a default-sized xfs inode can store my > hashes provided that the extent list is small. So I now when I walk through > my file system statting everything I can read the hashes too at absolutely > no extra cost. This makes deduplication really fast. /me slaps his forehead. You do realise that your "attr out of line" problem would have gone away by simply increasing the XFS inode size at mkfs time? And that there is almost no performance penalty for doing this? Instead, it seems you found a hammer named fallocate() and proceeded to treat every tool you have like a nail. :) Changing a single mkfs parameter is far less work than maintaining your own forks of multiple tools.... > I haven't experimented to see how many extents a file can have > before the attributes get pushed out of the inode, but by keeping > most everything contiguous I simply avoid the problem. Until aging has degraded your filesystem til free space is sufficiently fragmented that you can't allocate large extents any more. Then you are completely screwed. :/ Cheers, Dave. -- Dave Chinner david@fromorbit.com From sandeen@redhat.com Thu Jun 2 22:26:19 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,J_CHICKENPOX_21, J_CHICKENPOX_33,J_CHICKENPOX_62 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p533QJ5t248761 for ; Thu, 2 Jun 2011 22:26:19 -0500 X-ASG-Debug-ID: 1307071577-768b003d0000-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 C3022499B9F for ; Thu, 2 Jun 2011 20:26:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id HSKyTbVzGoRxwTtC for ; Thu, 02 Jun 2011 20:26:17 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p533QA5V032757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 23:26:10 -0400 Received: from liberator.sandeen.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p533Q5Ex031468 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 23:26:07 -0400 Message-ID: <4DE8544D.30800@redhat.com> Date: Thu, 02 Jun 2011 22:26:05 -0500 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Ted Ts'o" CC: Andreas Dilger , "Amir G." , Dave Chinner , xfs@oss.sgi.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <4DE7A557.9040608@redhat.com> <7D3F86FA-5AA9-49B0-9AFE-F597E83C07B4@dilger.ca> <20110603003610.GD16306@thunk.org> In-Reply-To: <20110603003610.GD16306@thunk.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1307071578 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/2/11 7:36 PM, Ted Ts'o wrote: > On Thu, Jun 02, 2011 at 11:22:53AM -0600, Andreas Dilger wrote: >> On 2011-06-02, at 8:59 AM, Eric Sandeen wrote: >>> I don't really mind adding ext4dev to FSTYP case statements, it >>> -is- something which blkid could, in theory, still return, and >>> making xfstests cope with that and try to invoke fsck -t ext4dev >>> doesn't bother me too much. It is sadly an fs type embedded into >>> a few tools. >> >> I'm perfectly OK with using ext4dev as a filesystem type that allows testing >> changes to ext4 on a system that is already running ext4 as the root fs. > > My take on this is that way too much time has been spent this subject. > Being able to use ext4dev is useful, and given that we have all of > this support in our existing system tools, why not use it to make ext4 > development more efficient/easy? As a bonus you can build the ext4dev > as a module, and that means you the compile/edit/debug cycle can be > much faster since you can avoid doing a reboot, for those > circumstances where using KVM is not possible/convenient. Personally, > I normally use KVM these days, but I can imagine situations where > using ext4dev would be a better way to go. For example, I'd probably > use KVM on my laptop, but for testing on production servers in a data > center, I'd probably use ext4dev, for a variety of local deployment > considerations that's not worth going into here. > > That being said, whether or not we modify xfstests seems to be a moot > point. In order for me to do my bigalloc development, I've been > patching common.rc so that "/sbin/mkfs.$FSTYP" --> "mkfs.$FSTYP" and > "/sbin/fsck -t $FSTYP" --> "fsck.$FSTYP". It's a 3 line change. Not > a big deal. I've been making this change using /bin/ed after > installing xfstests. So if the XFS folks want to veto this change --- > who cares? It's not hard to make the change locally in order to make > xfstests. > > On the other hand, given that xfstests is using "mkfs.$FSTYP", I don't > see why it's so important that it clings to "fsck -t $FSTYP" instead > of using "fsck.$FSTYP". There's no real benefit to calling the fsck > driver; it's just an extra fork and exec, and xfstests is being > inconsistent by insisting on the use of the fsck driver, but not using > the mkfs driver. > > But that being said, hacking xfstests is not hard, and if Dave and/or > Eric feels strongly about resisting this change, it's not worth a lot > of time, one way or another.... I think we just want to make sure we understand the reasons for a change. Every change has risks, and xfstests is used on a lot of different systems. If I don't fully understand the motivation for a change, I ask questions. All part of a careful review. And I apologize for the mkfs vs. fsck inconsistency, that was probably my fault, originally ;) -Eric > - Ted From sandeen@redhat.com Thu Jun 2 22:33:09 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_62,J_CHICKENPOX_65,J_CHICKENPOX_66 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p533X90b249388 for ; Thu, 2 Jun 2011 22:33:09 -0500 X-ASG-Debug-ID: 1307071988-565e02500000-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 A1D4C12CFDD6 for ; Thu, 2 Jun 2011 20:33:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id BEcbxx0Nd0XG5Xk6 for ; Thu, 02 Jun 2011 20:33:08 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p533X7xQ018747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2011 23:33:07 -0400 Received: from liberator.sandeen.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p533Wxtl004274 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 23:33:05 -0400 Message-ID: <4DE855EB.6020207@redhat.com> Date: Thu, 02 Jun 2011 22:32:59 -0500 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: amir73il@users.sourceforge.net CC: xfs@oss.sgi.com, sergey57@gmail.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, Amir Goldstein X-ASG-Orig-Subj: Re: [PATCH v3] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v3] xfstests: add support for ext4dev FSTYP References: <1306988221-3543-1-git-send-email-amir73il@users.sourceforge.net> In-Reply-To: <1306988221-3543-1-git-send-email-amir73il@users.sourceforge.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1307071988 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/1/11 11:17 PM, amir73il@users.sourceforge.net wrote: > From: Amir Goldstein > > blkid knows to identify the ext4dev FSTYP of a partition that was > formatted with mkfs.ext4dev. > quota tools and various util-linux utils are also aware of ext4dev, > so ext4dev shares the same capabilities as ext4. > > Signed-off-by: Amir Goldstein > Tested-by: Sergey Ivanov > --- > ext4dev is used to test experimental ext4 code in mutual existance > with production ext4 code on the same system. > > Specifically, ext4 snapshots code is available for testing as a > stand-alone ext4dev module for Fedora 15 and Ubuntu 11.4 > (see http://next3.sf.net). > > v2 -> v3: > - change if to case statement > > v1 -> v2: > - undo change of fsck -t $FSTYP to fsck.$FSTYP looks good to me, and thanks for fixing up the case statement :) I'll merge this tonight to the xfstests-dev tree. -Eric > common.defrag | 2 +- > common.quota | 10 +++++++--- > common.rc | 10 +++++----- > 3 files changed, 13 insertions(+), 9 deletions(-) > > diff --git a/common.defrag b/common.defrag > index 1bcf01d..4850803 100644 > --- a/common.defrag > +++ b/common.defrag > @@ -26,7 +26,7 @@ _require_defrag() > xfs) > DEFRAG_PROG=/usr/sbin/xfs_fsr > ;; > - ext4) > + ext4|ext4dev) > DEFRAG_PROG=/usr/bin/e4defrag > ;; > *) > diff --git a/common.quota b/common.quota > index 3c87ce1..9736306 100644 > --- a/common.quota > +++ b/common.quota > @@ -29,7 +29,7 @@ _require_quota() > [ -n $QUOTA_PROG ] || _notrun "Quota user tools not installed" > > case $FSTYP in > - ext2|ext3|ext4|reiserfs) > + ext2|ext3|ext4|ext4dev|reiserfs) > if [ ! -d /proc/sys/fs/quota ]; then > _notrun "Installed kernel does not support quotas" > fi > @@ -237,10 +237,14 @@ _check_quota_usage() > # Sync to get delalloc to disk > sync > VFS_QUOTA=0 > - if [ $FSTYP = "ext2" -o $FSTYP = "ext3" -o $FSTYP = "ext4" -o $FSTYP = "reiserfs" ]; then > + case $FSTYP in > + ext2|ext3|ext4|ext4dev|reiserfs) > VFS_QUOTA=1 > quotaon -f -u -g $SCRATCH_MNT 2>/dev/null > - fi > + ;; > + *) > + ;; > + esac > repquota -u -n $SCRATCH_MNT | grep -v "^#0" | _filter_scratch | > sort >$tmp.user.orig > repquota -g -n $SCRATCH_MNT | grep -v "^#0" | _filter_scratch | > diff --git a/common.rc b/common.rc > index e634fbb..c510c66 100644 > --- a/common.rc > +++ b/common.rc > @@ -65,7 +65,7 @@ _mount_opts() > nfs) > export MOUNT_OPTIONS=$NFS_MOUNT_OPTIONS > ;; > - ext2|ext3|ext4) > + ext2|ext3|ext4|ext4dev) > # acls & xattrs aren't turned on by default on ext$FOO > export MOUNT_OPTIONS="-o acl,user_xattr $EXT_MOUNT_OPTIONS" > ;; > @@ -110,7 +110,7 @@ _mkfs_opts() > _fsck_opts() > { > case $FSTYP in > - ext2|ext3|ext4) > + ext2|ext3|ext4|ext4dev) > export FSCK_OPTIONS="-nf" > ;; > reiserfs) > @@ -326,10 +326,10 @@ _scratch_mkfs_sized() > xfs) > _scratch_mkfs_xfs -d size=$fssize -b size=$blocksize > ;; > - ext2|ext3|ext4) > + ext2|ext3|ext4|ext4dev) > /sbin/mkfs.$FSTYP $MKFS_OPTIONS -b $blocksize $SCRATCH_DEV $blocks > ;; > - btrfs) > + btrfs) > /sbin/mkfs.$FSTYP $MKFS_OPTIONS $SCRATCH_DEV -b $fssize > ;; > *) > @@ -354,7 +354,7 @@ _scratch_mkfs_geom() > xfs) > MKFS_OPTIONS+=" -b size=$blocksize, -d su=$sunit_bytes,sw=$swidth_mult" > ;; > - ext4) > + ext4|ext4dev) > MKFS_OPTIONS+=" -b $blocksize -E stride=$sunit_blocks,stripe_width=$swidth_blocks" > ;; > *) From amir73il@gmail.com Thu Jun 2 23:59:27 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,J_CHICKENPOX_21, J_CHICKENPOX_33,J_CHICKENPOX_62,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p534xRc6255063 for ; Thu, 2 Jun 2011 23:59:27 -0500 X-ASG-Debug-ID: 1307077166-7287032d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ww0-f41.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1BE3E496A1B for ; Thu, 2 Jun 2011 21:59:26 -0700 (PDT) Received: from mail-ww0-f41.google.com (mail-ww0-f41.google.com [74.125.82.41]) by cuda.sgi.com with ESMTP id AppcyPOZqVjGtTex for ; Thu, 02 Jun 2011 21:59:26 -0700 (PDT) Received: by wwi18 with SMTP id 18so4686973wwi.2 for ; Thu, 02 Jun 2011 21:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gv+CqV3RBhjXE1IvjJoOzkXtuB5nm/oSiLht6wIasJ4=; b=MWUKwcq7h1kY36Eh6gmYUnJkdTbTcv5uHO2+P2jSRCCYvIQUMnQR89emkMVbUl2EyG Bln5C9lbYP2LWNltggxphdnaOZyK92HIDah0hdO8eg5CmwCWGmebEzEJVx8fF9/TJZ0Y EzRYKNe7f2As4zrJUeQ/bd/iytAKN+VW44DoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Q7FQahQUdDa+6SnVl/ANLdh1wJmdPCJJx2EYdP+DYB0PPUkMURz+BZTV8RhWIVIS4u VgpC6IETVp8QQBIWT02u/Gsj1oA3TyJ9TDVH0l3XkHLrSXSQeLGhz4YP1s0qfRxvKMMg mbsbF35/TFtqb7ckp7yxliyxZfoHnEIpaCr6Y= MIME-Version: 1.0 Received: by 10.216.221.29 with SMTP id q29mr6843857wep.6.1307077165901; Thu, 02 Jun 2011 21:59:25 -0700 (PDT) Sender: amir73il@gmail.com Received: by 10.216.21.209 with HTTP; Thu, 2 Jun 2011 21:59:25 -0700 (PDT) In-Reply-To: <20110603003610.GD16306@thunk.org> References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <4DE7A557.9040608@redhat.com> <7D3F86FA-5AA9-49B0-9AFE-F597E83C07B4@dilger.ca> <20110603003610.GD16306@thunk.org> Date: Fri, 3 Jun 2011 07:59:25 +0300 X-Google-Sender-Auth: OuToYFEjOMwk-3skbiFVl2b9fCM Message-ID: X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP From: "Amir G." To: "Ted Ts'o" Cc: Andreas Dilger , Eric Sandeen , Dave Chinner , xfs@oss.sgi.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-ww0-f41.google.com[74.125.82.41] X-Barracuda-Start-Time: 1307077167 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65450 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, Jun 3, 2011 at 3:36 AM, Ted Ts'o wrote: > On Thu, Jun 02, 2011 at 11:22:53AM -0600, Andreas Dilger wrote: >> On 2011-06-02, at 8:59 AM, Eric Sandeen wrote: >> > I don't really mind adding ext4dev to FSTYP case statements, it >> > -is- something which blkid could, in theory, still return, and >> > making xfstests cope with that and try to invoke fsck -t ext4dev >> > doesn't bother me too much. =A0It is sadly an fs type embedded into >> > a few tools. >> >> I'm perfectly OK with using ext4dev as a filesystem type that allows tes= ting >> changes to ext4 on a system that is already running ext4 as the root fs. > > My take on this is that way too much time has been spent this subject. No doubt. > Being able to use ext4dev is useful, and given that we have all of > this support in our existing system tools, why not use it to make ext4 > development more efficient/easy? =A0As a bonus you can build the ext4dev > as a module, and that means you the compile/edit/debug cycle can be > much faster since you can avoid doing a reboot, for those > circumstances where using KVM is not possible/convenient. =A0Personally, > I normally use KVM these days, but I can imagine situations where > using ext4dev would be a better way to go. =A0For example, I'd probably > use KVM on my laptop, but for testing on production servers in a data > center, I'd probably use ext4dev, for a variety of local deployment > considerations that's not worth going into here. > > That being said, whether or not we modify xfstests seems to be a moot > point. =A0In order for me to do my bigalloc development, I've been > patching common.rc so that "/sbin/mkfs.$FSTYP" --> "mkfs.$FSTYP" and > "/sbin/fsck -t $FSTYP" --> "fsck.$FSTYP". =A0It's a 3 line change. =A0Not > a big deal. =A0I've been making this change using /bin/ed after > installing xfstests. =A0So if the XFS folks want to veto this change --- > who cares? =A0It's not hard to make the change locally in order to make > xfstests. > > On the other hand, given that xfstests is using "mkfs.$FSTYP", I don't > see why it's so important that it clings to "fsck -t $FSTYP" instead > of using "fsck.$FSTYP". =A0There's no real benefit to calling the fsck > driver; it's just an extra fork and exec, and xfstests is being > inconsistent by insisting on the use of the fsck driver, but not using > the mkfs driver. > > But that being said, hacking xfstests is not hard, and if Dave and/or > Eric feels strongly about resisting this change, it's not worth a lot > of time, one way or another.... > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0- Ted > I blame only myself for not presenting the case correctly. I made it sound like I am trying to push my own private hack upstream. Actually, all 10 people involved in snapshot development clone my xfstests tree from github, so we have no real need for the upstream change. The reason I was pushing upstream is because I found this feature so useful, I thought other developers may enjoy it as well. Anyone on on this thread not having used ext4dev by next LSF can come to me to claim his beer ;-) Amir. From sandeen@redhat.com Fri Jun 3 00:06:21 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,J_CHICKENPOX_21, J_CHICKENPOX_33,J_CHICKENPOX_62 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5356LAk257744 for ; Fri, 3 Jun 2011 00:06:21 -0500 X-ASG-Debug-ID: 1307077580-566c00ff0000-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 B648112CFF70 for ; Thu, 2 Jun 2011 22:06:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id kEEsAM2sPpD7TsX5 for ; Thu, 02 Jun 2011 22:06:20 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5356B8E024555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2011 01:06:11 -0400 Received: from liberator.sandeen.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p53569Dj014180 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 3 Jun 2011 01:06:10 -0400 Message-ID: <4DE86BC1.4080008@redhat.com> Date: Fri, 03 Jun 2011 00:06:09 -0500 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Amir G." CC: "Ted Ts'o" , Andreas Dilger , Dave Chinner , xfs@oss.sgi.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <4DE7A557.9040608@redhat.com> <7D3F86FA-5AA9-49B0-9AFE-F597E83C07B4@dilger.ca> <20110603003610.GD16306@thunk.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1307077580 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/2/11 11:59 PM, Amir G. wrote: > On Fri, Jun 3, 2011 at 3:36 AM, Ted Ts'o wrote: >> On Thu, Jun 02, 2011 at 11:22:53AM -0600, Andreas Dilger wrote: >>> On 2011-06-02, at 8:59 AM, Eric Sandeen wrote: >>>> I don't really mind adding ext4dev to FSTYP case statements, it >>>> -is- something which blkid could, in theory, still return, and >>>> making xfstests cope with that and try to invoke fsck -t ext4dev >>>> doesn't bother me too much. It is sadly an fs type embedded into >>>> a few tools. >>> >>> I'm perfectly OK with using ext4dev as a filesystem type that allows testing >>> changes to ext4 on a system that is already running ext4 as the root fs. >> >> My take on this is that way too much time has been spent this subject. > > No doubt. > >> Being able to use ext4dev is useful, and given that we have all of >> this support in our existing system tools, why not use it to make ext4 >> development more efficient/easy? As a bonus you can build the ext4dev >> as a module, and that means you the compile/edit/debug cycle can be >> much faster since you can avoid doing a reboot, for those >> circumstances where using KVM is not possible/convenient. Personally, >> I normally use KVM these days, but I can imagine situations where >> using ext4dev would be a better way to go. For example, I'd probably >> use KVM on my laptop, but for testing on production servers in a data >> center, I'd probably use ext4dev, for a variety of local deployment >> considerations that's not worth going into here. >> >> That being said, whether or not we modify xfstests seems to be a moot >> point. In order for me to do my bigalloc development, I've been >> patching common.rc so that "/sbin/mkfs.$FSTYP" --> "mkfs.$FSTYP" and >> "/sbin/fsck -t $FSTYP" --> "fsck.$FSTYP". It's a 3 line change. Not >> a big deal. I've been making this change using /bin/ed after >> installing xfstests. So if the XFS folks want to veto this change --- >> who cares? It's not hard to make the change locally in order to make >> xfstests. >> >> On the other hand, given that xfstests is using "mkfs.$FSTYP", I don't >> see why it's so important that it clings to "fsck -t $FSTYP" instead >> of using "fsck.$FSTYP". There's no real benefit to calling the fsck >> driver; it's just an extra fork and exec, and xfstests is being >> inconsistent by insisting on the use of the fsck driver, but not using >> the mkfs driver. >> >> But that being said, hacking xfstests is not hard, and if Dave and/or >> Eric feels strongly about resisting this change, it's not worth a lot >> of time, one way or another.... >> >> - Ted >> > > I blame only myself for not presenting the case correctly. > I made it sound like I am trying to push my own private hack upstream. > Actually, all 10 people involved in snapshot development clone my xfstests > tree from github, so we have no real need for the upstream change. > The reason I was pushing upstream is because I found this feature > so useful, I thought other developers may enjoy it as well. > > Anyone on on this thread not having used ext4dev by next LSF > can come to me to claim his beer ;-) mmm I like beer, I'll see you then! ;) -Eric (tucking this email away for future reference... ;) > Amir. From jack@suse.cz Fri Jun 3 06:28:17 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53BSHAQ010324 for ; Fri, 3 Jun 2011 06:28:17 -0500 X-ASG-Debug-ID: 1307100495-7a0a02900000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A52FB1E3C018 for ; Fri, 3 Jun 2011 04:28:15 -0700 (PDT) Received: from mx1.suse.de (cantor.suse.de [195.135.220.2]) by cuda.sgi.com with ESMTP id A2fHjszgY8dozmnc for ; Fri, 03 Jun 2011 04:28:15 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id AF73093987; Fri, 3 Jun 2011 13:28:14 +0200 (CEST) Received: by quack.suse.cz (Postfix, from userid 1000) id 6D91B20550; Fri, 3 Jun 2011 13:27:56 +0200 (CEST) Date: Fri, 3 Jun 2011 13:27:56 +0200 From: Jan Kara To: xfs@oss.sgi.com Cc: Dave Chinner , Jan Kara X-ASG-Orig-Subj: Re: [PATCH] xfstests: Improve test 219 to work with different filesystems Subject: Re: [PATCH] xfstests: Improve test 219 to work with different filesystems Message-ID: <20110603112756.GA4789@quack.suse.cz> References: <1305805675-13753-1-git-send-email-jack@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1305805675-13753-1-git-send-email-jack@suse.cz> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: cantor.suse.de[195.135.220.2] X-Barracuda-Start-Time: 1307100496 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu 19-05-11 13:47:55, Jan Kara wrote: > Different filesystems account different amount of metadata in quota. Thus it is > impractical to check for a particular amount of space occupied by a file > because there is no right value. Change the test to verify whether the amount > of space is between the expected amount of space and the expected amount +5%. > The number of files is checked exactly as previously. > > Signed-off-by: Jan Kara > --- > 219 | 25 +++++++++++++++++++++++-- > 1 files changed, 23 insertions(+), 2 deletions(-) > > Dave, does this look better? Any reaction on this? Honza > > diff --git a/219 b/219 > index 836d703..ad4e64d 100755 > --- a/219 > +++ b/219 > @@ -58,6 +58,23 @@ test_files() > done > } > > +check_usage() > +{ > + wroteblocks=$1 > + wrotefiles=$2 > + read id exceed blocks bsoft bhard inodes isoft ihard > + if [ "$blocks" -lt "$wroteblocks" ]; then > + echo "Too few blocks used (type=$type)" > + # Save 5% for overhead of metadata or different block size > + elif [ "$blocks" -gt $((wroteblocks+wroteblocks/20)) ]; then > + echo "Too many blocks used (type=$type)" > + elif [ "$inodes" != "$wrotefiles" ]; then > + echo "Bad number of inodes used (type=$type)" > + else > + echo "Usage OK (type=$type)" > + fi > +} > + > test_accounting() > { > echo "### some controlled buffered, direct and mmapd IO (type=$type)" > @@ -77,8 +94,12 @@ test_accounting() > $here/src/lstat64 $file | head -3 | _filter_scratch > done > > - repquota -$type -n $SCRATCH_MNT | grep -v "^#0" | _filter_scratch | > - awk '/^#/ { if (seen[$1]) next; seen[$1]++; } { print; }' > + if [ $type == 'u' ]; then > + id=$uid > + else > + id=$gid > + fi > + repquota -$type -n $SCRATCH_MNT | grep "^#$id" | check_usage 144 3 > } > > # real QA test starts here > -- > 1.7.1 > -- Jan Kara SUSE Labs, CR From dsterba@suse.cz Fri Jun 3 08:52:59 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53DqxET015077 for ; Fri, 3 Jun 2011 08:52:59 -0500 X-ASG-Debug-ID: 1307109176-602103be0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2EDA41688658 for ; Fri, 3 Jun 2011 06:52:56 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id rrI93nEh0fDLXMxE for ; Fri, 03 Jun 2011 06:52:56 -0700 (PDT) Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id 355385FC9F; Fri, 3 Jun 2011 15:52:55 +0200 (CEST) Received: by ds.suse.cz (Postfix, from userid 10065) id F0309747E1; Fri, 3 Jun 2011 15:52:54 +0200 (CEST) From: David Sterba To: xfs@oss.sgi.com Cc: linux-fsdevel@vger.kernel.org, josef@redhat.com, David Sterba X-ASG-Orig-Subj: [PATCH] xfstests: fix hardcoded path in output of 254 Subject: [PATCH] xfstests: fix hardcoded path in output of 254 Date: Fri, 3 Jun 2011 15:52:42 +0200 Message-Id: <1307109162-21811-1-git-send-email-dsterba@suse.cz> X-Mailer: git-send-email 1.7.5.2.353.g5df3e X-Barracuda-Connect: cantor2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1307109178 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65473 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Add filters after btrfs commands, else the test would incorrectly appear failed. Signed-off-by: David Sterba --- 254 | 13 +++++++------ 254.out | 6 +++--- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/254 b/254 index 3c1a5a1..6320291 100755 --- a/254 +++ b/254 @@ -40,6 +40,7 @@ trap "_cleanup ; exit \$status" 0 1 2 3 15 # get standard environment, filters and checks . ./common.rc +. ./common.filter # real QA test starts here _supported_fs btrfs @@ -55,7 +56,7 @@ dd if=/dev/zero of=$SCRATCH_MNT/foo bs=1M count=1 &> /dev/null echo "List root dir" ls $SCRATCH_MNT echo "Creating snapshot of root dir" -btrfs subvolume snapshot $SCRATCH_MNT $SCRATCH_MNT/snap +btrfs subvolume snapshot $SCRATCH_MNT $SCRATCH_MNT/snap | _filter_scratch echo "List root dir after snapshot" ls $SCRATCH_MNT echo "List snapshot dir" @@ -67,7 +68,7 @@ echo "List snapshot dir" ls $SCRATCH_MNT/snap # Test creating a normal subvolme -btrfs subvolume create $SCRATCH_MNT/subvol +btrfs subvolume create $SCRATCH_MNT/subvol | _filter_scratch echo "Listing root dir" ls $SCRATCH_MNT echo "Listing subvol" @@ -77,7 +78,7 @@ ls $SCRATCH_MNT/subvol echo "Creating file bar in subvol" dd if=/dev/zero of=$SCRATCH_MNT/subvol/bar bs=1M count=1 &> /dev/null echo "Setting subvol to the default" -btrfs subvolume set-default $SCRATCH_MNT/subvol $SCRATCH_MNT/subvol +btrfs subvolume set-default $SCRATCH_MNT/subvol $SCRATCH_MNT/subvol | _filter_scratch _scratch_remount echo "List root dir which is now subvol" ls $SCRATCH_MNT @@ -87,17 +88,17 @@ _scratch_mount "-o subvolid=0" echo "List root dir" ls $SCRATCH_MNT echo "Setting the root dir as the default again" -btrfs subvolume set-default $SCRATCH_MNT $SCRATCH_MNT +btrfs subvolume set-default $SCRATCH_MNT $SCRATCH_MNT | _filter_scratch _scratch_remount echo "List root dir" ls $SCRATCH_MNT # Test listing the subvolumes echo "Listing subvolumes" -btrfs subvolume list $SCRATCH_MNT +btrfs subvolume list $SCRATCH_MNT | _filter_scratch # Delete the snapshot -btrfs subvolume delete $SCRATCH_MNT/snap +btrfs subvolume delete $SCRATCH_MNT/snap | _filter_scratch echo "List root dir" ls $SCRATCH_MNT _scratch_remount diff --git a/254.out b/254.out index e1c19ee..582357a 100644 --- a/254.out +++ b/254.out @@ -3,7 +3,7 @@ Creating file foo in root dir List root dir foo Creating snapshot of root dir -Create a snapshot of '/mnt/scratch' in '/mnt/scratch/snap' +Create a snapshot of 'SCRATCH_MNT' in 'SCRATCH_MNT/snap' List root dir after snapshot foo snap @@ -13,7 +13,7 @@ List root dir after rm of foo snap List snapshot dir foo -Create subvolume '/mnt/scratch/subvol' +Create subvolume 'SCRATCH_MNT/subvol' Listing root dir snap subvol @@ -33,7 +33,7 @@ subvol Listing subvolumes ID 256 top level 5 path snap ID 257 top level 5 path subvol -Delete subvolume '/mnt/scratch/snap' +Delete subvolume 'SCRATCH_MNT/snap' List root dir subvol List root dir -- 1.7.5.2.353.g5df3e From josef@redhat.com Fri Jun 3 09:08:19 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53E8J4S015578 for ; Fri, 3 Jun 2011 09:08:19 -0500 X-ASG-Debug-ID: 1307110098-2b4e03500000-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 8AD061661844 for ; Fri, 3 Jun 2011 07:08:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id RnHuLdrsPCOlURTF for ; Fri, 03 Jun 2011 07:08:18 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p53E8Hqp030358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2011 10:08:17 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p53E8H8b000572; Fri, 3 Jun 2011 10:08:17 -0400 Received: from localhost.localdomain (vpn-9-113.rdu.redhat.com [10.11.9.113]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p53E8GSZ020951; Fri, 3 Jun 2011 10:08:16 -0400 Message-ID: <4DE8EAD0.8010600@redhat.com> Date: Fri, 03 Jun 2011 10:08:16 -0400 From: Josef Bacik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: David Sterba CC: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH] xfstests: fix hardcoded path in output of 254 Subject: Re: [PATCH] xfstests: fix hardcoded path in output of 254 References: <1307109162-21811-1-git-send-email-dsterba@suse.cz> In-Reply-To: <1307109162-21811-1-git-send-email-dsterba@suse.cz> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1307110098 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 06/03/2011 09:52 AM, David Sterba wrote: > Add filters after btrfs commands, else the test would incorrectly appear > failed. > > Signed-off-by: David Sterba Argh thank you for that, Reviewed-by: Josef Bacik From aelder@sgi.com Fri Jun 3 10:25:44 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53FPigo018182 for ; Fri, 3 Jun 2011 10:25:44 -0500 Received: from cas.corp.sgi.com (pv-excas1-dc21-nlb.corp.sgi.com [137.38.102.126]) by relay2.corp.sgi.com (Postfix) with ESMTP id E09D3304039; Fri, 3 Jun 2011 08:25:40 -0700 (PDT) Received: from [127.0.0.1] (128.162.232.50) by xmail.sgi.com (137.38.102.30) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 3 Jun 2011 10:25:40 -0500 Subject: Re: [PATCH] xfstests: Improve test 219 to work with different filesystems From: Alex Elder Reply-To: To: Jan Kara CC: In-Reply-To: <1305805675-13753-1-git-send-email-jack@suse.cz> References: <1305805675-13753-1-git-send-email-jack@suse.cz> Content-Type: text/plain; charset="UTF-8" Date: Fri, 3 Jun 2011 10:25:40 -0500 Message-ID: <1307114740.2886.26.camel@doink> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.162.232.50] X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, 2011-05-19 at 13:47 +0200, Jan Kara wrote: > Different filesystems account different amount of metadata in quota. Thus it is > impractical to check for a particular amount of space occupied by a file > because there is no right value. Change the test to verify whether the amount > of space is between the expected amount of space and the expected amount +5%. > The number of files is checked exactly as previously. > > Signed-off-by: Jan Kara I don't know enough about the differences between filesystem quota reporting. Perhaps that's something whose definition should be better formalized across filesystem types. In any case I don't outright object to allowing the 5% variability. I do have questions/comments about your change, however. > --- > 219 | 25 +++++++++++++++++++++++-- > 1 files changed, 23 insertions(+), 2 deletions(-) > > Dave, does this look better? > > diff --git a/219 b/219 > index 836d703..ad4e64d 100755 > --- a/219 > +++ b/219 > @@ -58,6 +58,23 @@ test_files() > done > } > > +check_usage() > +{ > + wroteblocks=$1 > + wrotefiles=$2 > + read id exceed blocks bsoft bhard inodes isoft ihard > + if [ "$blocks" -lt "$wroteblocks" ]; then > + echo "Too few blocks used (type=$type)" > + # Save 5% for overhead of metadata or different block size > + elif [ "$blocks" -gt $((wroteblocks+wroteblocks/20)) ]; then > + echo "Too many blocks used (type=$type)" > + elif [ "$inodes" != "$wrotefiles" ]; then > + echo "Bad number of inodes used (type=$type)" > + else > + echo "Usage OK (type=$type)" > + fi > +} > + > test_accounting() > { > echo "### some controlled buffered, direct and mmapd IO (type=$type)" > @@ -77,8 +94,12 @@ test_accounting() > $here/src/lstat64 $file | head -3 | _filter_scratch > done > > - repquota -$type -n $SCRATCH_MNT | grep -v "^#0" | _filter_scratch | > - awk '/^#/ { if (seen[$1]) next; seen[$1]++; } { print; }' Why did you delete this awk line? > + if [ $type == 'u' ]; then > + id=$uid > + else > + id=$gid > + fi This (above) seems to be doing a better job of selecting what we're interested in seeing rather than filtering out anything owned by root. Is that what you're doing here? Does doing this also eliminate duplicate entries (which I think can occur when multiple user names share the same UID, for example)? Regardless, this hunk has nothing to do with the 5% slop that's the stated purpose of this patch. It really ought to have been done as separate (earlier) patch. Maybe this isn't a big deal for xfstests but in XFS we try to be more disciplined about that. > + repquota -$type -n $SCRATCH_MNT | grep "^#$id" | check_usage 144 3 > } > > # real QA test starts here From aelder@sgi.com Fri Jun 3 10:27:40 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53FRdjY018255 for ; Fri, 3 Jun 2011 10:27:40 -0500 Received: from cas.corp.sgi.com (pv-excas1-dc21-nlb.corp.sgi.com [137.38.102.126]) by relay1.corp.sgi.com (Postfix) with ESMTP id 9828D8F8096; Fri, 3 Jun 2011 08:27:36 -0700 (PDT) Received: from [127.0.0.1] (128.162.232.50) by xmail.sgi.com (137.38.102.30) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 3 Jun 2011 10:27:36 -0500 Subject: Re: [PATCH] xfstests: fix hardcoded path in output of 254 From: Alex Elder Reply-To: To: David Sterba CC: , , In-Reply-To: <1307109162-21811-1-git-send-email-dsterba@suse.cz> References: <1307109162-21811-1-git-send-email-dsterba@suse.cz> Content-Type: text/plain; charset="UTF-8" Date: Fri, 3 Jun 2011 10:27:36 -0500 Message-ID: <1307114856.2886.27.camel@doink> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.162.232.50] X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, 2011-06-03 at 15:52 +0200, David Sterba wrote: > Add filters after btrfs commands, else the test would incorrectly appear > failed. > > Signed-off-by: David Sterba Looks good. I will commit this for you. Signed-off-by: Alex Elder From powool@gmail.com Fri Jun 3 10:59:05 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53Fx52l019326 for ; Fri, 3 Jun 2011 10:59:05 -0500 X-ASG-Debug-ID: 1307116743-6a1f004d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-wy0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 71B091346013 for ; Fri, 3 Jun 2011 08:59:03 -0700 (PDT) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by cuda.sgi.com with ESMTP id 7sltxyrojau1eQWM for ; Fri, 03 Jun 2011 08:59:03 -0700 (PDT) Received: by wyi11 with SMTP id 11so1648482wyi.26 for ; Fri, 03 Jun 2011 08:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AgIxMfsRzt6mabN/Ukqlz4UMO0v2NPMSCabd5dvPSSQ=; b=nno/4cF+SffxKkUSQy71ldtyKMN7AgYEM0P9M5p5H0tvZo9/iRmtFhizNC0vFmOp5K z4WDGHruLPgza6qqFv0FaLgTrFmzliD1qEGfZVck0akHXrR7AN3GKTSFGvnPvbSpIlRn fkdwezULGQrMP333Z8dTmRAMbNrHB8yhYgcb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=v1H+GIxDlbM3paJX5Uhw1WqjrxrqeKcz72Ev/CeUN4vBgga1xY+xK1W/7F+1WGzppp jp/dGfjmXG4ZTlKSyFHOzqijsHl93TYUlqEw4sj4zYDtHxYI7H9nb17zu3AJ+BzRvM/3 zgJyKZkBdxeoaJWHWyXhwhKZg9kcnA4M5uaXA= MIME-Version: 1.0 Received: by 10.216.135.76 with SMTP id t54mr7491126wei.31.1307116742640; Fri, 03 Jun 2011 08:59:02 -0700 (PDT) Sender: powool@gmail.com Received: by 10.216.137.202 with HTTP; Fri, 3 Jun 2011 08:59:02 -0700 (PDT) In-Reply-To: <20110603013948.GX561@dastard> References: <20110603004247.GA28043@infradead.org> <20110603013948.GX561@dastard> Date: Fri, 3 Jun 2011 11:59:02 -0400 X-Google-Sender-Auth: RsTeQ5_tiUDnxAuZJYi-Gtwu8_o Message-ID: X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general From: Paul Anderson To: Dave Chinner Cc: Christoph Hellwig , xfs-oss Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-wy0-f181.google.com[74.125.82.181] X-Barracuda-Start-Time: 1307116744 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT, DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65477 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 2, 2011 at 9:39 PM, Dave Chinner wrote: > On Thu, Jun 02, 2011 at 08:42:47PM -0400, Christoph Hellwig wrote: >> On Thu, Jun 02, 2011 at 10:42:46AM -0400, Paul Anderson wrote: >> > This morning, I had a symptom of a I/O throughput problem in which >> > dirty pages appeared to be taking a long time to write to disk. >> > >> > The system is a large x64 192GiB dell 810 server running 2.6.38.5 from >> > kernel.org - the basic workload was data intensive - concurrent large >> > NFS (with high metadata/low filesize), rsync/lftp (with low >> > metadata/high file size) all working in a 200TiB XFS volume on a >> > software MD raid0 on top of 7 software MD raid6, each w/18 drives. =A0= I >> > had mounted the filesystem with inode64,largeio,logbufs=3D8,noatime. >> >> A few comments on the setup before trying to analze what's going on in >> detail. =A0I'd absolutely recommend an external log device for this setu= p, >> that is buy another two fast but small disks, or take two existing ones >> and use a RAID 1 for the external log device. =A0This will speed up >> anything log intensive, which both NFS, and resync workloads are lot. >> >> Second thing if you can split the workloads into multiple volumes if you >> have two such different workloads, so thay they don't interfear with >> each other. >> >> Second a RAID0 on top of RAID6 volumes sounds like a pretty worst case >> for almost any type of I/O. =A0You end up doing even relatively small I/= O >> to all of the disks in the worst case. =A0I think you'd be much better >> off with a simple linear concatenation of the RAID6 devices, even if you >> can split them into multiple filesystems >> >> > The specific symptom was that 'sync' hung, a dpkg command hung >> > (presumably trying to issue fsync), and experimenting with "killall >> > -STOP" or "kill -STOP" of the workload jobs didn't let the system >> > drain I/O enough to finish the sync. =A0I probably did not wait long >> > enough, however. >> >> It really sounds like you're simply killloing the MD setup with a >> log of log I/O that does to all the devices. > > And this is one of the reasons why I originally suggested that > storage at this scale really should be using hardware RAID with > large amounts of BBWC to isolate the backend from such problematic > IO patterns. > Dave Chinner > david@fromorbit.com > Good HW RAID cards are on order - seems to be backordered at least a few weeks now at CDW. Got the batteries immediately. That will give more options for test and deployment. Not sure what I can do about the log - man page says xfs_growfs doesn't implement log moving. I can rebuild the filesystems, but for the one mentioned in this theread, this will take a long time. I'm guessing we'll need to split out the workload - aside from the differences in file size and use patterns, they also have fundamentally different values (the high metadata dataset happens to be high value relative to the low metadata/large file dataset). Paul From sgi-linux-xfs@lo.gmane.org Fri Jun 3 11:15:08 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53GF7xe019828 for ; Fri, 3 Jun 2011 11:15:08 -0500 X-ASG-Debug-ID: 1307117705-142702ea0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lo.gmane.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 76E4349BF90 for ; Fri, 3 Jun 2011 09:15:05 -0700 (PDT) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by cuda.sgi.com with ESMTP id ftOxDmUpp45lliOT for ; Fri, 03 Jun 2011 09:15:05 -0700 (PDT) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QSX1c-0004ln-KW for linux-xfs@oss.sgi.com; Fri, 03 Jun 2011 18:15:04 +0200 Received: from s0106000acd1d509c.du.shawcable.net ([70.67.174.161]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Jun 2011 18:15:04 +0200 Received: from prad by s0106000acd1d509c.du.shawcable.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Jun 2011 18:15:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: prad X-ASG-Orig-Subj: altering defaults Subject: altering defaults Date: Fri, 03 Jun 2011 08:33:06 -0700 Lines: 21 Message-ID: <8762onaq19.fsf@psinom.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: s0106000acd1d509c.du.shawcable.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:CdouzyRl1sYYiDMRbiJtwex3kIE= X-Barracuda-Connect: lo.gmane.org[80.91.229.12] X-Barracuda-Start-Time: 1307117706 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65477 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean i'm new to xfs (courtesy of most helpful and encouraging commentary by stan hoeppner!) and i've seen some advice which says to make the block size -> 512 directory size -> 4096 on the other hand, i've also come across webpages which say don't mess around! keep the defaults as they are unless you are absolutely sure that changing it suits your purpose and know why. my question is for the data storage area on a web/email server. we're mainly going to have small files there and the email part will have only temporary files for the most part since people will download (ie pop). it makes sense to make the block size = 512, but i wonder if it really matters noticeably. the server is not a heavily visited one and only on very rare occasions will we get around 50000 hits/day - most of the time we're looking at under 10000 and that is with all the domains combined. -- in friendship, prad From amir73il@gmail.com Fri Jun 3 12:21:12 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,J_CHICKENPOX_21, J_CHICKENPOX_33,J_CHICKENPOX_62,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53HLCx8022154 for ; Fri, 3 Jun 2011 12:21:12 -0500 X-ASG-Debug-ID: 1307121669-7fc802970000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-wy0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 67E96D71D6B for ; Fri, 3 Jun 2011 10:21:10 -0700 (PDT) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by cuda.sgi.com with ESMTP id JlErhcXNO7fFhFVA for ; Fri, 03 Jun 2011 10:21:10 -0700 (PDT) Received: by wyi11 with SMTP id 11so1706479wyi.26 for ; Fri, 03 Jun 2011 10:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RIm7+Mmim/YnGawHSkRPsrgLfSnoeWodaWUZcCFSLTg=; b=BJwoBKNko3sHwJch86k4TgCNWyrwjldCad2BcXC5qlqrRFIOVduzhnjZRTshVQoHFC EPgNWSVjdEgTo5yNbRLmeiDZrSOeUCXaItjScjsenZpxDvq2rHYBjh/foebM9nl71fyk igdeDne2ja62leJewKbtMyz2ieLm6iGZhBn9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rfBPTnZBNAbuVO1X/St6/vaw/qlIqOcs4HVUKlHn+Vz6/efbdjEIIMB7A+rfluTT8b sTerifnkOoVQPHCJ2xW3V5hHbZn2FSdKUcS4KjlFnIkR9akwTggVI8retj/6aosrqG25 ZayR0PMdZ/50lLeMTJYVEBsvJQZzW9G0zgz4Q= MIME-Version: 1.0 Received: by 10.216.254.82 with SMTP id g60mr3429671wes.36.1307121669096; Fri, 03 Jun 2011 10:21:09 -0700 (PDT) Sender: amir73il@gmail.com Received: by 10.216.21.209 with HTTP; Fri, 3 Jun 2011 10:21:09 -0700 (PDT) In-Reply-To: <4DE86BC1.4080008@redhat.com> References: <1306933012-8666-1-git-send-email-amir73il@users.sourceforge.net> <20110601232804.GL32466@dastard> <4DE7A557.9040608@redhat.com> <7D3F86FA-5AA9-49B0-9AFE-F597E83C07B4@dilger.ca> <20110603003610.GD16306@thunk.org> <4DE86BC1.4080008@redhat.com> Date: Fri, 3 Jun 2011 20:21:09 +0300 X-Google-Sender-Auth: -JGDWwbPYsaGP39kOnwh6FtMaU4 Message-ID: X-ASG-Orig-Subj: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP Subject: Re: [PATCH v2] xfstests: add support for ext4dev FSTYP From: "Amir G." To: Eric Sandeen Cc: "Ted Ts'o" , Andreas Dilger , Dave Chinner , xfs@oss.sgi.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, sergey57@gmail.com, Amir Goldstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-wy0-f181.google.com[74.125.82.181] X-Barracuda-Start-Time: 1307121671 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65481 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, Jun 3, 2011 at 8:06 AM, Eric Sandeen wrote: > On 6/2/11 11:59 PM, Amir G. wrote: >> On Fri, Jun 3, 2011 at 3:36 AM, Ted Ts'o wrote: >>> On Thu, Jun 02, 2011 at 11:22:53AM -0600, Andreas Dilger wrote: >>>> On 2011-06-02, at 8:59 AM, Eric Sandeen wrote: >>>>> I don't really mind adding ext4dev to FSTYP case statements, it >>>>> -is- something which blkid could, in theory, still return, and >>>>> making xfstests cope with that and try to invoke fsck -t ext4dev >>>>> doesn't bother me too much. =A0It is sadly an fs type embedded into >>>>> a few tools. >>>> >>>> I'm perfectly OK with using ext4dev as a filesystem type that allows t= esting >>>> changes to ext4 on a system that is already running ext4 as the root f= s. >>> >>> My take on this is that way too much time has been spent this subject. >> >> No doubt. >> >>> Being able to use ext4dev is useful, and given that we have all of >>> this support in our existing system tools, why not use it to make ext4 >>> development more efficient/easy? =A0As a bonus you can build the ext4de= v >>> as a module, and that means you the compile/edit/debug cycle can be >>> much faster since you can avoid doing a reboot, for those >>> circumstances where using KVM is not possible/convenient. =A0Personally= , >>> I normally use KVM these days, but I can imagine situations where >>> using ext4dev would be a better way to go. =A0For example, I'd probably >>> use KVM on my laptop, but for testing on production servers in a data >>> center, I'd probably use ext4dev, for a variety of local deployment >>> considerations that's not worth going into here. >>> >>> That being said, whether or not we modify xfstests seems to be a moot >>> point. =A0In order for me to do my bigalloc development, I've been >>> patching common.rc so that "/sbin/mkfs.$FSTYP" --> "mkfs.$FSTYP" and >>> "/sbin/fsck -t $FSTYP" --> "fsck.$FSTYP". =A0It's a 3 line change. =A0N= ot >>> a big deal. =A0I've been making this change using /bin/ed after >>> installing xfstests. =A0So if the XFS folks want to veto this change --= - >>> who cares? =A0It's not hard to make the change locally in order to make >>> xfstests. >>> >>> On the other hand, given that xfstests is using "mkfs.$FSTYP", I don't >>> see why it's so important that it clings to "fsck -t $FSTYP" instead >>> of using "fsck.$FSTYP". =A0There's no real benefit to calling the fsck >>> driver; it's just an extra fork and exec, and xfstests is being >>> inconsistent by insisting on the use of the fsck driver, but not using >>> the mkfs driver. >>> >>> But that being said, hacking xfstests is not hard, and if Dave and/or >>> Eric feels strongly about resisting this change, it's not worth a lot >>> of time, one way or another.... >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0- Ted >>> >> >> I blame only myself for not presenting the case correctly. >> I made it sound like I am trying to push my own private hack upstream. >> Actually, all 10 people involved in snapshot development clone my xfstes= ts >> tree from github, so we have no real need for the upstream change. >> The reason I was pushing upstream is because I found this feature >> so useful, I thought other developers may enjoy it as well. >> >> Anyone on on this thread not having used ext4dev by next LSF >> can come to me to claim his beer ;-) > > mmm I like beer, I'll see you then! =A0;) > > -Eric (tucking this email away for future reference... ;) > Well, if anyone doesn't like beer, here are my low-tech ext4dev clone scripts ;-) ext4: scripts to clone and build ext4dev fs with default config options diff --git a/clone_ext4dev.sh b/clone_ext4dev.sh new file mode 100755 index 0000000..b5ae2c4 --- /dev/null +++ b/clone_ext4dev.sh @@ -0,0 +1,18 @@ +#!/bin/sh + +rm -rf fs/ext4dev +mkdir -p fs/ext4dev +cp -a fs/ext4/*.h fs/ext4dev +cp -a fs/ext4/*.c fs/ext4dev +cp -a fs/ext4/Kconfig fs/ext4dev +cp -a fs/ext4/Makefile fs/ext4dev +cp -a include/trace/events/ext4.h fs/ext4dev/ext4dev_events.h +cd fs/ext4dev +rm *.mod.c 2>/dev/null +mv ext4_extents.h ext4dev_extents.h +mv ext4_jbd2.h ext4dev_jbd2.h +mv ext4_jbd2.c ext4dev_jbd2.c +mv ext4.h ext4dev.h +sed -f ../../ext4dev.sed -i * +cd .. +tar cfz ../ext4dev_module.tar.gz ext4dev/ diff --git a/ext4dev.sed b/ext4dev.sed new file mode 100644 index 0000000..2ec2761 --- /dev/null +++ b/ext4dev.sed @@ -0,0 +1,3 @@ +s/ext4/ext4dev/g +s/Ext4/Ext4dev/g +s/EXT4/EXT4DEV/g diff --git a/make_ext4dev.sh b/make_ext4dev.sh new file mode 100755 index 0000000..495929f --- /dev/null +++ b/make_ext4dev.sh @@ -0,0 +1,11 @@ +#!/bin/sh + +KERNEL=3D$(uname -r) +KDIR=3D/lib/modules/${KERNEL}/build + +sudo cp fs/ext4dev/ext4dev_events.h ${KDIR}/include/trace/events/ext4dev.h +make -C ${KDIR} M=3D${PWD}/fs/ext4dev modules +sudo make -C ${KDIR} M=3D${PWD}/fs/ext4dev modules_install +sudo rmmod ext4dev +sudo modprobe ext4dev + diff --git a/fs/ext4/Makefile b/fs/ext4/Makefile index c947e36..9981306 100644 --- a/fs/ext4/Makefile +++ b/fs/ext4/Makefile @@ -2,6 +2,13 @@ # Makefile for the linux ext4-filesystem routines. # +ifndef CONFIG_EXT4_FS +CONFIG_EXT4_FS?=3Dm +CONFIG_EXT4_FS_XATTR?=3Dy +CONFIG_EXT4_FS_POSIX_ACL?=3D$(CONFIG_FS_POSIX_ACL) +CONFIG_EXT4_FS_SECURITY?=3Dy +endif + obj-$(CONFIG_EXT4_FS) +=3D ext4.o ext4-y :=3D balloc.o bitmap.o dir.o file.o fsync.o ialloc.o inode.o page-i= o.o \ diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 3aa0b72..657d437 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -33,6 +33,18 @@ #include #endif +#ifndef EXT4_SUPER_MAGIC +#define EXT4_SUPER_MAGIC EXT3_SUPER_MAGIC +/* configuration options for standalone module */ +#define CONFIG_EXT4_DEFAULTS_TO_ORDERED +#define CONFIG_EXT4_FS_XATTR +#ifdef CONFIG_FS_POSIX_ACL +#define CONFIG_EXT4_FS_POSIX_ACL +#endif +#define CONFIG_EXT4_FS_SECURITY +#define CONFIG_EXT4_DEBUG +#endif + /* * The fourth extended filesystem constants/structures */ --- From jack@suse.cz Fri Jun 3 12:34:55 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53HYsHJ022662 for ; Fri, 3 Jun 2011 12:34:55 -0500 X-ASG-Debug-ID: 1307122493-7afd013a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3FE1249C0DB for ; Fri, 3 Jun 2011 10:34:53 -0700 (PDT) Received: from mx1.suse.de (cantor.suse.de [195.135.220.2]) by cuda.sgi.com with ESMTP id eYNNCC4fAyfvBTTK for ; Fri, 03 Jun 2011 10:34:53 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 8DDBE90975; Fri, 3 Jun 2011 19:34:52 +0200 (CEST) Received: by quack.suse.cz (Postfix, from userid 1000) id E2EBC20550; Fri, 3 Jun 2011 19:34:51 +0200 (CEST) Date: Fri, 3 Jun 2011 19:34:51 +0200 From: Jan Kara To: Alex Elder Cc: Jan Kara , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfstests: Improve test 219 to work with different filesystems Subject: Re: [PATCH] xfstests: Improve test 219 to work with different filesystems Message-ID: <20110603173451.GA9018@quack.suse.cz> References: <1305805675-13753-1-git-send-email-jack@suse.cz> <1307114740.2886.26.camel@doink> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1307114740.2886.26.camel@doink> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: cantor.suse.de[195.135.220.2] X-Barracuda-Start-Time: 1307122494 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri 03-06-11 10:25:40, Alex Elder wrote: > On Thu, 2011-05-19 at 13:47 +0200, Jan Kara wrote: > > Different filesystems account different amount of metadata in quota. Thus it is > > impractical to check for a particular amount of space occupied by a file > > because there is no right value. Change the test to verify whether the amount > > of space is between the expected amount of space and the expected amount +5%. > > The number of files is checked exactly as previously. > > > > Signed-off-by: Jan Kara > > I don't know enough about the differences > between filesystem quota reporting. Perhaps > that's something whose definition should be > better formalized across filesystem types. Yes, the definition is different for different filesystems and it's kind of hard to change it now... > In any case I don't outright object to > allowing the 5% variability. > > I do have questions/comments about your change, > however. > > > --- > > 219 | 25 +++++++++++++++++++++++-- > > 1 files changed, 23 insertions(+), 2 deletions(-) > > > > Dave, does this look better? > > > > diff --git a/219 b/219 > > index 836d703..ad4e64d 100755 > > --- a/219 > > +++ b/219 > > @@ -58,6 +58,23 @@ test_files() > > done > > } > > > > +check_usage() > > +{ > > + wroteblocks=$1 > > + wrotefiles=$2 > > + read id exceed blocks bsoft bhard inodes isoft ihard > > + if [ "$blocks" -lt "$wroteblocks" ]; then > > + echo "Too few blocks used (type=$type)" > > + # Save 5% for overhead of metadata or different block size > > + elif [ "$blocks" -gt $((wroteblocks+wroteblocks/20)) ]; then > > + echo "Too many blocks used (type=$type)" > > + elif [ "$inodes" != "$wrotefiles" ]; then > > + echo "Bad number of inodes used (type=$type)" > > + else > > + echo "Usage OK (type=$type)" > > + fi > > +} > > + > > test_accounting() > > { > > echo "### some controlled buffered, direct and mmapd IO (type=$type)" > > @@ -77,8 +94,12 @@ test_accounting() > > $here/src/lstat64 $file | head -3 | _filter_scratch > > done > > > > - repquota -$type -n $SCRATCH_MNT | grep -v "^#0" | _filter_scratch | > > - awk '/^#/ { if (seen[$1]) next; seen[$1]++; } { print; }' > > Why did you delete this awk line? > > > + if [ $type == 'u' ]; then > > + id=$uid > > + else > > + id=$gid > > + fi > > This (above) seems to be doing a better job of selecting what > we're interested in seeing rather than filtering out anything > owned by root. Is that what you're doing here? Does doing > this also eliminate duplicate entries (which I think can occur > when multiple user names share the same UID, for example)? > > Regardless, this hunk has nothing to do with the 5% slop > that's the stated purpose of this patch. It really ought > to have been done as separate (earlier) patch. Maybe this > isn't a big deal for xfstests but in XFS we try to be more > disciplined about that. I've droppped the awk like because we check things differently now. Previously we just reported all users (except root whose usage was changing depending on other things stored in the filesystem so it had to be excluded) and compared this against expected output. After my change we check only usage of a particular user used for testing and check_usage() uses just the first line of output so there's no need to remove possible duplicate entries. So I didn't feel the particular need to separate out the change because I just viewed it as one logical change of how we check stuff... > > + repquota -$type -n $SCRATCH_MNT | grep "^#$id" | check_usage 144 3 > > } > > > > # real QA test starts here Honza -- Jan Kara SUSE Labs, CR From achender@linux.vnet.ibm.com Fri Jun 3 14:14:12 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_64,J_CHICKENPOX_66,J_CHICKENPOX_92,LOCAL_GNU_PATCH, SUBJ_FORWARDED autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53JEBIV029617 for ; Fri, 3 Jun 2011 14:14:12 -0500 X-ASG-Debug-ID: 1307128451-42dc014b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e33.co.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 988EB49C70D for ; Fri, 3 Jun 2011 12:14:11 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by cuda.sgi.com with ESMTP id xx8tZviOK6qMBw3Q for ; Fri, 03 Jun 2011 12:14:11 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p53J6oFw004355 for ; Fri, 3 Jun 2011 13:06:50 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p53JDjXk164868 for ; Fri, 3 Jun 2011 13:13:50 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p53DDiw4025790 for ; Fri, 3 Jun 2011 07:13:45 -0600 Received: from [9.11.169.110] (IBM-3CEFE379E05-009011169110.tucson.ibm.com [9.11.169.110]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p53DDiLS025739; Fri, 3 Jun 2011 07:13:44 -0600 Message-ID: <4DE93268.90007@linux.vnet.ibm.com> Date: Fri, 03 Jun 2011 12:13:44 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: Fwd: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX Subject: Fwd: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e33.co.us.ibm.com[32.97.110.151] X-Barracuda-Start-Time: 1307128451 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi All, I realized today that this patch needed to go out on some more mailing lists, so I'm going to forward them along. This is the patch set I've been working on to add more punch hole tests to xfstests. I'll keep the xfs mailing list on the forward too, to help keep the discussions in one thread. Thx! Allison Henderson -------- Original Message -------- Subject: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX Date: Wed, 25 May 2011 19:34:28 -0700 From: Allison Henderson To: xfs-oss This patch adds punch hole tests to the fsx stress test. Signed-off-by: Allison Henderson v1 -> v2: Corrections to the Makefile have been backed out. Those corrections have been addressed in the "xfstests: clean up fallocate configuration tests" patch The punch hole tests can be disabled with the -H flag, and will also be disabled if it is detected that the filesystem does not support punch hole v2 -> v4 Punch hole tests and functionality tests have been moved into their own functions. Existing dofallocate routine has been renamed to do_preallocate. --- :100644 100755 fe072d3... a55b6f7... M ltp/fsx.c ltp/fsx.c | 140 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------- 1 files changed, 122 insertions(+), 18 deletions(-) diff --git a/ltp/fsx.c b/ltp/fsx.c old mode 100644 new mode 100755 index fe072d3..a55b6f7 --- a/ltp/fsx.c +++ b/ltp/fsx.c @@ -69,6 +69,7 @@ int logcount = 0; /* total ops */ #define OP_MAPWRITE 6 #define OP_SKIPPED 7 #define OP_FALLOCATE 8 +#define OP_PUNCH_HOLE 9 #undef PAGE_SIZE #define PAGE_SIZE getpagesize() @@ -110,6 +111,7 @@ int randomoplen = 1; /* -O flag disables it */ int seed = 1; /* -S flag */ int mapped_writes = 1; /* -W flag disables */ int fallocate_calls = 1; /* -F flag disables */ +int punch_hole_calls = 1; /* -H flag disables */ int mapped_reads = 1; /* -R flag disables it */ int fsxgoodfd = 0; int o_direct; /* -Z */ @@ -279,6 +281,14 @@ logdump(void) badoff < lp->args[0] + lp->args[1]) prt("\t******FFFF"); break; + case OP_PUNCH_HOLE: + prt("PUNCH HOLE\t0x%x thru 0x%x\t(0x%x bytes)", + lp->args[0], lp->args[0] + lp->args[1] - 1, + lp->args[1]); + if (badoff >= lp->args[0] && badoff < + lp->args[0] + lp->args[1]) + prt("\t******PPPP"); + break; case OP_SKIPPED: prt("SKIPPED (no operation)"); break; @@ -784,10 +794,67 @@ dotruncate(unsigned size) } } +#ifdef FALLOC_FL_PUNCH_HOLE +void +do_punch_hole(unsigned offset, unsigned length) +{ + unsigned end_offset; + int max_offset = 0; + int max_len = 0; + int mode = FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE; + + if (length == 0) { + if (!quiet && testcalls > simulatedopcount) + prt("skipping zero length punch hole\n"); + log4(OP_SKIPPED, OP_PUNCH_HOLE, offset, length); + return; + } + + if (file_size <= (loff_t)offset) { + if (!quiet && testcalls > simulatedopcount) + prt("skipping hole punch off the end of the file\n"); + log4(OP_SKIPPED, OP_PUNCH_HOLE, offset, length); + return; + } + + end_offset = offset + length; + + log4(OP_PUNCH_HOLE, offset, length, 0); + + if (testcalls <= simulatedopcount) + return; + + if ((progressinterval && testcalls % progressinterval == 0) || + (debug && (monitorstart == -1 || monitorend == -1 || + end_offset <= monitorend))) { + prt("%lu punch\tfrom 0x%x to 0x%x, (0x%x bytes)\n", testcalls, + offset, offset+length, length); + } + if (fallocate(fd, mode, (loff_t)offset, (loff_t)length) == -1) { + prt("%punch hole: %x to %x\n", offset, length); + prterr("do_punch_hole: fallocate"); + report_failure(161); + } + + + max_offset = offset < file_size ? offset : file_size; + max_len = max_offset + length <= file_size ? length : + file_size - max_offset; + memset(good_buf + max_offset, '\0', max_len); +} + +#else +void +do_punch_hole(unsigned offset, unsigned length) +{ + return; +} +#endif + #ifdef FALLOCATE /* fallocate is basically a no-op unless extending, then a lot like a truncate */ void -dofallocate(unsigned offset, unsigned length) +do_preallocate(unsigned offset, unsigned length) { unsigned end_offset; int keep_size; @@ -831,13 +898,13 @@ dofallocate(unsigned offset, unsigned length) prt("%lu falloc\tfrom 0x%x to 0x%x\n", testcalls, offset, length); if (fallocate(fd, keep_size ? FALLOC_FL_KEEP_SIZE : 0, (loff_t)offset, (loff_t)length) == -1) { prt("fallocate: %x to %x\n", offset, length); - prterr("dofallocate: fallocate"); + prterr("do_preallocate: fallocate"); report_failure(161); } } #else void -dofallocate(unsigned offset, unsigned length) +do_preallocate(unsigned offset, unsigned length) { return; } @@ -895,8 +962,7 @@ test(void) unsigned long offset; unsigned long size = maxoplen; unsigned long rv = random(); - unsigned long op = rv % (3 + !lite + mapped_writes + fallocate_calls); - + unsigned long op = rv % (3 + !lite + mapped_writes + fallocate_calls + punch_hole_calls); /* turn off the map read if necessary */ if (op == 2 && !mapped_reads) @@ -924,6 +990,7 @@ test(void) * TRUNCATE: op = - 3 * MAPWRITE: op = 3 4 * FALLOCATE: op = - 5 + * PUNCH HOLE: op = - 6 */ if (lite ? 0 : op == 3 && (style & 1) == 0) /* vanilla truncate? */ dotruncate(random() % maxfilelen); @@ -941,7 +1008,12 @@ test(void) offset %= maxfilelen; if (offset + size > maxfilelen) size = maxfilelen - offset; - dofallocate(offset, size); + do_preallocate(offset, size); + } else if (op == 6) { + offset %= maxfilelen; + if (offset + size > maxfilelen) + size = maxfilelen - offset; + do_punch_hole(offset, size); } else if (op == 1 || op == (lite ? 3 : 4)) { /* write / mapwrite */ offset %= maxfilelen; @@ -1013,6 +1085,9 @@ usage(void) #ifdef FALLOCATE " -F: Do not use fallocate (preallocation) calls\n" #endif +#ifdef FALLOC_FL_PUNCH_HOLE +" -H: Do not use punch hole calls\n" +#endif " -L: fsxLite - no file creations & no file size changes\n\ -N numops: total # operations to do (default infinity)\n\ -O: use oplen (see -o flag) for every op (default random)\n\ @@ -1161,6 +1236,41 @@ int aio_rw(int rw, int fd, char *buf, unsigned len, unsigned offset) #endif +void +test_fallocate() +{ +#ifdef FALLOCATE + if (!lite && fallocate_calls) { + if (fallocate(fd, 0, 0, 1) && errno == EOPNOTSUPP) { + warn("main: filesystem does not support fallocate, disabling"); + fallocate_calls = 0; + } else { + ftruncate(fd, 0); + } + } +#else /* ! FALLOCATE */ + fallocate_calls = 0; +#endif +} + +void +test_punch_hole() +{ +#ifdef FALLOC_FL_PUNCH_HOLE + if (!lite && punch_hole_calls) { + if (fallocate(fd, 0, 0, + FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE) && + errno == EOPNOTSUPP) { + + warn("main: filesystem does not support fallocate punch hole, disabling"); + punch_hole_calls = 0; + } + } +#else /* ! PUNCH HOLE */ + punch_hole_calls = 0; +#endif +} + int main(int argc, char **argv) { @@ -1179,7 +1289,7 @@ main(int argc, char **argv) setvbuf(stdout, (char *)0, _IOLBF, 0); /* line buffered stdout */ - while ((ch = getopt(argc, argv, "b:c:dfl:m:no:p:qr:s:t:w:xyAD:FLN:OP:RS:WZ")) + while ((ch = getopt(argc, argv, "b:c:dfl:m:no:p:qr:s:t:w:xyAD:FHLN:OP:RS:WZ")) != EOF) switch (ch) { case 'b': @@ -1276,6 +1386,9 @@ main(int argc, char **argv) case 'F': fallocate_calls = 0; break; + case 'H': + punch_hole_calls = 0; + break; case 'L': lite = 1; break; @@ -1421,17 +1534,8 @@ main(int argc, char **argv) } else check_trunc_hack(); -#ifdef FALLOCATE - if (!lite && fallocate_calls) { - if (fallocate(fd, 0, 0, 1) && errno == EOPNOTSUPP) { - warn("main: filesystem does not support fallocate, disabling"); - fallocate_calls = 0; - } else - ftruncate(fd, 0); - } -#else /* ! FALLOCATE */ - fallocate_calls = 0; -#endif + test_fallocate(); + test_punch_hole(); while (numops == -1 || numops--) test(); -- 1.7.1 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From achender@linux.vnet.ibm.com Fri Jun 3 14:14:41 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_65, SUBJ_FORWARDED autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53JEfd9029635 for ; Fri, 3 Jun 2011 14:14:41 -0500 X-ASG-Debug-ID: 1307128480-24f702790000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e32.co.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A9D5649C718 for ; Fri, 3 Jun 2011 12:14:40 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by cuda.sgi.com with ESMTP id C1t3TjyPTmYvGs2t for ; Fri, 03 Jun 2011 12:14:40 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p53J31Re009471 for ; Fri, 3 Jun 2011 13:03:01 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p53JEP9g070552 for ; Fri, 3 Jun 2011 13:14:27 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p53DEPip028029 for ; Fri, 3 Jun 2011 07:14:25 -0600 Received: from [9.11.169.110] (IBM-3CEFE379E05-009011169110.tucson.ibm.com [9.11.169.110]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p53DEO4O028003; Fri, 3 Jun 2011 07:14:24 -0600 Message-ID: <4DE93290.70709@linux.vnet.ibm.com> Date: Fri, 03 Jun 2011 12:14:24 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: Fwd: [XFSTEST Add Fallocate Punch Hole Tests 2/3 v4] Expand 252 punch hole test to cover additional corner cases Subject: Fwd: [XFSTEST Add Fallocate Punch Hole Tests 2/3 v4] Expand 252 punch hole test to cover additional corner cases Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e32.co.us.ibm.com[32.97.110.150] X-Barracuda-Start-Time: 1307128480 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean -------- Original Message -------- Subject: [XFSTEST Add Fallocate Punch Hole Tests 2/3 v4] Expand 252 punch hole test to cover additional corner cases Date: Wed, 25 May 2011 19:34:39 -0700 From: Allison Henderson To: xfs-oss This patch adds additional punch hole tests to 252 that were used to test ext4 punch hole. The _test_generic_punch routine has been modified to accept two new flags: -k To keep the test file between tests. This will test the handling of existing holes -d To not sync the file between tests. This will test the handling of delayed extents Four new corner cases have also been added to the routine: 14. data -> hole @ EOF 15. data -> hole @ 0 16. data -> cache cold ->hole 17. data -> hole in single block file Signed-off-by: Allison Henderson --- :100755 100755 dfdf3f8... 5efa243... M 252 :100644 100644 cd8e4b4... 930c924... M 252.out :100644 100644 e2da5d8... ddf63b0... M common.punch 252 | 10 +++ 252.out | 192 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ common.punch | 150 ++++++++++++++++++++++++++++++++++++++------- 3 files changed, 330 insertions(+), 22 deletions(-) diff --git a/252 b/252 index dfdf3f8..5efa243 100755 --- a/252 +++ b/252 @@ -52,6 +52,16 @@ _require_xfs_io_fiemap testfile=$TEST_DIR/252.$$ +# Standard punch hole tests _test_generic_punch falloc fpunch fpunch fiemap _filter_fiemap $testfile -F +# Delayed allocation punch hole tests +_test_generic_punch -d falloc fpunch fpunch fiemap _filter_fiemap $testfile -F + +# Multi hole punch tests +_test_generic_punch -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F + +# Delayed allocation multi punch hole tests +_test_generic_punch -d -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F + status=0 ; exit diff --git a/252.out b/252.out index cd8e4b4..930c924 100644 --- a/252.out +++ b/252.out @@ -45,3 +45,195 @@ QA output created by 252 0: [0..7]: data 1: [8..31]: hole 2: [32..39]: data + 14. data -> hole @ EOF +0: [0..23]: data +1: [24..39]: hole + 15. data -> hole @ 0 +0: [0..15]: hole +1: [16..39]: data + 16. data -> cache cold ->hole +0: [0..15]: hole +1: [16..39]: data + 17. data -> hole in single block file +0: [0..7]: data + 1. into a hole + 2. into allocated space +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 3. into unwritten space +0: [0..7]: unwritten +1: [8..23]: hole +2: [24..39]: unwritten + 4. hole -> data +0: [0..23]: hole +1: [24..31]: data +2: [32..39]: hole + 5. hole -> unwritten +0: [0..23]: hole +1: [24..31]: unwritten +2: [32..39]: hole + 6. data -> hole +0: [0..7]: data +1: [8..39]: hole + 7. data -> unwritten +0: [0..7]: data +1: [8..23]: hole +2: [24..31]: unwritten +3: [32..39]: hole + 8. unwritten -> hole +0: [0..7]: unwritten +1: [8..39]: hole + 9. unwritten -> data +0: [0..7]: unwritten +1: [8..23]: hole +2: [24..31]: data +3: [32..39]: hole + 10. hole -> data -> hole + 11. data -> hole -> data +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 12. unwritten -> data -> unwritten +0: [0..7]: unwritten +1: [8..31]: hole +2: [32..39]: unwritten + 13. data -> unwritten -> data +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 14. data -> hole @ EOF +0: [0..23]: data +1: [24..39]: hole + 15. data -> hole @ 0 +0: [0..15]: hole +1: [16..39]: data + 16. data -> cache cold ->hole +0: [0..15]: hole +1: [16..39]: data + 17. data -> hole in single block file +0: [0..7]: data + 1. into a hole +0: [0..7]: data +1: [8..39]: hole + 2. into allocated space +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 3. into unwritten space +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 4. hole -> data +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 5. hole -> unwritten +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 6. data -> hole +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 7. data -> unwritten +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 8. unwritten -> hole +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 9. unwritten -> data +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 10. hole -> data -> hole +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 11. data -> hole -> data +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 12. unwritten -> data -> unwritten +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 13. data -> unwritten -> data +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 14. data -> hole @ EOF +0: [0..23]: data +1: [24..39]: hole + 15. data -> hole @ 0 +0: [0..15]: hole +1: [16..39]: data + 16. data -> cache cold ->hole +0: [0..15]: hole +1: [16..39]: data + 17. data -> hole in single block file +0: [0..7]: data + 1. into a hole +0: [0..7]: data +1: [8..39]: hole + 2. into allocated space +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 3. into unwritten space +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 4. hole -> data +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 5. hole -> unwritten +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 6. data -> hole +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 7. data -> unwritten +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 8. unwritten -> hole +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 9. unwritten -> data +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 10. hole -> data -> hole +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 11. data -> hole -> data +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 12. unwritten -> data -> unwritten +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 13. data -> unwritten -> data +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 14. data -> hole @ EOF +0: [0..23]: data +1: [24..39]: hole + 15. data -> hole @ 0 +0: [0..15]: hole +1: [16..39]: data + 16. data -> cache cold ->hole +0: [0..15]: hole +1: [16..39]: data + 17. data -> hole in single block file +0: [0..7]: data diff --git a/common.punch b/common.punch index e2da5d8..ddf63b0 100644 --- a/common.punch +++ b/common.punch @@ -256,8 +256,39 @@ die_now() # 11. data -> hole -> data # 12. unwritten -> data -> unwritten # 13. data -> unwritten -> data +# 14. data -> hole @ EOF +# 15. data -> hole @ 0 +# 16. data -> cache cold ->hole +# 17. data -> hole in single block file +# +# Test file is removed, created and sync'd between tests. +# +# Use -k flag to keep the file between tests. This will +# test the handling of pre-existing holes. +# +# Use the -d flag to not sync the file between tests. +# This will test the handling of delayed extents +# _test_generic_punch() { + + remove_testfile=1 + sync_cmd="-c fsync" + OPTIND=1 + while getopts 'dk' OPTION + do + case $OPTION in + k) remove_testfile= + ;; + d) sync_cmd= + ;; + ?) echo Invalid flag + exit 1 + ;; + esac + done + shift $(($OPTIND - 1)) + alloc_cmd=$1 punch_cmd=$2 zero_cmd=$3 #if not testing zero just set to punch @@ -267,22 +298,28 @@ _test_generic_punch() xfs_io_opt=$7 #needs to be -F if not testing xfs echo " 1. into a hole" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$zero_cmd 4k 8k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 2. into allocated space" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ - -c "pwrite 0 20k" -c "fsync" \ + -c "pwrite 0 20k" $sync_cmd \ -c "$zero_cmd 4k 8k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 3. into unwritten space" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 20k" \ -c "$zero_cmd 4k 8k" \ @@ -290,15 +327,19 @@ _test_generic_punch() [ $? -ne 0 ] && die_now echo " 4. hole -> data" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ - -c "pwrite 8k 8k" -c "fsync" \ + -c "pwrite 8k 8k" $sync_cmd \ -c "$zero_cmd 4k 8k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 5. hole -> unwritten" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 8k 8k" \ -c "$zero_cmd 4k 8k" \ @@ -306,24 +347,30 @@ _test_generic_punch() [ $? -ne 0 ] && die_now echo " 6. data -> hole" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ - -c "pwrite 0 8k" -c "fsync" \ + -c "pwrite 0 8k" $sync_cmd \ -c "$zero_cmd 4k 8k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 7. data -> unwritten" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ - -c "pwrite 0 8k" -c "fsync" \ + -c "pwrite 0 8k" $sync_cmd \ -c "$alloc_cmd 8k 8k" \ -c "$zero_cmd 4k 8k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 8. unwritten -> hole" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 8k" \ -c "$zero_cmd 4k 8k" \ @@ -331,49 +378,108 @@ _test_generic_punch() [ $? -ne 0 ] && die_now echo " 9. unwritten -> data" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 8k" \ - -c "pwrite 8k 8k" -c "fsync" \ + -c "pwrite 8k 8k" $sync_cmd \ -c "$zero_cmd 4k 8k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 10. hole -> data -> hole" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ - -c "pwrite 8k 4k" -c "fsync" \ + -c "pwrite 8k 4k" $sync_cmd \ -c "$zero_cmd 4k 12k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 11. data -> hole -> data" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 20k" \ -c "pwrite 0 8k" \ - -c "pwrite 12k 8k" -c "fsync" \ + -c "pwrite 12k 8k" $sync_cmd \ -c "$punch_cmd 8k 4k" \ -c "$zero_cmd 4k 12k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 12. unwritten -> data -> unwritten" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 20k" \ - -c "pwrite 8k 4k" -c "fsync" \ + -c "pwrite 8k 4k" $sync_cmd \ -c "$zero_cmd 4k 12k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 13. data -> unwritten -> data" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 20k" \ - -c "pwrite 0k 8k" -c "fsync" \ + -c "pwrite 0k 8k" $sync_cmd \ -c "pwrite 12k 8k" -c "fsync" \ -c "$zero_cmd 4k 12k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now + + echo " 14. data -> hole @ EOF" + rm -f $testfile + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ + -c "pwrite 0 20k" $sync_cmd \ + -c "$zero_cmd 12k 8k" \ + -c "$map_cmd -v" $testfile | $filter_cmd + [ $? -ne 0 ] && die_now + + echo " 15. data -> hole @ 0" + if [ "$remove_testfile" ]; then + rm -f $testfile + fi + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ + -c "pwrite 0 20k" $sync_cmd \ + -c "$zero_cmd 0k 8k" \ + -c "$map_cmd -v" $testfile | $filter_cmd + [ $? -ne 0 ] && die_now + + echo " 16. data -> cache cold ->hole" + if [ "$remove_testfile" ]; then + rm -f $testfile + rm -f $testfile.2 + else + cp $testfile $testfile.2 + fi + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ + -c "pwrite 8k 12k" -c "fsync" $testfile.2 \ + > /dev/null + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ + -c "pwrite 0 20k" $sync_cmd \ + -c "$zero_cmd 0k 8k" \ + -c "fadvise -d" \ + -c "$map_cmd -v" $testfile | $filter_cmd + diff $testfile $testfile.2 + [ $? -ne 0 ] && die_now + rm -f $testfile.2 + + echo " 17. data -> hole in single block file" + if [ "$remove_testfile" ]; then + rm -f $testfile + fi + block_size=`stat -f $TEST_DEV | grep "Block size" | cut -d " " -f3` + $XFS_IO_PROG $xfs_io_opt -f -c "truncate $block_size" \ + -c "pwrite 0 $block_size" $sync_cmd \ + -c "$zero_cmd 128 128" \ + -c "$map_cmd -v" $testfile | $filter_cmd + [ $? -ne 0 ] && die_now + } -- 1.7.1 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From achender@linux.vnet.ibm.com Fri Jun 3 14:14:59 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_65, SUBJ_FORWARDED autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53JExXW029655 for ; Fri, 3 Jun 2011 14:14:59 -0500 X-ASG-Debug-ID: 1307128498-4cab02800000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e31.co.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EB9DE13470D5 for ; Fri, 3 Jun 2011 12:14:58 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by cuda.sgi.com with ESMTP id 51ZgablKLlZBkYdl for ; Fri, 03 Jun 2011 12:14:58 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p53IwGZ1001995 for ; Fri, 3 Jun 2011 12:58:16 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p53JEoEZ056772 for ; Fri, 3 Jun 2011 13:14:51 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p53DEnmv029532 for ; Fri, 3 Jun 2011 07:14:49 -0600 Received: from [9.11.169.110] (IBM-3CEFE379E05-009011169110.tucson.ibm.com [9.11.169.110]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p53DEmDK029479; Fri, 3 Jun 2011 07:14:49 -0600 Message-ID: <4DE932A9.7040007@linux.vnet.ibm.com> Date: Fri, 03 Jun 2011 12:14:49 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: Fwd: [XFSTEST Add Fallocate Punch Hole Tests 3/3 v4] Add ENOSPC Hole Punch Test Subject: Fwd: [XFSTEST Add Fallocate Punch Hole Tests 3/3 v4] Add ENOSPC Hole Punch Test Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e31.co.us.ibm.com[32.97.110.149] X-Barracuda-Start-Time: 1307128498 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean -------- Original Message -------- Subject: [XFSTEST Add Fallocate Punch Hole Tests 3/3 v4] Add ENOSPC Hole Punch Test Date: Wed, 25 May 2011 19:34:44 -0700 From: Allison Henderson To: xfs-oss This patch adds a test to 252 that tests that a hole can be punched even when the disk is full. Reserved blocks should be used to allow a punch hole to proceed even when there is not enough blocks to further fragment the file. To test this, the file system is fragmented by punching holes in regular intervals and filling the file system between punches. This will eventually force the file system to use reserved blocks to proceed with the punch hole operation. Signed-off-by: Allison Henderson --- :100755 100755 5efa243... b5204fe... M 252 :100644 100644 ddf63b0... fc6123c... M common.punch 252 | 12 +++++++ common.punch | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 107 insertions(+), 0 deletions(-) diff --git a/252 b/252 index 5efa243..b5204fe 100755 --- a/252 +++ b/252 @@ -49,6 +49,7 @@ _supported_os Linux _require_xfs_io_falloc_punch _require_xfs_io_fiemap +_require_scratch testfile=$TEST_DIR/252.$$ @@ -64,4 +65,15 @@ _test_generic_punch -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F # Delayed allocation multi punch hole tests _test_generic_punch -d -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F +# Test full filesystem hole punching. +# Make a small file system to fill +umount $SCRATCH_DEV &> /dev/null +_scratch_mkfs_sized $(( 1024 * 1024 * 1024 )) &> /dev/null +_scratch_mount +# Test must be able to write files with non-root permissions +chmod 777 $SCRATCH_MNT + +block_size=`stat -f $SCRATCH_DEV | grep "Block size" | cut -d " " -f3` +_test_full_fs_punch $(( $block_size * 2 )) $block_size 500 $SCRATCH_MNT/252.$$ + status=0 ; exit diff --git a/common.punch b/common.punch index ddf63b0..fc6123c 100644 --- a/common.punch +++ b/common.punch @@ -481,5 +481,100 @@ _test_generic_punch() -c "$zero_cmd 128 128" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now +} + +# _fill_fs() +# +# Fills a file system by repeatedly creating files in the given folder +# starting with the given file size. Files are reduced in size when +# they can no longer fit untill no more files can be created. +# +# This routine is used by _test_full_fs_punch to test that a hole may +# still be punched when the disk is full by borrowing reserved blocks. +# All files are created as a non root user to prevent reserved blocks +# from being consumed. +# +_fill_fs() { + local file_size=$1 + local dir=$2 + local file_count=1 + + if [ $# -ne 2 ] + then + echo "USAGE: $0 filesize dir" + exit 1 + fi + + mkdir -p $dir &> /dev/null + if [[ $? != 0 ]] ; then + return 0 + fi + chmod 777 $dir + + rc=0 + while [ $file_size -gt 0 -a $rc == 0 ] + do + # This part must not be done as root or + # reserved blocks will be consumed + sudo -u nobody $XFS_IO_PROG -F -f -c "pwrite 0 $file_size" $dir/$file_count.bin &> /dev/null + rc=$? + + # If there was no room to make the file, + # and the file size can still be made smaller, + # then divide it in half, and keep going + if [ $file_size -gt 1 -a $rc != 0 ] + then + file_size=$(( $file_size / 2 )) + rc=0 + fi + file_count=$(( $file_count + 1 )) + + done +} +# _test_full_fs_punch() +# +# This function will test that a hole may be punched +# even when the file system is full. Reserved blocks +# should be used to allow a punch hole to proceed even +# when there is not enough blocks to further fragment the +# file. To test this, this function will fragment the file +# system by punching holes in regular intervals and filling +# the file system between punches. +# +_test_full_fs_punch() +{ + hole_len=$1 # The length of the holes to punch + hole_interval=$2 # The interval between the holes + iterations=$3 # The number of holes to punch + file_name=$4 # File to punch holes in + file_len=$(( $(( $hole_len + $hole_interval )) * $iterations )) + path=`dirname $file_name` + hole_offset=0 + + rm -f $file_name &> /dev/null + + $XFS_IO_PROG -F -f -c "pwrite 0 $file_len" \ + -c "fsync" $file_name &> /dev/null + chmod 666 $file_name + + _fill_fs $(( 1024 * 1024 * 1024 )) $path/fill + + for (( i=0; i<$iterations; i++ )) + do + # This part must not be done as root in order to + # test that reserved blocks are used when needed + sudo -u nobody $XFS_IO_PROG -F -f -c "fpunch $hole_offset $hole_len" $file_name + rc=$? + if [[ $? != 0 ]] ; then + echo Punch hole failed + break + fi + + hole_offset=$(( $hole_offset + $hole_len + $hole_interval )) + + _fill_fs $hole_len $path/fill.$i + + done } + -- 1.7.1 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From achender@linux.vnet.ibm.com Fri Jun 3 14:15:42 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,SUBJ_FORWARDED autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53JFghc029701 for ; Fri, 3 Jun 2011 14:15:42 -0500 X-ASG-Debug-ID: 1307128541-4b1f02ab0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e1.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 143E06FDF2B for ; Fri, 3 Jun 2011 12:15:41 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by cuda.sgi.com with ESMTP id v2REVW8mTINIZFzU for ; Fri, 03 Jun 2011 12:15:41 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p53J48Qs011478 for ; Fri, 3 Jun 2011 15:04:08 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p53JFd8s075356 for ; Fri, 3 Jun 2011 15:15:39 -0400 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p53DFSWj000521 for ; Fri, 3 Jun 2011 07:15:28 -0600 Received: from [9.11.169.110] (IBM-3CEFE379E05-009011169110.tucson.ibm.com [9.11.169.110]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p53DFRGN032587; Fri, 3 Jun 2011 07:15:27 -0600 Message-ID: <4DE932D0.9040808@linux.vnet.ibm.com> Date: Fri, 03 Jun 2011 12:15:28 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: Fwd: XFS TESTS: Add Fallocate Punch Hole Test v4 Changes Subject: Fwd: XFS TESTS: Add Fallocate Punch Hole Test v4 Changes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e1.ny.us.ibm.com[32.97.182.141] X-Barracuda-Start-Time: 1307128542 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean -------- Original Message -------- Subject: XFS TESTS: Add Fallocate Punch Hole Test v4 Changes Date: Wed, 25 May 2011 19:40:20 -0700 From: Allison Henderson To: xfs-oss Hi All, Here is v4 of the punch hole tests. I've merged in the non over-lapping tests from v3 into 252, and I've separated the code paths for punch hole and fallocate in the fsx patch. I've also included the ENOSPC test that we used in the ext4 punch hole tests. Feedback appreciated! Thx All! Allison Henderson _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From achender@linux.vnet.ibm.com Fri Jun 3 14:16:49 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_64,J_CHICKENPOX_66,J_CHICKENPOX_92,SUBJ_FORWARDED autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53JGnxV029728 for ; Fri, 3 Jun 2011 14:16:49 -0500 X-ASG-Debug-ID: 1307128608-149e03bf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e3.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DA20649AFC9 for ; Fri, 3 Jun 2011 12:16:48 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by cuda.sgi.com with ESMTP id jNZOLYisS0ZQRw5b for ; Fri, 03 Jun 2011 12:16:48 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p53IsVDW023825 for ; Fri, 3 Jun 2011 14:54:31 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p53JGlLP092674 for ; Fri, 3 Jun 2011 15:16:47 -0400 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p53DGd5Z006027 for ; Fri, 3 Jun 2011 07:16:40 -0600 Received: from [9.11.169.110] (IBM-3CEFE379E05-009011169110.tucson.ibm.com [9.11.169.110]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p53DGcva005944; Fri, 3 Jun 2011 07:16:38 -0600 Message-ID: <4DE93316.3080208@linux.vnet.ibm.com> Date: Fri, 03 Jun 2011 12:16:38 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: Fwd: Re: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX Subject: Fwd: Re: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e3.ny.us.ibm.com[32.97.182.143] X-Barracuda-Start-Time: 1307128608 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean -------- Original Message -------- Subject: Re: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX Date: Wed, 01 Jun 2011 16:01:18 -0700 From: Allison Henderson To: xfs-oss On 5/25/2011 7:34 PM, Allison Henderson wrote: > This patch adds punch hole tests to the fsx stress test. > > Signed-off-by: Allison Henderson > > v1 -> v2: > Corrections to the Makefile have been backed out. > Those corrections have been addressed in the > "xfstests: clean up fallocate configuration tests" > patch > > The punch hole tests can be disabled with the > -H flag, and will also be disabled if it is > detected that the filesystem does not support > punch hole > > v2 -> v4 > Punch hole tests and functionality tests have been moved > into their own functions. Existing dofallocate routine > has been renamed to do_preallocate. > --- > :100644 100755 fe072d3... a55b6f7... M ltp/fsx.c > ltp/fsx.c | 140 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------- > 1 files changed, 122 insertions(+), 18 deletions(-) > > diff --git a/ltp/fsx.c b/ltp/fsx.c > old mode 100644 > new mode 100755 > index fe072d3..a55b6f7 > --- a/ltp/fsx.c > +++ b/ltp/fsx.c > @@ -69,6 +69,7 @@ int logcount = 0; /* total ops */ > #define OP_MAPWRITE 6 > #define OP_SKIPPED 7 > #define OP_FALLOCATE 8 > +#define OP_PUNCH_HOLE 9 > > #undef PAGE_SIZE > #define PAGE_SIZE getpagesize() > @@ -110,6 +111,7 @@ int randomoplen = 1; /* -O flag disables it */ > int seed = 1; /* -S flag */ > int mapped_writes = 1; /* -W flag disables */ > int fallocate_calls = 1; /* -F flag disables */ > +int punch_hole_calls = 1; /* -H flag disables */ > int mapped_reads = 1; /* -R flag disables it */ > int fsxgoodfd = 0; > int o_direct; /* -Z */ > @@ -279,6 +281,14 @@ logdump(void) > badoff< lp->args[0] + lp->args[1]) > prt("\t******FFFF"); > break; > + case OP_PUNCH_HOLE: > + prt("PUNCH HOLE\t0x%x thru 0x%x\t(0x%x bytes)", > + lp->args[0], lp->args[0] + lp->args[1] - 1, > + lp->args[1]); > + if (badoff>= lp->args[0]&& badoff< > + lp->args[0] + lp->args[1]) > + prt("\t******PPPP"); > + break; > case OP_SKIPPED: > prt("SKIPPED (no operation)"); > break; > @@ -784,10 +794,67 @@ dotruncate(unsigned size) > } > } > > +#ifdef FALLOC_FL_PUNCH_HOLE > +void > +do_punch_hole(unsigned offset, unsigned length) > +{ > + unsigned end_offset; > + int max_offset = 0; > + int max_len = 0; > + int mode = FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE; > + > + if (length == 0) { > + if (!quiet&& testcalls> simulatedopcount) > + prt("skipping zero length punch hole\n"); > + log4(OP_SKIPPED, OP_PUNCH_HOLE, offset, length); > + return; > + } > + > + if (file_size<= (loff_t)offset) { > + if (!quiet&& testcalls> simulatedopcount) > + prt("skipping hole punch off the end of the file\n"); > + log4(OP_SKIPPED, OP_PUNCH_HOLE, offset, length); > + return; > + } > + > + end_offset = offset + length; > + > + log4(OP_PUNCH_HOLE, offset, length, 0); > + > + if (testcalls<= simulatedopcount) > + return; > + > + if ((progressinterval&& testcalls % progressinterval == 0) || > + (debug&& (monitorstart == -1 || monitorend == -1 || > + end_offset<= monitorend))) { > + prt("%lu punch\tfrom 0x%x to 0x%x, (0x%x bytes)\n", testcalls, > + offset, offset+length, length); > + } > + if (fallocate(fd, mode, (loff_t)offset, (loff_t)length) == -1) { > + prt("%punch hole: %x to %x\n", offset, length); > + prterr("do_punch_hole: fallocate"); > + report_failure(161); > + } > + > + > + max_offset = offset< file_size ? offset : file_size; > + max_len = max_offset + length<= file_size ? length : > + file_size - max_offset; > + memset(good_buf + max_offset, '\0', max_len); > +} > + > +#else > +void > +do_punch_hole(unsigned offset, unsigned length) > +{ > + return; > +} > +#endif > + > #ifdef FALLOCATE > /* fallocate is basically a no-op unless extending, then a lot like a truncate */ > void > -dofallocate(unsigned offset, unsigned length) > +do_preallocate(unsigned offset, unsigned length) > { > unsigned end_offset; > int keep_size; > @@ -831,13 +898,13 @@ dofallocate(unsigned offset, unsigned length) > prt("%lu falloc\tfrom 0x%x to 0x%x\n", testcalls, offset, length); > if (fallocate(fd, keep_size ? FALLOC_FL_KEEP_SIZE : 0, (loff_t)offset, (loff_t)length) == -1) { > prt("fallocate: %x to %x\n", offset, length); > - prterr("dofallocate: fallocate"); > + prterr("do_preallocate: fallocate"); > report_failure(161); > } > } > #else > void > -dofallocate(unsigned offset, unsigned length) > +do_preallocate(unsigned offset, unsigned length) > { > return; > } > @@ -895,8 +962,7 @@ test(void) > unsigned long offset; > unsigned long size = maxoplen; > unsigned long rv = random(); > - unsigned long op = rv % (3 + !lite + mapped_writes + fallocate_calls); > - > + unsigned long op = rv % (3 + !lite + mapped_writes + fallocate_calls + punch_hole_calls); > /* turn off the map read if necessary */ > > if (op == 2&& !mapped_reads) > @@ -924,6 +990,7 @@ test(void) > * TRUNCATE: op = - 3 > * MAPWRITE: op = 3 4 > * FALLOCATE: op = - 5 > + * PUNCH HOLE: op = - 6 > */ > if (lite ? 0 : op == 3&& (style& 1) == 0) /* vanilla truncate? */ > dotruncate(random() % maxfilelen); > @@ -941,7 +1008,12 @@ test(void) > offset %= maxfilelen; > if (offset + size> maxfilelen) > size = maxfilelen - offset; > - dofallocate(offset, size); > + do_preallocate(offset, size); > + } else if (op == 6) { > + offset %= maxfilelen; > + if (offset + size> maxfilelen) > + size = maxfilelen - offset; > + do_punch_hole(offset, size); > } else if (op == 1 || op == (lite ? 3 : 4)) { > /* write / mapwrite */ > offset %= maxfilelen; > @@ -1013,6 +1085,9 @@ usage(void) > #ifdef FALLOCATE > " -F: Do not use fallocate (preallocation) calls\n" > #endif > +#ifdef FALLOC_FL_PUNCH_HOLE > +" -H: Do not use punch hole calls\n" > +#endif > " -L: fsxLite - no file creations& no file size changes\n\ > -N numops: total # operations to do (default infinity)\n\ > -O: use oplen (see -o flag) for every op (default random)\n\ > @@ -1161,6 +1236,41 @@ int aio_rw(int rw, int fd, char *buf, unsigned len, unsigned offset) > > #endif > > +void > +test_fallocate() > +{ > +#ifdef FALLOCATE > + if (!lite&& fallocate_calls) { > + if (fallocate(fd, 0, 0, 1)&& errno == EOPNOTSUPP) { > + warn("main: filesystem does not support fallocate, disabling"); > + fallocate_calls = 0; > + } else { > + ftruncate(fd, 0); > + } > + } > +#else /* ! FALLOCATE */ > + fallocate_calls = 0; > +#endif > +} > + > +void > +test_punch_hole() > +{ > +#ifdef FALLOC_FL_PUNCH_HOLE > + if (!lite&& punch_hole_calls) { > + if (fallocate(fd, 0, 0, > + FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE)&& > + errno == EOPNOTSUPP) { > + > + warn("main: filesystem does not support fallocate punch hole, disabling"); > + punch_hole_calls = 0; > + } > + } > +#else /* ! PUNCH HOLE */ > + punch_hole_calls = 0; > +#endif > +} > + > int > main(int argc, char **argv) > { > @@ -1179,7 +1289,7 @@ main(int argc, char **argv) > > setvbuf(stdout, (char *)0, _IOLBF, 0); /* line buffered stdout */ > > - while ((ch = getopt(argc, argv, "b:c:dfl:m:no:p:qr:s:t:w:xyAD:FLN:OP:RS:WZ")) > + while ((ch = getopt(argc, argv, "b:c:dfl:m:no:p:qr:s:t:w:xyAD:FHLN:OP:RS:WZ")) > != EOF) > switch (ch) { > case 'b': > @@ -1276,6 +1386,9 @@ main(int argc, char **argv) > case 'F': > fallocate_calls = 0; > break; > + case 'H': > + punch_hole_calls = 0; > + break; > case 'L': > lite = 1; > break; > @@ -1421,17 +1534,8 @@ main(int argc, char **argv) > } else > check_trunc_hack(); > > -#ifdef FALLOCATE > - if (!lite&& fallocate_calls) { > - if (fallocate(fd, 0, 0, 1)&& errno == EOPNOTSUPP) { > - warn("main: filesystem does not support fallocate, disabling"); > - fallocate_calls = 0; > - } else > - ftruncate(fd, 0); > - } > -#else /* ! FALLOCATE */ > - fallocate_calls = 0; > -#endif > + test_fallocate(); > + test_punch_hole(); > > while (numops == -1 || numops--) > test(); Hi all, I just wanted to poke this patch set before too much time gets away. Most of the changes that happened between v3 and v4 were discussed in the previous threads. I updated my xfstest recently and noticed that some activity in this code has caused the patch not to apply, so I may need to send out an update, but if anyone has any more comments please let me know so I can add them in. Thx! Allison Henderson _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From achender@linux.vnet.ibm.com Fri Jun 3 14:17:32 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_65, SUBJ_FORWARDED autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53JHWgw029758 for ; Fri, 3 Jun 2011 14:17:32 -0500 X-ASG-Debug-ID: 1307128651-44ea033b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e32.co.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F23CB72FAF3 for ; Fri, 3 Jun 2011 12:17:31 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by cuda.sgi.com with ESMTP id gkBJc7gFxtfPCFoC for ; Fri, 03 Jun 2011 12:17:31 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p53J5qNL012568 for ; Fri, 3 Jun 2011 13:05:52 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p53JHKVO078976 for ; Fri, 3 Jun 2011 13:17:22 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p53DHJOE008886 for ; Fri, 3 Jun 2011 07:17:19 -0600 Received: from [9.11.169.110] (IBM-3CEFE379E05-009011169110.tucson.ibm.com [9.11.169.110]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p53DHJTV008862; Fri, 3 Jun 2011 07:17:19 -0600 Message-ID: <4DE9333F.2020901@linux.vnet.ibm.com> Date: Fri, 03 Jun 2011 12:17:19 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: Fwd: Re: [XFSTEST Add Fallocate Punch Hole Tests 2/3 v4] Expand 252 punch hole test to cover additional corner cases Subject: Fwd: Re: [XFSTEST Add Fallocate Punch Hole Tests 2/3 v4] Expand 252 punch hole test to cover additional corner cases Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e32.co.us.ibm.com[32.97.110.150] X-Barracuda-Start-Time: 1307128651 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean -------- Original Message -------- Subject: Re: [XFSTEST Add Fallocate Punch Hole Tests 2/3 v4] Expand 252 punch hole test to cover additional corner cases Date: Wed, 01 Jun 2011 16:01:42 -0700 From: Allison Henderson To: xfs-oss On 5/25/2011 7:34 PM, Allison Henderson wrote: > This patch adds additional punch hole tests to 252 > that were used to test ext4 punch hole. The _test_generic_punch > routine has been modified to accept two new flags: > > -k To keep the test file between tests. > This will test the handling of existing holes > > -d To not sync the file between tests. > This will test the handling of delayed extents > > Four new corner cases have also been added to the routine: > 14. data -> hole @ EOF > 15. data -> hole @ 0 > 16. data -> cache cold ->hole > 17. data -> hole in single block file > > > Signed-off-by: Allison Henderson > > --- > :100755 100755 dfdf3f8... 5efa243... M 252 > :100644 100644 cd8e4b4... 930c924... M 252.out > :100644 100644 e2da5d8... ddf63b0... M common.punch > 252 | 10 +++ > 252.out | 192 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > common.punch | 150 ++++++++++++++++++++++++++++++++++++++------- > 3 files changed, 330 insertions(+), 22 deletions(-) > > diff --git a/252 b/252 > index dfdf3f8..5efa243 100755 > --- a/252 > +++ b/252 > @@ -52,6 +52,16 @@ _require_xfs_io_fiemap > > testfile=$TEST_DIR/252.$$ > > +# Standard punch hole tests > _test_generic_punch falloc fpunch fpunch fiemap _filter_fiemap $testfile -F > > +# Delayed allocation punch hole tests > +_test_generic_punch -d falloc fpunch fpunch fiemap _filter_fiemap $testfile -F > + > +# Multi hole punch tests > +_test_generic_punch -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F > + > +# Delayed allocation multi punch hole tests > +_test_generic_punch -d -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F > + > status=0 ; exit > diff --git a/252.out b/252.out > index cd8e4b4..930c924 100644 > --- a/252.out > +++ b/252.out > @@ -45,3 +45,195 @@ QA output created by 252 > 0: [0..7]: data > 1: [8..31]: hole > 2: [32..39]: data > + 14. data -> hole @ EOF > +0: [0..23]: data > +1: [24..39]: hole > + 15. data -> hole @ 0 > +0: [0..15]: hole > +1: [16..39]: data > + 16. data -> cache cold ->hole > +0: [0..15]: hole > +1: [16..39]: data > + 17. data -> hole in single block file > +0: [0..7]: data > + 1. into a hole > + 2. into allocated space > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 3. into unwritten space > +0: [0..7]: unwritten > +1: [8..23]: hole > +2: [24..39]: unwritten > + 4. hole -> data > +0: [0..23]: hole > +1: [24..31]: data > +2: [32..39]: hole > + 5. hole -> unwritten > +0: [0..23]: hole > +1: [24..31]: unwritten > +2: [32..39]: hole > + 6. data -> hole > +0: [0..7]: data > +1: [8..39]: hole > + 7. data -> unwritten > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..31]: unwritten > +3: [32..39]: hole > + 8. unwritten -> hole > +0: [0..7]: unwritten > +1: [8..39]: hole > + 9. unwritten -> data > +0: [0..7]: unwritten > +1: [8..23]: hole > +2: [24..31]: data > +3: [32..39]: hole > + 10. hole -> data -> hole > + 11. data -> hole -> data > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 12. unwritten -> data -> unwritten > +0: [0..7]: unwritten > +1: [8..31]: hole > +2: [32..39]: unwritten > + 13. data -> unwritten -> data > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 14. data -> hole @ EOF > +0: [0..23]: data > +1: [24..39]: hole > + 15. data -> hole @ 0 > +0: [0..15]: hole > +1: [16..39]: data > + 16. data -> cache cold ->hole > +0: [0..15]: hole > +1: [16..39]: data > + 17. data -> hole in single block file > +0: [0..7]: data > + 1. into a hole > +0: [0..7]: data > +1: [8..39]: hole > + 2. into allocated space > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 3. into unwritten space > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 4. hole -> data > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 5. hole -> unwritten > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 6. data -> hole > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 7. data -> unwritten > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 8. unwritten -> hole > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 9. unwritten -> data > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 10. hole -> data -> hole > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 11. data -> hole -> data > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 12. unwritten -> data -> unwritten > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 13. data -> unwritten -> data > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 14. data -> hole @ EOF > +0: [0..23]: data > +1: [24..39]: hole > + 15. data -> hole @ 0 > +0: [0..15]: hole > +1: [16..39]: data > + 16. data -> cache cold ->hole > +0: [0..15]: hole > +1: [16..39]: data > + 17. data -> hole in single block file > +0: [0..7]: data > + 1. into a hole > +0: [0..7]: data > +1: [8..39]: hole > + 2. into allocated space > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 3. into unwritten space > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 4. hole -> data > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 5. hole -> unwritten > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 6. data -> hole > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 7. data -> unwritten > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 8. unwritten -> hole > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 9. unwritten -> data > +0: [0..7]: data > +1: [8..23]: hole > +2: [24..39]: data > + 10. hole -> data -> hole > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 11. data -> hole -> data > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 12. unwritten -> data -> unwritten > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 13. data -> unwritten -> data > +0: [0..7]: data > +1: [8..31]: hole > +2: [32..39]: data > + 14. data -> hole @ EOF > +0: [0..23]: data > +1: [24..39]: hole > + 15. data -> hole @ 0 > +0: [0..15]: hole > +1: [16..39]: data > + 16. data -> cache cold ->hole > +0: [0..15]: hole > +1: [16..39]: data > + 17. data -> hole in single block file > +0: [0..7]: data > diff --git a/common.punch b/common.punch > index e2da5d8..ddf63b0 100644 > --- a/common.punch > +++ b/common.punch > @@ -256,8 +256,39 @@ die_now() > # 11. data -> hole -> data > # 12. unwritten -> data -> unwritten > # 13. data -> unwritten -> data > +# 14. data -> hole @ EOF > +# 15. data -> hole @ 0 > +# 16. data -> cache cold ->hole > +# 17. data -> hole in single block file > +# > +# Test file is removed, created and sync'd between tests. > +# > +# Use -k flag to keep the file between tests. This will > +# test the handling of pre-existing holes. > +# > +# Use the -d flag to not sync the file between tests. > +# This will test the handling of delayed extents > +# > _test_generic_punch() > { > + > + remove_testfile=1 > + sync_cmd="-c fsync" > + OPTIND=1 > + while getopts 'dk' OPTION > + do > + case $OPTION in > + k) remove_testfile= > + ;; > + d) sync_cmd= > + ;; > + ?) echo Invalid flag > + exit 1 > + ;; > + esac > + done > + shift $(($OPTIND - 1)) > + > alloc_cmd=$1 > punch_cmd=$2 > zero_cmd=$3 #if not testing zero just set to punch > @@ -267,22 +298,28 @@ _test_generic_punch() > xfs_io_opt=$7 #needs to be -F if not testing xfs > > echo " 1. into a hole" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$zero_cmd 4k 8k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 2. into allocated space" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > - -c "pwrite 0 20k" -c "fsync" \ > + -c "pwrite 0 20k" $sync_cmd \ > -c "$zero_cmd 4k 8k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 3. into unwritten space" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 0 20k" \ > -c "$zero_cmd 4k 8k" \ > @@ -290,15 +327,19 @@ _test_generic_punch() > [ $? -ne 0 ]&& die_now > > echo " 4. hole -> data" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > - -c "pwrite 8k 8k" -c "fsync" \ > + -c "pwrite 8k 8k" $sync_cmd \ > -c "$zero_cmd 4k 8k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 5. hole -> unwritten" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 8k 8k" \ > -c "$zero_cmd 4k 8k" \ > @@ -306,24 +347,30 @@ _test_generic_punch() > [ $? -ne 0 ]&& die_now > > echo " 6. data -> hole" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > - -c "pwrite 0 8k" -c "fsync" \ > + -c "pwrite 0 8k" $sync_cmd \ > -c "$zero_cmd 4k 8k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 7. data -> unwritten" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > - -c "pwrite 0 8k" -c "fsync" \ > + -c "pwrite 0 8k" $sync_cmd \ > -c "$alloc_cmd 8k 8k" \ > -c "$zero_cmd 4k 8k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 8. unwritten -> hole" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 0 8k" \ > -c "$zero_cmd 4k 8k" \ > @@ -331,49 +378,108 @@ _test_generic_punch() > [ $? -ne 0 ]&& die_now > > echo " 9. unwritten -> data" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 0 8k" \ > - -c "pwrite 8k 8k" -c "fsync" \ > + -c "pwrite 8k 8k" $sync_cmd \ > -c "$zero_cmd 4k 8k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 10. hole -> data -> hole" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > - -c "pwrite 8k 4k" -c "fsync" \ > + -c "pwrite 8k 4k" $sync_cmd \ > -c "$zero_cmd 4k 12k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 11. data -> hole -> data" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 0 20k" \ > -c "pwrite 0 8k" \ > - -c "pwrite 12k 8k" -c "fsync" \ > + -c "pwrite 12k 8k" $sync_cmd \ > -c "$punch_cmd 8k 4k" \ > -c "$zero_cmd 4k 12k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > > echo " 12. unwritten -> data -> unwritten" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 0 20k" \ > - -c "pwrite 8k 4k" -c "fsync" \ > + -c "pwrite 8k 4k" $sync_cmd \ > -c "$zero_cmd 4k 12k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now Hi all, I had some questions about test 12. The output for this test is: 12. unwritten -> data -> unwritten 0: [0..7]: unwritten 1: [8..31]: hole 2: [32..39]: unwritten But ext4 gets data extents here instead of unwritten extents (on the first test with the fsync flag on). I did some investigating and it looks like the fsync command causes the extents to be written out before the punch hole operation even starts. So it makes sense to me that it should end up with data extents. Can someone explain why the golden output has unwritten extents here? Thx! Allison Henderson > > echo " 13. data -> unwritten -> data" > - rm -f $testfile > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > -c "$alloc_cmd 0 20k" \ > - -c "pwrite 0k 8k" -c "fsync" \ > + -c "pwrite 0k 8k" $sync_cmd \ > -c "pwrite 12k 8k" -c "fsync" \ > -c "$zero_cmd 4k 12k" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > + > + echo " 14. data -> hole @ EOF" > + rm -f $testfile > + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > + -c "pwrite 0 20k" $sync_cmd \ > + -c "$zero_cmd 12k 8k" \ > + -c "$map_cmd -v" $testfile | $filter_cmd > + [ $? -ne 0 ]&& die_now > + > + echo " 15. data -> hole @ 0" > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > + -c "pwrite 0 20k" $sync_cmd \ > + -c "$zero_cmd 0k 8k" \ > + -c "$map_cmd -v" $testfile | $filter_cmd > + [ $? -ne 0 ]&& die_now > + > + echo " 16. data -> cache cold ->hole" > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + rm -f $testfile.2 > + else > + cp $testfile $testfile.2 > + fi > + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > + -c "pwrite 8k 12k" -c "fsync" $testfile.2 \ > + > /dev/null > + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ > + -c "pwrite 0 20k" $sync_cmd \ > + -c "$zero_cmd 0k 8k" \ > + -c "fadvise -d" \ > + -c "$map_cmd -v" $testfile | $filter_cmd > + diff $testfile $testfile.2 > + [ $? -ne 0 ]&& die_now > + rm -f $testfile.2 > + > + echo " 17. data -> hole in single block file" > + if [ "$remove_testfile" ]; then > + rm -f $testfile > + fi > + block_size=`stat -f $TEST_DEV | grep "Block size" | cut -d " " -f3` > + $XFS_IO_PROG $xfs_io_opt -f -c "truncate $block_size" \ > + -c "pwrite 0 $block_size" $sync_cmd \ > + -c "$zero_cmd 128 128" \ > + -c "$map_cmd -v" $testfile | $filter_cmd > + [ $? -ne 0 ]&& die_now > + > } _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From achender@linux.vnet.ibm.com Fri Jun 3 14:18:25 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_65, SUBJ_FORWARDED autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53JIOiQ029786 for ; Fri, 3 Jun 2011 14:18:24 -0500 X-ASG-Debug-ID: 1307128703-42dd01940000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e38.co.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5B53249A616 for ; Fri, 3 Jun 2011 12:18:24 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by cuda.sgi.com with ESMTP id rWSDn6zysANoon75 for ; Fri, 03 Jun 2011 12:18:24 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p53JA63v027091 for ; Fri, 3 Jun 2011 13:10:06 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p53JIJ3V157952 for ; Fri, 3 Jun 2011 13:18:19 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p53DIIRL012216 for ; Fri, 3 Jun 2011 07:18:18 -0600 Received: from [9.11.169.110] (IBM-3CEFE379E05-009011169110.tucson.ibm.com [9.11.169.110]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p53DIHg4012174; Fri, 3 Jun 2011 07:18:17 -0600 Message-ID: <4DE9337A.5010409@linux.vnet.ibm.com> Date: Fri, 03 Jun 2011 12:18:18 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: Fwd: Re: [XFSTEST Add Fallocate Punch Hole Tests 3/3 v4] Add ENOSPC Hole Punch Test Subject: Fwd: Re: [XFSTEST Add Fallocate Punch Hole Tests 3/3 v4] Add ENOSPC Hole Punch Test Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e38.co.us.ibm.com[32.97.110.159] X-Barracuda-Start-Time: 1307128704 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean -------- Original Message -------- Subject: Re: [XFSTEST Add Fallocate Punch Hole Tests 3/3 v4] Add ENOSPC Hole Punch Test Date: Wed, 01 Jun 2011 16:02:10 -0700 From: Allison Henderson To: xfs-oss , Dave Chinner On 5/25/2011 7:34 PM, Allison Henderson wrote: > This patch adds a test to 252 that tests that a hole can be punched even when the > disk is full. Reserved blocks should be used to allow a punch hole to proceed even > when there is not enough blocks to further fragment the file. To test this, the > file system is fragmented by punching holes in regular intervals and filling > the file system between punches. This will eventually force the file system to use > reserved blocks to proceed with the punch hole operation. > > Signed-off-by: Allison Henderson > --- > :100755 100755 5efa243... b5204fe... M 252 > :100644 100644 ddf63b0... fc6123c... M common.punch > 252 | 12 +++++++ > common.punch | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 107 insertions(+), 0 deletions(-) > > diff --git a/252 b/252 > index 5efa243..b5204fe 100755 > --- a/252 > +++ b/252 > @@ -49,6 +49,7 @@ _supported_os Linux > > _require_xfs_io_falloc_punch > _require_xfs_io_fiemap > +_require_scratch > > testfile=$TEST_DIR/252.$$ > > @@ -64,4 +65,15 @@ _test_generic_punch -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F > # Delayed allocation multi punch hole tests > _test_generic_punch -d -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F > > +# Test full filesystem hole punching. > +# Make a small file system to fill > +umount $SCRATCH_DEV&> /dev/null > +_scratch_mkfs_sized $(( 1024 * 1024 * 1024 ))&> /dev/null > +_scratch_mount > +# Test must be able to write files with non-root permissions > +chmod 777 $SCRATCH_MNT > + > +block_size=`stat -f $SCRATCH_DEV | grep "Block size" | cut -d " " -f3` > +_test_full_fs_punch $(( $block_size * 2 )) $block_size 500 $SCRATCH_MNT/252.$$ > + > status=0 ; exit > diff --git a/common.punch b/common.punch > index ddf63b0..fc6123c 100644 > --- a/common.punch > +++ b/common.punch > @@ -481,5 +481,100 @@ _test_generic_punch() > -c "$zero_cmd 128 128" \ > -c "$map_cmd -v" $testfile | $filter_cmd > [ $? -ne 0 ]&& die_now > +} > + > +# _fill_fs() > +# > +# Fills a file system by repeatedly creating files in the given folder > +# starting with the given file size. Files are reduced in size when > +# they can no longer fit untill no more files can be created. > +# > +# This routine is used by _test_full_fs_punch to test that a hole may > +# still be punched when the disk is full by borrowing reserved blocks. > +# All files are created as a non root user to prevent reserved blocks > +# from being consumed. > +# > +_fill_fs() { > + local file_size=$1 > + local dir=$2 > + local file_count=1 > + > + if [ $# -ne 2 ] > + then > + echo "USAGE: $0 filesize dir" > + exit 1 > + fi > + > + mkdir -p $dir&> /dev/null > + if [[ $? != 0 ]] ; then > + return 0 > + fi > + chmod 777 $dir > + > + rc=0 > + while [ $file_size -gt 0 -a $rc == 0 ] > + do > + # This part must not be done as root or > + # reserved blocks will be consumed > + sudo -u nobody $XFS_IO_PROG -F -f -c "pwrite 0 $file_size" $dir/$file_count.bin&> /dev/null Hi all, This is the ENOSPC test that we used on the ext4 punch hole, but modified to use the xfsprogs facilities. I notice the test takes a lot longer to run after doing this. If I replace the above command with the original code: sudo -u nobody dd if=/dev/zero of=$dir/$file_count.bin bs=$file_size count=1 &> /dev/null it runs a lot faster (takes off almost 15 minutes). Is there anything we can do to improve the xfsprogs command? Thx! Allison Henderson > + rc=$? > + > + # If there was no room to make the file, > + # and the file size can still be made smaller, > + # then divide it in half, and keep going > + if [ $file_size -gt 1 -a $rc != 0 ] > + then > + file_size=$(( $file_size / 2 )) > + rc=0 > + fi > + file_count=$(( $file_count + 1 )) > + > + done > +} > > +# _test_full_fs_punch() > +# > +# This function will test that a hole may be punched > +# even when the file system is full. Reserved blocks > +# should be used to allow a punch hole to proceed even > +# when there is not enough blocks to further fragment the > +# file. To test this, this function will fragment the file > +# system by punching holes in regular intervals and filling > +# the file system between punches. > +# > +_test_full_fs_punch() > +{ > + hole_len=$1 # The length of the holes to punch > + hole_interval=$2 # The interval between the holes > + iterations=$3 # The number of holes to punch > + file_name=$4 # File to punch holes in > + file_len=$(( $(( $hole_len + $hole_interval )) * $iterations )) > + path=`dirname $file_name` > + hole_offset=0 > + > + rm -f $file_name&> /dev/null > + > + $XFS_IO_PROG -F -f -c "pwrite 0 $file_len" \ > + -c "fsync" $file_name&> /dev/null > + chmod 666 $file_name > + > + _fill_fs $(( 1024 * 1024 * 1024 )) $path/fill > + > + for (( i=0; i<$iterations; i++ )) > + do > + # This part must not be done as root in order to > + # test that reserved blocks are used when needed > + sudo -u nobody $XFS_IO_PROG -F -f -c "fpunch $hole_offset $hole_len" $file_name > + rc=$? > + if [[ $? != 0 ]] ; then > + echo Punch hole failed > + break > + fi > + > + hole_offset=$(( $hole_offset + $hole_len + $hole_interval )) > + > + _fill_fs $hole_len $path/fill.$i > + > + done > } > + From pg_mh@sabi.co.UK Fri Jun 3 17:19:52 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53MJq5Z035635 for ; Fri, 3 Jun 2011 17:19:52 -0500 X-ASG-Debug-ID: 1307139589-0d5001a30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from honeysuckle.london.02.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4BD051ED4244 for ; Fri, 3 Jun 2011 15:19:49 -0700 (PDT) Received: from honeysuckle.london.02.net (honeysuckle.london.02.net [87.194.255.144]) by cuda.sgi.com with ESMTP id sLADAHR7A5HMx7uk for ; Fri, 03 Jun 2011 15:19:49 -0700 (PDT) Received: from ty.sabi.co.UK (87.194.99.40) by honeysuckle.london.02.net (8.5.133) id 4DA2FC0B013130E8 for xfs@oss.sgi.com; Fri, 3 Jun 2011 23:19:48 +0100 Received: from from [127.0.0.1] (helo=tree.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.71 #1) id 1QSciD-0004Tt-9j for ; Fri, 03 Jun 2011 23:19:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19945.24042.711472.158523@tree.ty.sabi.co.UK> Date: Fri, 3 Jun 2011 23:19:22 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general In-Reply-To: References: <19943.56524.969126.59978@tree.ty.sabi.co.UK> X-Mailer: VM 8.0.13 under 23.1.1 (x86_64-pc-linux-gnu) From: pg_xf2@xf2.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-Barracuda-Connect: honeysuckle.london.02.net[87.194.255.144] X-Barracuda-Start-Time: 1307139590 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0089 1.0000 -1.9630 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.36 X-Barracuda-Spam-Status: No, SCORE=-1.36 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65489 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean > All JBOD chassis (SuperMicro SC 847's)... been experimenting > with the flusher, will look at the others. I think that from the symptoms you describe the hang happens in the first instance because the number of dirty pages has hit 'dirty_background_ratio', after which all writes become synchronous and this really works badly, especially with XFS. To prevent that, and in general to prevent the accumulation of lots of dirty pages, and sudden latency killing large bursts of IO, it is quite important to tell the flusher to sync pretty often and constantly. For the Linux kernel by default permits the buildup of a mass of dirty pages proportional to memory, which is a very bad idea, as it should be proportional to write speed, with the idea that one should not buffer more than 1 second or perhaps less of dirty pages. In your case that's probably a few hundred MBs, and even that is pretty bad in case of crashes. The sw solution is to set the 'vm/dirty_*' tunables accordingly. vm/dirty_ratio=2 vm/dirty_bytes=400000000 vm/dirty_background_ratio=60 vm/dirty_background_bytes=0 vm/dirty_expire_centisecs=200 vm/dirty_writeback_centisecs=400 The hw solution is to do that *and* use SAS/SATA host adapters with (large) battery-backed buffers/cache (but still keeping very few dirty pages in the Linux page cache). I would not use them in hw RAID mode, also because so many hw RAID cards have abominably buggy firmware, and I trust Linxu MD rather more. Unfortunately it is difficult to recommend any specific host adapter. > The rsync job currently appear to be causing the issue - it > was rsyncing around 250,000 files. If the copy had already > been done, the rsync is fast (i.e. stat is fast, despite the > numbers), but when it starts moving data, the IOPS pegs and > seems to be the limiting factor. That's probably also some effect related to writing to the intent log, and a RAID60 makes that very painful. [ ... ] > We most likely live in different worlds - this is a pure > research group with "different" constraints than those you're > probably used to. Not my choice, but 4-10X the cost per unit > of storage is currently not an option. Then lots lots more smaller RAID5 sets, or even RAID6 if you are sufficiently desparate. Joined together at the namespace level, not with a RAID0. Do you really need a single free space pool? I doubt it: you probably are reading/generating data and storing it, so you instead of having a single 200TB storage pool, you could have 20x10TB ones and fill one after the other. Also ideally much smaller RAID sets: 18 wide with double parity beckons a world of read-modify-write pain, especially if the metadata intent log is on the same logical block device. The MD maintainer thinks that for his much smaller needs putting the metadata intent logs on a speedy small RAID1 is good enough, but I think that scales a fair bit. After all the maximum log size for XFS is not that large (fortunately) and smaller is better. Having multiple smaller filesystems also help with having multiple smaller metadata intent logs. > With XFS freshly installed, it was doing around 1400MiB/sec > write, and around 1900MiB/sec read - 10 parallel high > throughput processes read or writing as fast as possible > (which actually is our use case). >> Also, your 1000MiB/s set probably is not full yet, so that's >> outer tracks only, and when it fills up, data gets into the >> inner tracks, and get a bit churned, then the real >> performances will "shine" through. > Yeah - overall, I expect it to drop - perhaps 50%? I dunno. > The particular filesystem being discussed is 80% full at the > moment. That's then fairly realistic, as it is getting well into the inner tracks. Getting avobe 90% will cause trouble. [ ... ] >> But you seem to have 8-10GiB of dirty pages in your 192GiB >> system. Extraordinarily imaginative. > No, I do not want lots of dirty pages, however, I'm also aware > that if those are just data pages, it represents a few seconds > of system operation. Only if written entirely sequentially. IOPS in random and sequential are quite different. > All other approaches I am aware of cost more. I favor Lustre, > but the infrastructure costs alone for a 2-5PB system will > tend to be exceptional. Why? Lustre can run on your existing hw, and you need the network anyhow (unless you compute several TB on one host and store them on that host's disks, in which case you are lucky). >> [ ... ] is Lustre or one of its forks (or much simpler >> imitators like DPM), and that has its own downsides (it takes >> a lot of work), but a single large storage pool is almost >> never needed, at most a single large namespace, and that can >> be instantiated with an automounter (and Lustre/DPM/.... is >> in effect a more sophisticated automounter). > "It takes a lot of work" is another reason we aren't readily > able to go to other architectures, despite their many > advantages. But creating a 200TB volume and formatting it as XFS seems a quick thing to do now, but soon you will need to cope with the consequences. Setting up Lustre takes more at the beginning, but will handle your workload a lot better, and it handles much better having a lot of smaller independently fsck-able pools and highly parallel network operation. It handles small files not so well, so some kind of NFS server with XFS or better JFS for that would be nice. There is a high throughput genomic data system at thre Sanger Institute in Cambridge UK based on Lustre and it might inspire you. This is a relatively old post, it has been in production for a long time: http://threebit.net/mail-archive/bioclusters/msg00188.html http://www.slideshare.net/gcoates Alternatively a number of smaller XFS filesystems as suggested above, but you lose the extra integration/parallelism Lustre gives. [ ... ] > fsck happens in less than a day, It takes less than a day *if there is essentially no damage*, otherwise it might take weeks. > likewise rebuilding all RAIDs... But the impact on performance will be terrifying, and if you reduce resync speed, it will take much longer, and while it rebuilds further failures will be far more likely, and that will be a very long day. Also consider that you have a 7-wide RAID0 of RAID6 sets; if one of the RAID6 sets becomes much slower because of rebuild, odds are this will impact *all* IO because of the RAID0. If you are unlucky, you could end up with one of the RAID6 members of the RAID0 set being in rebuild quite a good percentage of the time. > backups are interesting - it is impossible in the old scenario > (our prior generation storage) - possible now due to higher > disk and network bandwidth. But many people forget that a backup is often the most stressful operation that can happen. > Keep in mind our ultimate backup is tissue samples. If you can regenerate the data even if expensively then avoid RAID6. Two 8+1 RAID5 sets are better than a 16+2 RAID6 set, and losing a bit more spare, three 5+1 RAID5 sets (10TB each) are better still. The reason are much smaller RMW stripe width, the ability to do non-full-width RMW updates, much nicer rebuilds (1/2 or 1/3 of the drives would be slowed down). > 2TB drives are mandatory - there simply isn't enough available > space in the data center otherwise. Ah that's a pretty hard constraint then. > The bulk of the work is not small-file - almost all is large > files. Then perhaps put the large file on XFS or Lustre and the small file on JFS. From karn@philkarn.net Fri Jun 3 17:29:00 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p53MT0Nt036219 for ; Fri, 3 Jun 2011 17:29:00 -0500 X-ASG-Debug-ID: 1307140138-3526039f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-px0-f174.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 50BE449D119 for ; Fri, 3 Jun 2011 15:28:58 -0700 (PDT) Received: from mail-px0-f174.google.com (mail-px0-f174.google.com [209.85.212.174]) by cuda.sgi.com with ESMTP id POzfNVokgJdH2nW8 for ; Fri, 03 Jun 2011 15:28:58 -0700 (PDT) Received: by pxi15 with SMTP id 15so1562977pxi.5 for ; Fri, 03 Jun 2011 15:28:58 -0700 (PDT) Received: by 10.143.58.15 with SMTP id l15mr446413wfk.418.1307140138232; Fri, 03 Jun 2011 15:28:58 -0700 (PDT) Received: from maggie.local (router.ka9q.net [75.60.237.91]) by mx.google.com with ESMTPS id o16sm1288288wff.1.2011.06.03.15.28.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2011 15:28:56 -0700 (PDT) Message-ID: <4DE96026.2030802@philkarn.net> Date: Fri, 03 Jun 2011 15:28:54 -0700 From: Phil Karn User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dave Chinner CC: Paul Anderson , Linux fs XFS X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general References: <19943.56524.969126.59978@tree.ty.sabi.co.UK> <4DE823DD.7060600@philkarn.net> <20110603003907.GW561@dastard> <20110603025459.GB561@dastard> In-Reply-To: <20110603025459.GB561@dastard> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-px0-f174.google.com[209.85.212.174] X-Barracuda-Start-Time: 1307140139 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65489 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/2/11 7:54 PM, Dave Chinner wrote: > There are definitely cases where it helps for preventing > fragmenting, but as a sweeping generalisation it is very, very > wrong. Well, if I ever see that in practice I'll change my procedures. > Do you do that for temporary object files when you build > from source? No, that would involve patching gcc to use fallocate(). I could be wrong -- I don't know much about gcc internals -- but I think most temp files go on /tmp, which is not xfs. As I clearly said, I patched only a few file copy programs like rsync that I use to create long-lived files. I can't see why the upstream maintainers of those programs shouldn't accept patches to incorporate fallocate() as long as care is taken to avoid calling the POSIX version and no other harm is done on file systems or OSes that don't support it. > Allocation and freeing has CPU overhead, transaction overhead, log > space overhead, can cause free space fragmentation when you have a > mix of short- and long-lived files being preallocated at the same > time, IO for long lived data does not get packed together closely so > requires more seeks to issue which leads to significantly worse IO > performance on RAID5/6 storage sub-systems, etc. I'll believe that when I see it. Like a lot of people I am moving away from RAID 5/6. It is hard to see how keeping files contiguous can lead to free space fragmentation. Seems to me that when a file is severely fragmented, so is the free space around it. Keeping a file contiguous also keeps free space in fewer, larger pieces. > You do realise that your "attr out of line" problem would have gone > away by simply increasing the XFS inode size at mkfs time? And that > there is almost no performance penalty for doing this? Instead, it > seems you found a hammer named fallocate() and proceeded to treat > every tool you have like a nail. :) You do realize that I started experimenting with attributes well *after* I had built XFS on a 6 GB (net) RAID5 that took over a week of solid copying to load to 50%? I had noticed the inode size parameter to mkfs.xfs but I wasn't about to buy four more disks, mkfs a whole new file system with bigger inodes and copy all my data (again) just to waste more space on largely empty inodes and, more importantly, require many more disk seeks and reads to walk through them all. The default xfs inode is 256 bytes. That means a single 4KiB block read fetches 16 inodes at once. Making each inode 512 bytes means reading only 8 inodes in each 4KiB block. That's arithmetic. And I'd still have no guarantee of keeping my attributes in the inodes without some limit on the size of the extent list. > Changing a single mkfs parameter is far less work than maintaining > your own forks of multiple tools.... See above. I've since built a new RAID1 array with bigger and faster drives and am abandoning RAID5, but I still see no reason to waste disk space and seeks on larger data structures that are mostly empty space. A long extent table contains overhead information that is useless -- noise -- to me, the user. Defragmenting a file discards that information and allows more of the disk's storage and I/O capacity to be used for user data. The only drawback I can see to keeping a file system defragmented is that I give up an opportunity for steganography, i.e., hiding information in the locations and sizes of those seemingly random sequences of extent allocations. I know this has been done. > Until aging has degraded your filesystem til free space is > sufficiently fragmented that you can't allocate large extents any > more. Then you are completely screwed. :/ Once again, it is very difficult to see how keeping my long-lived files contiguous causes free space to become more fragmented, not less. Help me out here; it's highly counter intuitive, and more importantly I haven't seen that problem, at least not yet. I have a few extremely large files (many GB) that cannot be allocated a contiguous area. That's probably because of xfs's strategy of scattering files around disk to allow room for growth, which fragments the free space. But that's not a big problem since I don't have very many such files. Each extent is still pretty big, so sequential I/O is still quite fast, and if their attributes are squeezed out of their inodes it's not a big performance hit either. You seem to take personal offense to my use of fallocate(), which is hardly my intention. Did you perhaps write the xfs preallocation code that I'm bypassing? As I said, I still rely on it for log files, mailboxes and temporary files, and it is much appreciated. --Phil From viro@ftp.linux.org.uk Fri Jun 3 19:26:02 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p540Q1dA043815 for ; Fri, 3 Jun 2011 19:26:01 -0500 X-ASG-Debug-ID: 1307147158-2f4f01e70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ZenIV.linux.org.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 52C2F49D0D3 for ; Fri, 3 Jun 2011 17:25:59 -0700 (PDT) Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by cuda.sgi.com with ESMTP id vZJpclwCSxtcvqJu for ; Fri, 03 Jun 2011 17:25:59 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.76 #1 (Red Hat Linux)) id 1QSega-0003MI-PO; Sat, 04 Jun 2011 00:25:52 +0000 Date: Sat, 4 Jun 2011 01:25:52 +0100 From: Al Viro To: Dave Chinner Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 06/12] inode: Make unused inode LRU per superblock Subject: Re: [PATCH 06/12] inode: Make unused inode LRU per superblock Message-ID: <20110604002552.GU11521@ZenIV.linux.org.uk> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> <1306998067-27659-7-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1306998067-27659-7-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Al Viro X-Barracuda-Connect: zeniv.linux.org.uk[195.92.253.2] X-Barracuda-Start-Time: 1307147159 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65491 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Jun 02, 2011 at 05:01:01PM +1000, Dave Chinner wrote: > From: Dave Chinner > > The inode unused list is currently a global LRU. This does not match > the other global filesystem cache - the dentry cache - which uses > per-superblock LRU lists. Hence we have related filesystem object > types using different LRU reclaimation schemes. > > To enable a per-superblock filesystem cache shrinker, both of these > caches need to have per-sb unused object LRU lists. Hence this patch > converts the global inode LRU to per-sb LRUs. > > The patch only does rudimentary per-sb propotioning in the shrinker > infrastructure, as this gets removed when the per-sb shrinker > callouts are introduced later on. What protects s_nr_inodes_unused? From viro@ftp.linux.org.uk Fri Jun 3 19:42:36 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p540gavB044221 for ; Fri, 3 Jun 2011 19:42:36 -0500 X-ASG-Debug-ID: 1307148154-06da03e00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ZenIV.linux.org.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CF88ED72CF1 for ; Fri, 3 Jun 2011 17:42:34 -0700 (PDT) Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by cuda.sgi.com with ESMTP id PMqkD9VttxANJnEv for ; Fri, 03 Jun 2011 17:42:34 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.76 #1 (Red Hat Linux)) id 1QSewi-0003X9-2K; Sat, 04 Jun 2011 00:42:32 +0000 Date: Sat, 4 Jun 2011 01:42:31 +0100 From: Al Viro To: Dave Chinner Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 08/12] superblock: introduce per-sb cache shrinker infrastructure Subject: Re: [PATCH 08/12] superblock: introduce per-sb cache shrinker infrastructure Message-ID: <20110604004231.GV11521@ZenIV.linux.org.uk> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> <1306998067-27659-9-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1306998067-27659-9-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Al Viro X-Barracuda-Connect: zeniv.linux.org.uk[195.92.253.2] X-Barracuda-Start-Time: 1307148155 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65491 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean > @@ -278,7 +325,12 @@ void generic_shutdown_super(struct super_block *sb) > { > const struct super_operations *sop = sb->s_op; > > - > + /* > + * shut down the shrinker first so we know that there are no possible > + * races when shrinking the dcache or icache. Removes the need for > + * external locking to prevent such races. > + */ > + unregister_shrinker(&sb->s_shrink); > if (sb->s_root) { > shrink_dcache_for_umount(sb); > sync_filesystem(sb); What it means is that shrinker_rwsem now nests inside ->s_umount... IOW, if any ->shrink() gets stuck, so does every generic_shutdown_super(). I'm still not convinced it's a good idea - especially since _this_ superblock will be skipped anyway. Is there any good reason to evict shrinker that early? Note that doing that after ->s_umount is dropped should be reasonably safe - your shrinker will see that superblock is doomed if it's called anywhere in that window... From david@fromorbit.com Fri Jun 3 20:40:29 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p541eSrd046000 for ; Fri, 3 Jun 2011 20:40:29 -0500 X-ASG-Debug-ID: 1307151626-7fb403440000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 887E0B4B43E for ; Fri, 3 Jun 2011 18:40:26 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id wrvs5l6AEuJGowxi for ; Fri, 03 Jun 2011 18:40:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAEAAKM6U15LCoegWdsb2JhbABTpkYVAQEWJiXLAQ6GEwSgPw Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl6.internode.on.net with ESMTP; 04 Jun 2011 11:10:24 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QSfqX-0003Fg-E1; Sat, 04 Jun 2011 11:40:13 +1000 Date: Sat, 4 Jun 2011 11:40:13 +1000 From: Dave Chinner To: Al Viro Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 06/12] inode: Make unused inode LRU per superblock Subject: Re: [PATCH 06/12] inode: Make unused inode LRU per superblock Message-ID: <20110604014013.GC561@dastard> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> <1306998067-27659-7-git-send-email-david@fromorbit.com> <20110604002552.GU11521@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110604002552.GU11521@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1307151627 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65493 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sat, Jun 04, 2011 at 01:25:52AM +0100, Al Viro wrote: > On Thu, Jun 02, 2011 at 05:01:01PM +1000, Dave Chinner wrote: > > From: Dave Chinner > > > > The inode unused list is currently a global LRU. This does not match > > the other global filesystem cache - the dentry cache - which uses > > per-superblock LRU lists. Hence we have related filesystem object > > types using different LRU reclaimation schemes. > > > > To enable a per-superblock filesystem cache shrinker, both of these > > caches need to have per-sb unused object LRU lists. Hence this patch > > converts the global inode LRU to per-sb LRUs. > > > > The patch only does rudimentary per-sb propotioning in the shrinker > > infrastructure, as this gets removed when the per-sb shrinker > > callouts are introduced later on. > > What protects s_nr_inodes_unused? For this patch, the modifications are protected by the inode_lru_lock, but the reads are unprotected. That's the same protection as the inode_stat.nr_unused field, and the same as the existing dentry cache per-sb LRU accounting. In the next patch modifcations are moved under the sb->s_inode_lru_lock, but reads still remain unprotected. I can see how the multiple reads in shrink_icache_sb() could each return a different value during the proportioning, but I don't think that is a big problem. That proportioning code goes away in the next patch and is replaced by different code in prune_super(), so if you want the reads protected by locks or a single snapshot used for the proportioning calculations I'll do it in the new code in prune_super(). Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Fri Jun 3 20:52:16 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p541qGTB046372 for ; Fri, 3 Jun 2011 20:52:16 -0500 X-ASG-Debug-ID: 1307152334-510003150000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B6EA049D514 for ; Fri, 3 Jun 2011 18:52:14 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id 7XGurlq7Z4vW6WAX for ; Fri, 03 Jun 2011 18:52:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAEAAKM6U15LCoegWdsb2JhbABTpkYVAQEWJiWIccIQDoYTBKA/ Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl6.internode.on.net with ESMTP; 04 Jun 2011 11:22:13 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QSg28-0003Gm-8m; Sat, 04 Jun 2011 11:52:12 +1000 Date: Sat, 4 Jun 2011 11:52:12 +1000 From: Dave Chinner To: Al Viro Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 08/12] superblock: introduce per-sb cache shrinker infrastructure Subject: Re: [PATCH 08/12] superblock: introduce per-sb cache shrinker infrastructure Message-ID: <20110604015212.GD561@dastard> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> <1306998067-27659-9-git-send-email-david@fromorbit.com> <20110604004231.GV11521@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110604004231.GV11521@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1307152335 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65493 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sat, Jun 04, 2011 at 01:42:31AM +0100, Al Viro wrote: > > @@ -278,7 +325,12 @@ void generic_shutdown_super(struct super_block *sb) > > { > > const struct super_operations *sop = sb->s_op; > > > > - > > + /* > > + * shut down the shrinker first so we know that there are no possible > > + * races when shrinking the dcache or icache. Removes the need for > > + * external locking to prevent such races. > > + */ > > + unregister_shrinker(&sb->s_shrink); > > if (sb->s_root) { > > shrink_dcache_for_umount(sb); > > sync_filesystem(sb); > > What it means is that shrinker_rwsem now nests inside ->s_umount... IOW, > if any ->shrink() gets stuck, so does every generic_shutdown_super(). > I'm still not convinced it's a good idea - especially since _this_ > superblock will be skipped anyway. True, that's not nice. > Is there any good reason to evict > shrinker that early? I wanted to put it early on in the unmount path so that the shrinker was guaranteed to be gone before evict_inodes() was called. That would mean that it is obviously safe to remove the iprune_sem serialisation in that function. The code in the umount path is quite different between 2.6.35 (the original version of the patchset) and 3.0-rc1, so I'm not surprised that I haven't put the unregister call in the right place. > Note that doing that after ->s_umount is dropped > should be reasonably safe - your shrinker will see that superblock is > doomed if it's called anywhere in that window... Agreed. In trying to find the best "early" place to unregister the shrinker, I've completely missed the obvious "late is safe" solution. I'll respin it with these changes. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Fri Jun 3 22:12:47 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p543ClGP052541 for ; Fri, 3 Jun 2011 22:12:47 -0500 X-ASG-Debug-ID: 1307157163-183200640000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 838231BEF219 for ; Fri, 3 Jun 2011 20:12:43 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id M75XoqaXVX32HCq4 for ; Fri, 03 Jun 2011 20:12:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIEAGmh6U15LCoegWdsb2JhbABTG4QvoXwVAQEWJiWIcbEIkFcOgR2DbIEKBKA/ Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl6.internode.on.net with ESMTP; 04 Jun 2011 12:42:42 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QShI0-0003Mz-F9; Sat, 04 Jun 2011 13:12:40 +1000 Date: Sat, 4 Jun 2011 13:12:40 +1000 From: Dave Chinner To: Phil Karn Cc: Paul Anderson , Linux fs XFS X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general Message-ID: <20110604031240.GE561@dastard> References: <19943.56524.969126.59978@tree.ty.sabi.co.UK> <4DE823DD.7060600@philkarn.net> <20110603003907.GW561@dastard> <20110603025459.GB561@dastard> <4DE96026.2030802@philkarn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4DE96026.2030802@philkarn.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1307157165 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65495 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, Jun 03, 2011 at 03:28:54PM -0700, Phil Karn wrote: > On 6/2/11 7:54 PM, Dave Chinner wrote: > > > There are definitely cases where it helps for preventing > > fragmenting, but as a sweeping generalisation it is very, very > > wrong. > > Well, if I ever see that in practice I'll change my procedures. > > > Do you do that for temporary object files when you build > > from source? > > No, that would involve patching gcc to use fallocate(). I could be wrong > -- I don't know much about gcc internals -- but I think most temp files > go on /tmp, which is not xfs. As I clearly said, I patched only a few > file copy programs like rsync that I use to create long-lived files. I > can't see why the upstream maintainers of those programs shouldn't > accept patches to incorporate fallocate() as long as care is taken to > avoid calling the POSIX version and no other harm is done on file > systems or OSes that don't support it. They are trying, but, well, the file corruption problems seen on 2.6.38/.39 kernels that are the result of them using fiemap/fallocate don't inspire me with confidence.... > > away by simply increasing the XFS inode size at mkfs time? And that > > there is almost no performance penalty for doing this? Instead, it > > seems you found a hammer named fallocate() and proceeded to treat > > every tool you have like a nail. :) > > You do realize that I started experimenting with attributes well *after* > I had built XFS on a 6 GB (net) RAID5 that took over a week of solid > copying to load to 50%? I had noticed the inode size parameter to > mkfs.xfs but I wasn't about to buy four more disks, mkfs a whole new > file system with bigger inodes and copy all my data (again) just to > waste more space on largely empty inodes and, more importantly, require > many more disk seeks and reads to walk through them all. > > The default xfs inode is 256 bytes. That means a single 4KiB block read > fetches 16 inodes at once. Making each inode 512 bytes means reading > only 8 inodes in each 4KiB block. That's arithmetic. XFS does not do inode IO like that, so your logic is flawed. Firstly, inodes are read and written in clusters of 8k, and contiguous inode clusters are merged during IO by the elevator. Metadata blocks are heavily sorted before being issued by for writeback, so we get excellent large IO patterns even for metadata IO. Under heavy file create workloads, I'm seeing XFS consistently write metadata to disk in 320k IOs - the maximum IO size my storage subsystem will allow. e.g. a couple of instructive graphs from Chris Mason for a parallel file create workload: http://oss.oracle.com/~mason/seekwatcher/fs_mark/xfs.png http://oss.oracle.com/~mason/seekwatcher/fs_mark/xfs.ogg The fact that ~5000 IOPS is being sustained with only 30-100 seeks/s indicates that the elevator merging is merging roughly 50-100 individual IOs together into each physical IO. This will happen regardless of inode size, so inode/metadata writeback under these workloads tends to be limited by bandwidth, not IOPS.... Reads might be a bit more random, but due to inodes being allocated in larger chunks (64 inodes at a time) and temporal locality effects due to sequential allocation by apps like rsync, then typically reads occur to localised areas as well and hit track caches or RAID controller readahead windows. > And I'd still have no guarantee of keeping my attributes in the inodes > without some limit on the size of the extent list. going from 256 -> 512 byte inodes gives you 256 bytes more space for attributes and extents, which in your case woul dbe entirely for data extents. In hat space you can fit another 16 extent records, which is more than enough for 99.9% of normal files. > > Changing a single mkfs parameter is far less work than maintaining > > your own forks of multiple tools.... > > See above. I've since built a new RAID1 array with bigger and faster > drives and am abandoning RAID5, but I still see no reason to waste disk > space and seeks on larger data structures that are mostly empty space. Well, if you think that inodes are taking too much space, then I guess you'd be really concerned about the amount of space that directories consume and how badly they get fragmented ;) > > Until aging has degraded your filesystem til free space is > > sufficiently fragmented that you can't allocate large extents any > > more. Then you are completely screwed. :/ > > Once again, it is very difficult to see how keeping my long-lived files > contiguous causes free space to become more fragmented, not less. Help > me out here; it's highly counter intuitive, and more importantly I > haven't seen that problem, at least not yet. Initial allocations are done via the "allocate near" algorithm. It starts by finding the largest freespace extent that will hold the allocation via a -size- match i.e. it will look for a match on the size you are asking for. If there isn't a free space extent large enough, it will fall back to searching for a large enough extent near to where you are asking with an increasing search radius. Once a free space extent is found, it then trims it for alignment to stripe unit/stripe width. This generally leaves small, isolated chunks of free space behind, as allocations are typically not stripe unit/width length. Hence you end up with lots of little holes around. Subsequent sequential allocations use an exact block allocation target to try to extend the contiguous allocation each file does. For large files, this tends to keep the files contiguous, or at least with multiple large extents rather than lots of small extents. Then things like unrelated metadata allocations will tend to fill those little holes, be it inodes, btree blocks, directory blocks or attributes. If there aren't little holes (or you aren't using alignment), they will simply sit between data extents. When you then free the allocated data space, you've still got that unrelated metadata lying around, and the free space is now somewhat fragmented. This pattern gets worse as the filesystem ages. Delayed allocation reduces the impact of this problem because it reduces the amount of on-disk metadata modifications that occur during normal operations. It also allows things like directory and inode extent allocation during creates (e.g. untaring) to avoid interleaving with data allocations, so directory and inode extents tend to cluster and be more contiguous and not fill holes between data extents. This means that you are less likely to get sparse metadata blocks fragmenting free space, metadata read and write IO is more likely to be clustered effectively (better IO performance), and so on. IOWs, there are many reasons why delayed allocation reduces the effects of filesystem aging compared to up-front preallocation.... > I have a few extremely large files (many GB) that cannot be allocated a > contiguous area. That's probably because of xfs's strategy of scattering > files around disk to allow room for growth, which fragments the free > space. I doubt it. An extent canbe at most 8GB on a 4kB filesystem, so that's why you see multiple extents for large files. i.e. they require multiple allocations.... > You seem to take personal offense to my use of fallocate(), which is > hardly my intention. Nothing personal at all. > Did you perhaps write the xfs preallocation code > that I'm bypassing? No. People much smarter than me designed and wrote all this stuff. What I'm commenting on is your implication (sweeping generalisation) that preallocation should be used everywhere because it seems to work for you. I don't like to let such statements stand unchallenged, especially when there are very good reaÑ•ons why it is likely to be wrong. I don't do this for my benefit - and I don't really care if you benefit from it or not - but there's a lot of XFS users on this list that might have be wondering "why isn't that done by default?". Those people learn a lot from someone trying to explain why what one person says is beneficial for their use cases might be considered harmful to everyone else... Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Fri Jun 3 22:15:47 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p543Fl2s052657 for ; Fri, 3 Jun 2011 22:15:47 -0500 X-ASG-Debug-ID: 1307157339-54c101920000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CFC19134754B for ; Fri, 3 Jun 2011 20:15:39 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id N3moHGbkNGgymGrT for ; Fri, 03 Jun 2011 20:15:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAEAGmh6U15LCoegWdsb2JhbABTEKY2FQEBFiYlylAOhhMEn3hH Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail06.adl6.internode.on.net with ESMTP; 04 Jun 2011 12:45:38 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QShKr-0003NE-Ot; Sat, 04 Jun 2011 13:15:37 +1000 Date: Sat, 4 Jun 2011 13:15:37 +1000 From: Dave Chinner To: Paul Anderson Cc: Christoph Hellwig , xfs-oss X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general Message-ID: <20110604031537.GF561@dastard> References: <20110603004247.GA28043@infradead.org> <20110603013948.GX561@dastard> 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.20 (2009-06-14) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1307157340 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65495 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, Jun 03, 2011 at 11:59:02AM -0400, Paul Anderson wrote: > On Thu, Jun 2, 2011 at 9:39 PM, Dave Chinner wrote: > > On Thu, Jun 02, 2011 at 08:42:47PM -0400, Christoph Hellwig wrote: > >> On Thu, Jun 02, 2011 at 10:42:46AM -0400, Paul Anderson wrote: > >> > This morning, I had a symptom of a I/O throughput problem in which > >> > dirty pages appeared to be taking a long time to write to disk. > >> > > >> > The system is a large x64 192GiB dell 810 server running 2.6.38.5 from > >> > kernel.org - the basic workload was data intensive - concurrent large > >> > NFS (with high metadata/low filesize), rsync/lftp (with low > >> > metadata/high file size) all working in a 200TiB XFS volume on a > >> > software MD raid0 on top of 7 software MD raid6, each w/18 drives.  I > >> > had mounted the filesystem with inode64,largeio,logbufs=8,noatime. > >> > >> A few comments on the setup before trying to analze what's going on in > >> detail.  I'd absolutely recommend an external log device for this setup, > >> that is buy another two fast but small disks, or take two existing ones > >> and use a RAID 1 for the external log device.  This will speed up > >> anything log intensive, which both NFS, and resync workloads are lot. > >> > >> Second thing if you can split the workloads into multiple volumes if you > >> have two such different workloads, so thay they don't interfear with > >> each other. > >> > >> Second a RAID0 on top of RAID6 volumes sounds like a pretty worst case > >> for almost any type of I/O.  You end up doing even relatively small I/O > >> to all of the disks in the worst case.  I think you'd be much better > >> off with a simple linear concatenation of the RAID6 devices, even if you > >> can split them into multiple filesystems > >> > >> > The specific symptom was that 'sync' hung, a dpkg command hung > >> > (presumably trying to issue fsync), and experimenting with "killall > >> > -STOP" or "kill -STOP" of the workload jobs didn't let the system > >> > drain I/O enough to finish the sync.  I probably did not wait long > >> > enough, however. > >> > >> It really sounds like you're simply killloing the MD setup with a > >> log of log I/O that does to all the devices. > > > > And this is one of the reasons why I originally suggested that > > storage at this scale really should be using hardware RAID with > > large amounts of BBWC to isolate the backend from such problematic > > IO patterns. > > > Dave Chinner > > david@fromorbit.com > > > > Good HW RAID cards are on order - seems to be backordered at least a > few weeks now at CDW. Got the batteries immediately. > > That will give more options for test and deployment. > > Not sure what I can do about the log - man page says xfs_growfs > doesn't implement log moving. I can rebuild the filesystems, but for > the one mentioned in this theread, this will take a long time. Once you have BBWC, the log IO gets aggregated into stripe width writes to the back end (because it is always sequential IO), so it's generally not a significant problem for HW RAID subsystems. Cheers, Dave. -- Dave Chinner david@fromorbit.com From stan@hardwarefreak.com Sat Jun 4 03:14:59 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p548ExaE067343 for ; Sat, 4 Jun 2011 03:14:59 -0500 X-ASG-Debug-ID: 1307175297-6249007a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EB4421E3D0B9 for ; Sat, 4 Jun 2011 01:14:57 -0700 (PDT) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id kUHMf3VDyhQ6fMEf for ; Sat, 04 Jun 2011 01:14:57 -0700 (PDT) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id 888796C127; Sat, 4 Jun 2011 03:14:56 -0500 (CDT) Message-ID: <4DE9E97D.30500@hardwarefreak.com> Date: Sat, 04 Jun 2011 03:14:53 -0500 From: Stan Hoeppner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Anderson CC: Dave Chinner , Christoph Hellwig , xfs-oss X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general References: <20110603004247.GA28043@infradead.org> <20110603013948.GX561@dastard> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-65-41-216-221.sta.embarqhsd.net[65.41.216.221] X-Barracuda-Start-Time: 1307175297 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0751 1.0000 -1.5438 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.84 X-Barracuda-Spam-Status: No, SCORE=-0.84 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65501 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/3/2011 10:59 AM, Paul Anderson wrote: Hi Paul, When I first replied to this thread I didn't recognize your name, thus forgot our off-list conversation. Sorry bout that. > Good HW RAID cards are on order - seems to be backordered at least a > few weeks now at CDW. Got the batteries immediately. As I mentioned, the 9285-8E is very new product, but I didn't realize it was *that* new. Sorry you're having to wait for them. > That will give more options for test and deployment. Others have made valid points WRT the down sides of wide stripe parity arrays. I've mentioned many times I loathe parity RAID due to those reasons, and others, but it's mandatory in your case due to the reasons you previously stated. If such arguments are sufficiently convincing, and you can afford to lose the capacity of 2 more disks per chassis to parity, and increase complexity a bit, you may want to consider 3 x 7 drive RAID5 arrays per backplane, 6 drive stripe width, 18 total arrays concatenated, 216 AGs, 6 AGs per array, 216TB raw storage per server, if my math is correct. That instead of the concatenated 6 x 21 drive RAID6 arrays I previously mentioned. You'd have 3 arrays per backplane/cable and thus retain some isolation advantages for troubleshooting, with the same spares arrangement. Your overall resiliency, mathematical/theoretical anyway, to drive failure should actually increase slightly as you would have 3 drives per backplane worth of parity instead of 2, and array rebuild time would be ~1/3rd that of the 21 drive array, somewhat negating the dual parity advantage of RAID6 as the odds of drive failure during a rebuild tend to increase with the duration of the rebuild. > Not sure what I can do about the log - man page says xfs_growfs > doesn't implement log moving. I can rebuild the filesystems, but for > the one mentioned in this theread, this will take a long time. See the logdev mount option. Using two mirrored drives was recommended, I'd go a step further and use two quality "consumer grade", i.e. MLC based, SSDs, such as: http://www.cdw.com/shop/products/Corsair-Force-Series-F40-solid-state-drive-40-GB-SATA-300/2181114.aspx Rated at 50K 4K write IOPS, about 150 times greater than a 15K SAS drive. > I'm guessing we'll need to split out the workload - aside from the > differences in file size and use patterns, they also have > fundamentally different values (the high metadata dataset happens to > be high value relative to the low metadata/large file dataset). LSI is touting significantly better parity performance for the 9265/9285 vs LSI's previous generation cards for which they claim peaks of ~2700 MB/s sequential read and ~1800 MB/s write. The new cards have double the cache of the previous, so I would think write performance would increase more than read. I'm really interested in seeing your test results with your workloads Paul. -- Stan From david@fromorbit.com Sat Jun 4 05:32:56 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p54AWt55072941 for ; Sat, 4 Jun 2011 05:32:56 -0500 X-ASG-Debug-ID: 1307183572-491d036e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail05.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CEF9E49DFD3 for ; Sat, 4 Jun 2011 03:32:52 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id Z3qlS79xf6plW8lZ for ; Sat, 04 Jun 2011 03:32:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvADAB8I6k15LCoegWdsb2JhbABSpkUVAQEWJiXKCg6GEwSgRQ Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail05.adl6.internode.on.net with ESMTP; 04 Jun 2011 20:02:50 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QSo9v-0003vf-HY; Sat, 04 Jun 2011 20:32:47 +1000 Date: Sat, 4 Jun 2011 20:32:47 +1000 From: Dave Chinner To: Stan Hoeppner Cc: Paul Anderson , Christoph Hellwig , xfs-oss X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general Message-ID: <20110604103247.GG561@dastard> References: <20110603004247.GA28043@infradead.org> <20110603013948.GX561@dastard> <4DE9E97D.30500@hardwarefreak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE9E97D.30500@hardwarefreak.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1307183573 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65504 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sat, Jun 04, 2011 at 03:14:53AM -0500, Stan Hoeppner wrote: > On 6/3/2011 10:59 AM, Paul Anderson wrote: > > Not sure what I can do about the log - man page says xfs_growfs > > doesn't implement log moving. I can rebuild the filesystems, but for > > the one mentioned in this theread, this will take a long time. > > See the logdev mount option. Using two mirrored drives was recommended, > I'd go a step further and use two quality "consumer grade", i.e. MLC > based, SSDs, such as: > > http://www.cdw.com/shop/products/Corsair-Force-Series-F40-solid-state-drive-40-GB-SATA-300/2181114.aspx > > Rated at 50K 4K write IOPS, about 150 times greater than a 15K SAS drive. If you are using delayed logging, then a pair of mirrored 7200rpm SAS or SATA drives would be sufficient for most workloads as the log bandwidth rarely gets above 50MB/s in normal operation. If you have fsync heavy workloads, or are not using delayed logging, then you really need to use the RAID5/6 device behind a BBWC because the log is -seriously- bandwidth intensive. I can drive >500MB/s of log throughput on metadata intensive workloads on 2.6.39 when not using delayed logging or I'm regularly forcing the log via fsync. You sure as hell don't want to be running a sustained long term write load like that on consumer grade SSDs..... Cheers, Dave. -- Dave Chinner david@fromorbit.com From theoliveira@eep.br Sat Jun 4 06:59:11 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.1 required=5.0 tests=BAYES_99,J_CHICKENPOX_73, T_LOTS_OF_MONEY autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p54BxB0M079336 for ; Sat, 4 Jun 2011 06:59:11 -0500 X-ASG-Debug-ID: 1307188749-01b1009d0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pinga.eep.br (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2C27F49A616 for ; Sat, 4 Jun 2011 04:59:09 -0700 (PDT) Received: from pinga.eep.br (pinga.eep.br [201.72.166.52]) by cuda.sgi.com with ESMTP id Q9rnyw5lVjGZWreG for ; Sat, 04 Jun 2011 04:59:09 -0700 (PDT) Received: by pinga.eep.br (Postfix, from userid 65534) id B95FE16EA084; Sat, 4 Jun 2011 08:54:26 -0300 (BRT) Received: from pinga.eep.br (localhost.localdomain [127.0.0.1]) by pinga.eep.br (Postfix) with ESMTP id 1B1CE16E9E02; Sat, 4 Jun 2011 08:54:26 -0300 (BRT) From: "thelma oliveira" Reply-To: datsongalleon@bigstring.com X-ASG-Orig-Subj: ATTN Subject: ATTN Date: Sat, 4 Jun 2011 09:54:26 -0200 Message-Id: <20110604115357.M5163@eep.br> X-Mailer: OpenWebMail 2.52 20060502 X-OriginatingIP: 41.73.225.143 (taaolive) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: undisclosed-recipients:; X-Barracuda-Connect: pinga.eep.br[201.72.166.52] X-Barracuda-Start-Time: 1307188750 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4312 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.2, rules version 3.2.2.65504 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Your email address has made you a winner of 11,000,000 USD, contact,our agent immediately From stan@hardwarefreak.com Sat Jun 4 07:11:56 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_48 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p54CBupP079814 for ; Sat, 4 Jun 2011 07:11:56 -0500 X-ASG-Debug-ID: 1307189513-510e007f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 54ED91347C8F for ; Sat, 4 Jun 2011 05:11:53 -0700 (PDT) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id 4S6hC1u2mNVvNMvF for ; Sat, 04 Jun 2011 05:11:53 -0700 (PDT) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id 518A26C170; Sat, 4 Jun 2011 07:11:53 -0500 (CDT) Message-ID: <4DEA2106.5000900@hardwarefreak.com> Date: Sat, 04 Jun 2011 07:11:50 -0500 From: Stan Hoeppner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dave Chinner CC: Paul Anderson , Christoph Hellwig , xfs-oss X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general References: <20110603004247.GA28043@infradead.org> <20110603013948.GX561@dastard> <4DE9E97D.30500@hardwarefreak.com> <20110604103247.GG561@dastard> In-Reply-To: <20110604103247.GG561@dastard> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-65-41-216-221.sta.embarqhsd.net[65.41.216.221] X-Barracuda-Start-Time: 1307189515 X-Barracuda-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.32 X-Barracuda-Spam-Status: No, SCORE=-1.32 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65505 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/4/2011 5:32 AM, Dave Chinner wrote: > On Sat, Jun 04, 2011 at 03:14:53AM -0500, Stan Hoeppner wrote: >> On 6/3/2011 10:59 AM, Paul Anderson wrote: >>> Not sure what I can do about the log - man page says xfs_growfs >>> doesn't implement log moving. I can rebuild the filesystems, but for >>> the one mentioned in this theread, this will take a long time. >> >> See the logdev mount option. Using two mirrored drives was recommended, >> I'd go a step further and use two quality "consumer grade", i.e. MLC >> based, SSDs, such as: >> >> http://www.cdw.com/shop/products/Corsair-Force-Series-F40-solid-state-drive-40-GB-SATA-300/2181114.aspx >> >> Rated at 50K 4K write IOPS, about 150 times greater than a 15K SAS drive. > > If you are using delayed logging, then a pair of mirrored 7200rpm > SAS or SATA drives would be sufficient for most workloads as the log > bandwidth rarely gets above 50MB/s in normal operation. Hi Dave. I made the first reply to Paul's post, recommending he enable delayed logging as a possible solution to his I/O hang problem. I recommended this due to his mention of super heavy metadata operations at the time on his all md raid60 on plain HBA setup. Paul did not list delaylog when he submitted his 2.6.38.5 mount options: inode64,largeio,logbufs=8,noatime Being the author of the delayed logging code, I had expected you to comment on this, either expounding on my recommendation, or shooting it down, and giving the reasons why. So, would delayed logging have possibly prevented his hang problem or no? I always read your replies at least twice, and I don't recall you touching on delayed logging in this thread. If you did and I missed it, my apologies. Paul will have 3 of LSI's newest RAID cards with a combined 3GB BBWC to test with, hopefully soon. With that much cache is an external log device still needed? With and/or without delayed logging enabled? > If you have fsync heavy workloads, or are not using delayed logging, > then you really need to use the RAID5/6 device behind a BBWC because > the log is -seriously- bandwidth intensive. I can drive >500MB/s of > log throughput on metadata intensive workloads on 2.6.39 when not > using delayed logging or I'm regularly forcing the log via fsync. > You sure as hell don't want to be running a sustained long term > write load like that on consumer grade SSDs..... Given that the max log size is 2GB, IIRC, and that most recommendations I've seen here are against using a log that big, I figure such MLC drives would be fine. AIUI, modern wear leveling will spread writes throughout the entire flash array before going back and over writing the first sector. Published MTBF on most MLC drives rates are roughly equivalent to enterprise SRDs, 1+ million hours. Do you believe MLC based SSDs are simply never appropriate for anything but consumer use, and that only SLC devices should be used for real storage applications? AIUI SLC flash cells do have about a 10:1 greater lifetime than MLC cells. However, there have been a number of articles/posts demonstrating math which shows a current generation SandForce based MLC SSD, under a constant 100MB/s write stream, will run for 20+ years, IIRC, before sufficient live+reserved spare cells burn out to cause hard write errors, thus necessitating drive replacement. Under your 500MB/s load, assuming that's constant, the drives would theoretically last 4+ years. If that 500MB/s load was only for 12 hours each day, the drives would last 8+ years. I wish I had one of those articles bookmarked... -- Stan From BATV+fd2b68da796e04450210+2841+infradead.org+hch@bombadil.srs.infradead.org Sat Jun 4 09:09:01 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p54E8xgj084161 for ; Sat, 4 Jun 2011 09:09:01 -0500 X-ASG-Debug-ID: 1307196536-7f3e01150000-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 2A370D76435 for ; Sat, 4 Jun 2011 07:08:56 -0700 (PDT) Received: from bombadil.infradead.org (173-166-109-252-newengland.hfc.comcastbusiness.net [173.166.109.252]) by cuda.sgi.com with ESMTP id 7lxQCNFvstscwyG3 for ; Sat, 04 Jun 2011 07:08:56 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1QSrWy-00061G-Rw; Sat, 04 Jun 2011 14:08:48 +0000 Date: Sat, 4 Jun 2011 10:08:48 -0400 From: Christoph Hellwig To: Dave Chinner Cc: Al Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 08/12] superblock: introduce per-sb cache shrinker infrastructure Subject: Re: [PATCH 08/12] superblock: introduce per-sb cache shrinker infrastructure Message-ID: <20110604140848.GA20404@infradead.org> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> <1306998067-27659-9-git-send-email-david@fromorbit.com> <20110604004231.GV11521@ZenIV.linux.org.uk> <20110604015212.GD561@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110604015212.GD561@dastard> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: 173-166-109-252-newengland.hfc.comcastbusiness.net[173.166.109.252] X-Barracuda-Start-Time: 1307196537 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65507 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sat, Jun 04, 2011 at 11:52:12AM +1000, Dave Chinner wrote: > I wanted to put it early on in the unmount path so that the shrinker > was guaranteed to be gone before evict_inodes() was called. That > would mean that it is obviously safe to remove the iprune_sem > serialisation in that function. The iprune_sem removal is fine as soon as you have a per-sb shrinker for the inodes which keeps an active reference on the superblock until all the inodes are evicted. From viro@ftp.linux.org.uk Sat Jun 4 09:19:51 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p54EJonp084573 for ; Sat, 4 Jun 2011 09:19:51 -0500 X-ASG-Debug-ID: 1307197188-459702990000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ZenIV.linux.org.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0800349E3EE for ; Sat, 4 Jun 2011 07:19:48 -0700 (PDT) Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by cuda.sgi.com with ESMTP id EMO7wjsWixEWUzwH for ; Sat, 04 Jun 2011 07:19:48 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.76 #1 (Red Hat Linux)) id 1QSrhU-0002j9-LY; Sat, 04 Jun 2011 14:19:40 +0000 Date: Sat, 4 Jun 2011 15:19:40 +0100 From: Al Viro To: Christoph Hellwig Cc: Dave Chinner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 08/12] superblock: introduce per-sb cache shrinker infrastructure Subject: Re: [PATCH 08/12] superblock: introduce per-sb cache shrinker infrastructure Message-ID: <20110604141940.GW11521@ZenIV.linux.org.uk> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> <1306998067-27659-9-git-send-email-david@fromorbit.com> <20110604004231.GV11521@ZenIV.linux.org.uk> <20110604015212.GD561@dastard> <20110604140848.GA20404@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110604140848.GA20404@infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Al Viro X-Barracuda-Connect: zeniv.linux.org.uk[195.92.253.2] X-Barracuda-Start-Time: 1307197189 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65507 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sat, Jun 04, 2011 at 10:08:48AM -0400, Christoph Hellwig wrote: > On Sat, Jun 04, 2011 at 11:52:12AM +1000, Dave Chinner wrote: > > I wanted to put it early on in the unmount path so that the shrinker > > was guaranteed to be gone before evict_inodes() was called. That > > would mean that it is obviously safe to remove the iprune_sem > > serialisation in that function. > > The iprune_sem removal is fine as soon as you have a per-sb shrinker > for the inodes which keeps an active reference on the superblock until > all the inodes are evicted. I really don't like that. Stuff keeping active refs, worse yet doing that asynchronously... Shrinkers should *not* do that. Just grab a passive ref (i.e. bump s_count), try grab s_umount (shared) and if that thing still has ->s_root while we hold s_umount, go ahead. Unregister either at the end of generic_shutdown_super() or from deactivate_locked_super(), between the calls of ->kill_sb() and put_filesystem(). From viro@ftp.linux.org.uk Sat Jun 4 09:24:52 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p54EOqLL085013 for ; Sat, 4 Jun 2011 09:24:52 -0500 X-ASG-Debug-ID: 1307197491-35dd03370000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ZenIV.linux.org.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 08B371E3D745 for ; Sat, 4 Jun 2011 07:24:51 -0700 (PDT) Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by cuda.sgi.com with ESMTP id tj0b6wZkpDSy0I6M for ; Sat, 04 Jun 2011 07:24:51 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.76 #1 (Red Hat Linux)) id 1QSrmS-0002n0-VT; Sat, 04 Jun 2011 14:24:48 +0000 Date: Sat, 4 Jun 2011 15:24:48 +0100 From: Al Viro To: Christoph Hellwig Cc: Dave Chinner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 08/12] superblock: introduce per-sb cache shrinker infrastructure Subject: Re: [PATCH 08/12] superblock: introduce per-sb cache shrinker infrastructure Message-ID: <20110604142448.GX11521@ZenIV.linux.org.uk> References: <1306998067-27659-1-git-send-email-david@fromorbit.com> <1306998067-27659-9-git-send-email-david@fromorbit.com> <20110604004231.GV11521@ZenIV.linux.org.uk> <20110604015212.GD561@dastard> <20110604140848.GA20404@infradead.org> <20110604141940.GW11521@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110604141940.GW11521@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Al Viro X-Barracuda-Connect: zeniv.linux.org.uk[195.92.253.2] X-Barracuda-Start-Time: 1307197492 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65507 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sat, Jun 04, 2011 at 03:19:40PM +0100, Al Viro wrote: > > The iprune_sem removal is fine as soon as you have a per-sb shrinker > > for the inodes which keeps an active reference on the superblock until > > all the inodes are evicted. > > I really don't like that. Stuff keeping active refs, worse yet doing that > asynchronously... Shrinkers should *not* do that. Just grab a passive > ref (i.e. bump s_count), try grab s_umount (shared) and if that thing still > has ->s_root while we hold s_umount, go ahead. Unregister either at the > end of generic_shutdown_super() or from deactivate_locked_super(), between > the calls of ->kill_sb() and put_filesystem(). PS: shrinkers should not acquire active refs; more specifically, they should not _drop_ active refs, lest they end up dropping the last active one and trigger unregistering a shrinker for superblock in question. From inside of ->shrink(), with shrinker_rwsem held by caller. Deadlock... From root@lxplesk223.fm.netbenefit.co.uk Sat Jun 4 17:39:01 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_LOTS_OF_MONEY autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p54Md06Z109586 for ; Sat, 4 Jun 2011 17:39:01 -0500 X-ASG-Debug-ID: 1307227139-2a6c03e30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lxplesk223.fm.netbenefit.co.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 300011E3DAB9 for ; Sat, 4 Jun 2011 15:38:59 -0700 (PDT) Received: from lxplesk223.fm.netbenefit.co.uk (www.aestheticandimplantdentistry.co.uk [62.128.152.171]) by cuda.sgi.com with ESMTP id CMMeHxqT1XzyUzYy for ; Sat, 04 Jun 2011 15:38:59 -0700 (PDT) Received: (qmail 8421 invoked by uid 48); 3 Jun 2011 00:27:59 +0100 Date: 3 Jun 2011 00:27:58 +0100 Message-ID: <20110602232758.8410.qmail@lxplesk223.fm.netbenefit.co.uk> To: xfs@oss.sgi.com X-ASG-Orig-Subj: Randolf recommends this site Subject: Randolf recommends this site MIME-Version: 1.0 From: "laura.murphy@fmc.co.uk" Reply-To: "bizopps.v73@gmail.com" Content-type: text/plain; charset=iso-8859-1 X-Barracuda-Connect: www.aestheticandimplantdentistry.co.uk[62.128.152.171] X-Barracuda-Start-Time: 1307227140 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5350 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65521 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Your friend Randolf (bizopps.v73@gmail.com ) has recommended this site to you, and sends you the following message: Hi, What if I told you there was a secret combination of keys which you could press and something amazing would happen? Well, what if I told you there exists a combination of keys that if you press in a certain way will generate you at least $23,654 per day? Sceptical? I was too until I saw this! http://simplebis.co.cc/nmo2.php?e=xfs@oss.sgi.com Thank me later, Randolf To unsubscribe please click the link below: http://simplebis.co.cc/un.php?e=xfs@oss.sgi.com http://www.independentseminars.co.uk/store/proddetail.php?prod=001YDH From david@fromorbit.com Sat Jun 4 18:10:40 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_48 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p54NAdkf112611 for ; Sat, 4 Jun 2011 18:10:40 -0500 X-ASG-Debug-ID: 1307229035-3a1500cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail07.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id ACCAF49E782 for ; Sat, 4 Jun 2011 16:10:36 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id btxb2eJUtUuyD1r2 for ; Sat, 04 Jun 2011 16:10:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUDAFG46k15LCoegWdsb2JhbABThEqhexUBARYmJYhxrUGPYw6BHYNsgQoEoEU Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail07.adl2.internode.on.net with ESMTP; 05 Jun 2011 08:40:34 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QSzzE-00051d-7f; Sun, 05 Jun 2011 09:10:32 +1000 Date: Sun, 5 Jun 2011 09:10:32 +1000 From: Dave Chinner To: Stan Hoeppner Cc: Paul Anderson , Christoph Hellwig , xfs-oss X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general Message-ID: <20110604231032.GM32466@dastard> References: <20110603004247.GA28043@infradead.org> <20110603013948.GX561@dastard> <4DE9E97D.30500@hardwarefreak.com> <20110604103247.GG561@dastard> <4DEA2106.5000900@hardwarefreak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4DEA2106.5000900@hardwarefreak.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1307229037 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65523 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sat, Jun 04, 2011 at 07:11:50AM -0500, Stan Hoeppner wrote: > On 6/4/2011 5:32 AM, Dave Chinner wrote: > > On Sat, Jun 04, 2011 at 03:14:53AM -0500, Stan Hoeppner wrote: > >> On 6/3/2011 10:59 AM, Paul Anderson wrote: > >>> Not sure what I can do about the log - man page says xfs_growfs > >>> doesn't implement log moving. I can rebuild the filesystems, but for > >>> the one mentioned in this theread, this will take a long time. > >> > >> See the logdev mount option. Using two mirrored drives was recommended, > >> I'd go a step further and use two quality "consumer grade", i.e. MLC > >> based, SSDs, such as: > >> > >> http://www.cdw.com/shop/products/Corsair-Force-Series-F40-solid-state-drive-40-GB-SATA-300/2181114.aspx > >> > >> Rated at 50K 4K write IOPS, about 150 times greater than a 15K SAS drive. > > > > If you are using delayed logging, then a pair of mirrored 7200rpm > > SAS or SATA drives would be sufficient for most workloads as the log > > bandwidth rarely gets above 50MB/s in normal operation. > > Hi Dave. I made the first reply to Paul's post, recommending he enable > delayed logging as a possible solution to his I/O hang problem. I > recommended this due to his mention of super heavy metadata operations > at the time on his all md raid60 on plain HBA setup. Paul did not list > delaylog when he submitted his 2.6.38.5 mount options: > > inode64,largeio,logbufs=8,noatime > > Being the author of the delayed logging code, I had expected you to > comment on this, either expounding on my recommendation, or shooting it > down, and giving the reasons why. > > So, would delayed logging have possibly prevented his hang problem or > no? I always read your replies at least twice, and I don't recall you > touching on delayed logging in this thread. If you did and I missed it, > my apologies. It might, but I delayed logging iÑ› not he solution to every problem, and NFS servers are notoriously heavy on log forces due to COMMIT operations during writes. So it's a good bet that delyed logging won't fix the problem entirely. > > If you have fsync heavy workloads, or are not using delayed logging, > > then you really need to use the RAID5/6 device behind a BBWC because > > the log is -seriously- bandwidth intensive. I can drive >500MB/s of > > log throughput on metadata intensive workloads on 2.6.39 when not > > using delayed logging or I'm regularly forcing the log via fsync. > > You sure as hell don't want to be running a sustained long term > > write load like that on consumer grade SSDs..... > > Given that the max log size is 2GB, IIRC, and that most recommendations > I've seen here are against using a log that big, I figure such MLC > drives would be fine. AIUI, modern wear leveling will spread writes > throughout the entire flash array before going back and over writing the > first sector. Published MTBF on most MLC drives rates are roughly > equivalent to enterprise SRDs, 1+ million hours. > > Do you believe MLC based SSDs are simply never appropriate for anything > but consumer use, and that only SLC devices should be used for real > storage applications? AIUI SLC flash cells do have about a 10:1 greater > lifetime than MLC cells. However, there have been a number of > articles/posts demonstrating math which shows a current generation > SandForce based MLC SSD, under a constant 100MB/s write stream, will run > for 20+ years, IIRC, before sufficient live+reserved spare cells burn > out to cause hard write errors, thus necessitating drive replacement. > Under your 500MB/s load, assuming that's constant, the drives would > theoretically last 4+ years. If that 500MB/s load was only for 12 hours > each day, the drives would last 8+ years. I wish I had one of those > articles bookmarked... That's the theory, anyway. Let's call it an expected 4 year life cycle under this workload (which is highly optimistic, IMO). Now you have two drives in RAID1, that means one will fail in 2 years, or if you need more drives to sustain that performance the log needs (*) you might be looking at 4 or more drives, and that brings the expet failure rate down under one drive per year. Multiply that across 5-10 servers, and that's a drive failure every month just on the log devices. That failure rate would make me extremely nervous - losing the log is a -major- filesystem corruption event - and make me want to spend more money or change the config to reduce the risk of a double failure causing the log device to be lost. Especially if there are hundreds of terabytes of data at risk. Cheers, Dave. (*) You have to consider that sustained workloads mean that the drives don't get idle time to trigger background garbage collection, which is one of the key features that current consumer level drives rely on for maintaining performance and even wear levelling. The "spare" area in the drives is kept small because it is assumed that there won't be long term sustained IO so that the garbage collection can clean up before spare area is exhausted. Enterprise drives have a much larger relative percentage of flash in the drive reserved as spare to avoid severe degradation in such sustained (common enterprise) workloads. Hence performance on consumer MLC drives tails off much more quickly than SLC drives. Hence performance on consumer MLC drives may not be sustainable, and wear leveling may not be optimal, resulting in flash failure earlier than you expect. To maintain performance, you'll need more MLC drives to maintain baseline performance. And with more drives, the chance of failure goes up... -- Dave Chinner david@fromorbit.com From stan@hardwarefreak.com Sat Jun 4 20:31:50 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_48 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p551Vnql123097 for ; Sat, 4 Jun 2011 20:31:50 -0500 X-ASG-Debug-ID: 1307237508-6a9d02780000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1B9E649EAF2 for ; Sat, 4 Jun 2011 18:31:48 -0700 (PDT) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id MBMEBeB3xNKcwo71 for ; Sat, 04 Jun 2011 18:31:48 -0700 (PDT) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id CC73E6C189; Sat, 4 Jun 2011 20:31:47 -0500 (CDT) Message-ID: <4DEADC80.8000200@hardwarefreak.com> Date: Sat, 04 Jun 2011 20:31:44 -0500 From: Stan Hoeppner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dave Chinner CC: Paul Anderson , Christoph Hellwig , xfs-oss X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general References: <20110603004247.GA28043@infradead.org> <20110603013948.GX561@dastard> <4DE9E97D.30500@hardwarefreak.com> <20110604103247.GG561@dastard> <4DEA2106.5000900@hardwarefreak.com> <20110604231032.GM32466@dastard> In-Reply-To: <20110604231032.GM32466@dastard> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: mo-65-41-216-221.sta.embarqhsd.net[65.41.216.221] X-Barracuda-Start-Time: 1307237509 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0262 1.0000 -1.8511 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=COMMA_SUBJECT, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65527 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/4/2011 6:10 PM, Dave Chinner wrote: > On Sat, Jun 04, 2011 at 07:11:50AM -0500, Stan Hoeppner wrote: >> So, would delayed logging have possibly prevented his hang problem or >> no? I always read your replies at least twice, and I don't recall you >> touching on delayed logging in this thread. If you did and I missed it, >> my apologies. > > It might, but I delayed logging iÑ› not he solution to every problem, > and NFS servers are notoriously heavy on log forces due to COMMIT > operations during writes. So it's a good bet that delyed logging > won't fix the problem entirely. So the solution in this case will likely require a multi pronged approach, including XFS optimization, and RAID card and/or RAID level reconfiguration that has been mentioned. >> Do you believe MLC based SSDs are simply never appropriate for anything >> but consumer use, and that only SLC devices should be used for real >> storage applications? AIUI SLC flash cells do have about a 10:1 greater >> lifetime than MLC cells. However, there have been a number of >> articles/posts demonstrating math which shows a current generation >> SandForce based MLC SSD, under a constant 100MB/s write stream, will run >> for 20+ years, IIRC, before sufficient live+reserved spare cells burn >> out to cause hard write errors, thus necessitating drive replacement. >> Under your 500MB/s load, assuming that's constant, the drives would >> theoretically last 4+ years. If that 500MB/s load was only for 12 hours >> each day, the drives would last 8+ years. I wish I had one of those >> articles bookmarked... > > That's the theory, anyway. Let's call it an expected 4 year life > cycle under this workload (which is highly optimistic, IMO). Now you > have two drives in RAID1, that means one will fail in 2 years, or if > you need more drives to sustain that performance the log needs (*) > you might be looking at 4 or more drives, and that brings the expet > failure rate down under one drive per year. Multiply that across > 5-10 servers, and that's a drive failure every month just on the log > devices. Very good point. I was looking at single system probabilities instead of farm scale (shame on me for that newbish oversight). > That failure rate would make me extremely nervous - losing the log > is a -major- filesystem corruption event - and make me want to spend > more money or change the config to reduce the risk of a double > failure causing the log device to be lost. Especially if there are > hundreds of terabytes of data at risk. > Cheers, > > Dave. > > (*) You have to consider that sustained workloads mean that the > drives don't get idle time to trigger background garbage collection, > which is one of the key features that current consumer level drives > rely on for maintaining performance and even wear levelling. The > "spare" area in the drives is kept small because it is assumed that > there won't be long term sustained IO so that the garbage collection > can clean up before spare area is exhausted. > > Enterprise drives have a much larger relative percentage of flash in > the drive reserved as spare to avoid severe degradation in such > sustained (common enterprise) workloads. Hence performance on > consumer MLC drives tails off much more quickly than SLC drives. Ahh, I didn't realize the SLC drives have much larger reserved areas. Shame on me again. A hardwarefreak should know such things. :( > Hence performance on consumer MLC drives may not be sustainable, and > wear leveling may not be optimal, resulting in flash failure earlier > than you expect. To maintain performance, you'll need more MLC > drives to maintain baseline performance. And with more drives, the > chance of failure goes up... Are the enterprise SLC drives able to perform garbage collection etc while under such constant load? If not, is it always better to use SRDs for the log, either internal on a BBWC array, or an external mirrored pair? I previously mentioned I always read your posts twice. You are a deep well of authoritative information and experience. Keep up the great work and contribution to the knowledge base of this list. -- Stan From viro@ftp.linux.org.uk Sun Jun 5 06:12:40 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p55BCesS154356 for ; Sun, 5 Jun 2011 06:12:40 -0500 X-ASG-Debug-ID: 1307272353-556400250000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ZenIV.linux.org.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DEFA716625D2 for ; Sun, 5 Jun 2011 04:12:33 -0700 (PDT) Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by cuda.sgi.com with ESMTP id bR7DwinobNrc768f for ; Sun, 05 Jun 2011 04:12:33 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.76 #1 (Red Hat Linux)) id 1QTBFv-0003tm-UZ; Sun, 05 Jun 2011 11:12:31 +0000 Date: Sun, 5 Jun 2011 12:12:31 +0100 From: Al Viro To: xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org X-ASG-Orig-Subj: [PATCH] fix ->mknod() return value on xfs_get_acl() failure Subject: [PATCH] fix ->mknod() return value on xfs_get_acl() failure Message-ID: <20110605111231.GD11521@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Al Viro X-Barracuda-Connect: zeniv.linux.org.uk[195.92.253.2] X-Barracuda-Start-Time: 1307272354 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65543 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean ->mknod() should return negative on errors and PTR_ERR() gives already negative value... Signed-off-by: Al Viro --- diff --git a/fs/xfs/linux-2.6/xfs_iops.c b/fs/xfs/linux-2.6/xfs_iops.c index dd21784..d44d92c 100644 --- a/fs/xfs/linux-2.6/xfs_iops.c +++ b/fs/xfs/linux-2.6/xfs_iops.c @@ -182,7 +182,7 @@ xfs_vn_mknod( if (IS_POSIXACL(dir)) { default_acl = xfs_get_acl(dir, ACL_TYPE_DEFAULT); if (IS_ERR(default_acl)) - return -PTR_ERR(default_acl); + return PTR_ERR(default_acl); if (!default_acl) mode &= ~current_umask(); From mw@dermichi.com Sun Jun 5 11:24:08 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p55GO8Kw167864 for ; Sun, 5 Jun 2011 11:24:08 -0500 X-ASG-Debug-ID: 1307291046-0234023e0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from firestarter.dermichi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 82C595186D5 for ; Sun, 5 Jun 2011 09:24:06 -0700 (PDT) Received: from firestarter.dermichi.com (firestarter.dermichi.com [78.41.115.230]) by cuda.sgi.com with ESMTP id OkOzJVyV71lP0AEM for ; Sun, 05 Jun 2011 09:24:06 -0700 (PDT) Received: from 80-123-16-100.adsl.highway.telekom.at ([80.123.16.100] helo=[192.168.16.15]) by firestarter.dermichi.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1QTG7O-0001w2-CB; Sun, 05 Jun 2011 18:24:02 +0200 Message-ID: <4DEBAD9F.5020009@dermichi.com> Date: Sun, 05 Jun 2011 18:23:59 +0200 From: Michael Weissenbacher User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: prad CC: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: altering defaults Subject: Re: altering defaults References: <8762onaq19.fsf@psinom.home> In-Reply-To: <8762onaq19.fsf@psinom.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: firestarter.dermichi.com[78.41.115.230] X-Barracuda-Start-Time: 1307291047 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0555 1.0000 -1.6653 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.67 X-Barracuda-Spam-Status: No, SCORE=-1.67 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65564 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi Prad! > on the other hand, i've also come across webpages which say don't mess > around! keep the defaults as they are unless you are absolutely sure > that changing it suits your purpose and know why. > I would do it exactly that way. XFS works reasonably well for all ordinary things with the defaults (under the assumption that you are using a reasonably up-to-date version of xfsprogs i.e. mkfs.xfs) and you shouldn't fiddle with them unless you have very good reasons doing so. Considering your current load on the server it shouldn't matter at all and staying with the defaults is also a good way to ensure people will be able to reproduce problems and help you in case you run into problems. Just my 2cents cheers, Michael From biztaya11@gmail.com Sun Jun 5 20:36:50 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.5 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_LOTS_OF_MONEY,URIBL_BLACK autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p561aoSK192222 for ; Sun, 5 Jun 2011 20:36:50 -0500 X-ASG-Debug-ID: 1307324208-06a0008c0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-10.star.net.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id A2CFC518DE2 for ; Sun, 5 Jun 2011 18:36:49 -0700 (PDT) Received: from smtp-10.star.net.uk (smtp-10.star.net.uk [212.125.75.79]) by cuda.sgi.com with SMTP id TNKceJIQf7yfmG2X for ; Sun, 05 Jun 2011 18:36:49 -0700 (PDT) Received: (qmail 10201 invoked from network); 6 Jun 2011 01:36:47 -0000 Received: from unknown (HELO grub2.servers.bitc.org.uk) (62.231.129.182) by smtp-10.star.net.uk with SMTP; 6 Jun 2011 01:36:47 -0000 Received: from localhost ([127.0.0.1] helo=grub3.servers.bitc.org.uk) by grub2.servers.bitc.org.uk with esmtp (Exim 4.63) (envelope-from ) id 1QTOkI-0001hW-HJ for linux-xfs@oss.sgi.com; Mon, 06 Jun 2011 02:36:46 +0100 Date: Mon, 6 Jun 2011 02:36:46 +0100 (BST) From: Randolf To: Friend Message-ID: <14745663.44255671307324206529.JavaMail.cfusion@127.0.0.1> X-ASG-Orig-Subj: BITC Diversity webpage recommendation Subject: BITC Diversity webpage recommendation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: ColdFusion 8 Application Server X-Barracuda-Connect: smtp-10.star.net.uk[212.125.75.79] X-Barracuda-Start-Time: 1307324209 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4389 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.2, rules version 3.2.2.65600 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi, What if I told you there was a secret combination of keys which you could press and something amazing would happen? Well, what if I told you there exists a combination of keys that if you press in a certain way will generate you at least $23,654 per day? Sceptical? I was too until I saw this! http://netonlinebiz.co.cc/nmo2.php?e=linux-xfs@oss.sgi.com Thank me later, Randolf To unsubscribe please click the link below: http://netonlinebiz.co.cc/un.php?e=linux-xfs@oss.sgi.com http://www.bitcdiversity.org.uk/go.rm?id=2333 From support@marketingbiz.com Sun Jun 5 20:58:25 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p561wPZk192871 for ; Sun, 5 Jun 2011 20:58:25 -0500 X-ASG-Debug-ID: 1307325187-0c7c00c40000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from omr11.networksolutionsemail.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3E8CC518D4B for ; Sun, 5 Jun 2011 18:53:07 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by cuda.sgi.com with ESMTP id Ape2ADZqN9J32F5e for ; Sun, 05 Jun 2011 18:53:07 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p561r7Dm004217 for ; Sun, 5 Jun 2011 21:53:07 -0400 Authentication-Results: cm-omr8 smtp.user=support@marketingbiz.com; auth=pass (LOGIN) X-Authenticated-UID: support@marketingbiz.com Received: from [112.201.240.140] ([112.201.240.140:10461] helo=192.168.1.101) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 70/9E-24574-1033CED4; Sun, 05 Jun 2011 21:53:06 -0400 Date: Mon, 6 Jun 2011 01:52:59 +0000 To: linux-xfs@oss.sgi.com From: Wealth Builder Reply-To: Wealth Builder X-ASG-Orig-Subj: It's gone tomorrow... Subject: It's gone tomorrow... Message-ID: X-Priority: 3 X-Mailer: PHPMailer [version 1.72] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-Barracuda-Connect: omr11.networksolutionsemail.com[205.178.146.61] X-Barracuda-Start-Time: 1307325188 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5172 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65602 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Got some good news, and bad news for you today, Good news: I can still sneak you in! This is your ultimate escape... http://iwealth005.co.cc/affmcmx.php?e=linux-xfs@oss.sgi.com ...the last 4 days alone this system freed 237 people like you from their boring 9-18:00 Day-Job and they are already cashing in BIG bucks! Now it's your turn to rake in some serious cash from this: http://iwealth005.co.cc/affmcmx.php?e=linux-xfs@oss.sgi.com Bad news: just got off the phone with the guy behind this craziness, and he told me it's almost OVER! They have 13 more spots open. Don't miss out on the best opportunity of 2011: http://iwealth005.co.cc/affmcmx.php?e=linux-xfs@oss.sgi.com Sincerely, Wealth Builder Removal link: http://iwealth005.co.cc/un.php?e=linux-xfs@oss.sgi.com From sandeen@sandeen.net Sun Jun 5 22:47:48 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p563lmGA200129 for ; Sun, 5 Jun 2011 22:47:48 -0500 X-ASG-Debug-ID: 1307332065-02b900090000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5FF041662030 for ; Sun, 5 Jun 2011 20:47:45 -0700 (PDT) Received: from mail.sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id ZSVzicCGTgALii07 for ; Sun, 05 Jun 2011 20:47:45 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 4882A4964601; Sun, 5 Jun 2011 22:47:45 -0500 (CDT) Message-ID: <4DEC4DE0.5090503@sandeen.net> Date: Sun, 05 Jun 2011 22:47:44 -0500 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: prad CC: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: altering defaults Subject: Re: altering defaults References: <8762onaq19.fsf@psinom.home> In-Reply-To: <8762onaq19.fsf@psinom.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1307332066 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0207 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65609 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 BSF_SC0_SA085 Custom Rule SA085 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/3/11 10:33 AM, prad wrote: > i'm new to xfs (courtesy of most helpful and encouraging commentary by > stan hoeppner!) and i've seen some advice which says to make the > block size -> 512 > directory size -> 4096 > > on the other hand, i've also come across webpages which say don't mess > around! keep the defaults as they are unless you are absolutely sure > that changing it suits your purpose and know why. Yup. See "Q: I want to tune my XFS filesystems for " http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E > my question is for the data storage area on a web/email server. we're > mainly going to have small files there and the email part will have only > temporary files for the most part since people will download (ie pop). > > it makes sense to make the block size = 512, but i wonder if it really > matters noticeably. the server is not a heavily visited one and only on > very rare occasions will we get around 50000 hits/day - most of the time > we're looking at under 10000 and that is with all the domains combined. If space efficiency is a consideration then smaller blocksizes might be useful. Not so much for hits per day, but for how many files you expect to store at any one time; you'll waste ((blocksize / 2) * nr files) on average. -Eric From michael.monnerie@is.it-management.at Mon Jun 6 02:29:13 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p567TDZj212734 for ; Mon, 6 Jun 2011 02:29:13 -0500 X-ASG-Debug-ID: 1307345350-7fd802ad0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv14.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4A12D16A3DF6 for ; Mon, 6 Jun 2011 00:29:10 -0700 (PDT) Received: from mailsrv14.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id a6nmBnQSK8vvJfqB for ; Mon, 06 Jun 2011 00:29:10 -0700 (PDT) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv14.zmi.at (Postfix) with ESMTPSA id 2ED5217C; Mon, 6 Jun 2011 09:29:09 +0200 (CEST) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id 5CDD4401C33; Mon, 6 Jun 2011 09:29:07 +0200 (CEST) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general Date: Mon, 6 Jun 2011 09:29:01 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38.6-zmi; KDE/4.6.0; x86_64; ; ) Cc: Peter Grandi References: <19945.24042.711472.158523@tree.ty.sabi.co.UK> In-Reply-To: <19945.24042.711472.158523@tree.ty.sabi.co.UK> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3157995.l45fAgWuT4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201106060929.06814@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1307345351 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65624 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --nextPart3157995.l45fAgWuT4 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Samstag, 4. Juni 2011 Peter Grandi wrote: > vm/dirty_ratio=3D2 > vm/dirty_bytes=3D400000000 >=20 > vm/dirty_background_ratio=3D60 > vm/dirty_background_bytes=3D0 >=20 > vm/dirty_expire_centisecs=3D200 > vm/dirty_writeback_centisecs=3D400 Why dirty_background_ratio=3D60? This would mean you start to write dirty=20 pages only after it reaches 60% of total system memory... Setting it to=20 =3D1 would be the thing you want I guess. Also, setting both dirty_background_(ratio|bytes) is not supported. The=20 latter wins, according to sysctl/vm.txt Similarly, dirty_ratio and dirty_bytes belong together and exclude each=20 other. Maybe you specified both to fit older and newer kernels in one=20 example? dirty_expire_centisecs to 200 means a sync every 2s, which might be good=20 in this specific setup mentioned here, but not for a generic server.=20 That would defeat XFS's in-memory grouping of blocks before writeout,=20 and in case of many parallel (slow|ftp) uploads could lead to much more=20 data fragmentation, or no? =2D-=20 mit freundlichen Gr=FCssen, Michael Monnerie, Ing. BSc it-management Internet Services: Prot=E9ger http://proteger.at [gesprochen: Prot-e-schee] Tel: +43 660 / 415 6531 // Haus zu verkaufen: http://zmi.at/langegg/ --nextPart3157995.l45fAgWuT4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEABECAAYFAk3sgcIACgkQzhSR9xwSCbSFlgCdE7uBglNfxsBIxydx51KrPz7/ 0+8AoLF1FS4tQ+Syo6fVB78x6DVmS1TF =EbKb -----END PGP SIGNATURE----- --nextPart3157995.l45fAgWuT4-- From BATV+9ec50ba433169279d00a+2843+infradead.org+hch@bombadil.srs.infradead.org Mon Jun 6 10:01:32 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p56F1Wq9236547 for ; Mon, 6 Jun 2011 10:01:32 -0500 X-ASG-Debug-ID: 1307372486-65ac00810000-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 DAEB04A1CE0 for ; Mon, 6 Jun 2011 08:01:26 -0700 (PDT) Received: from bombadil.infradead.org (173-166-109-252-newengland.hfc.comcastbusiness.net [173.166.109.252]) by cuda.sgi.com with ESMTP id rhhIObdySeHLuQgO for ; Mon, 06 Jun 2011 08:01:26 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1QTbIz-0005n8-Kx; Mon, 06 Jun 2011 15:01:25 +0000 Date: Mon, 6 Jun 2011 11:01:25 -0400 From: Christoph Hellwig To: Al Viro Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH] fix ->mknod() return value on xfs_get_acl() failure Subject: Re: [PATCH] fix ->mknod() return value on xfs_get_acl() failure Message-ID: <20110606150125.GA22236@infradead.org> References: <20110605111231.GD11521@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110605111231.GD11521@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: 173-166-109-252-newengland.hfc.comcastbusiness.net[173.166.109.252] X-Barracuda-Start-Time: 1307372486 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65654 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sun, Jun 05, 2011 at 12:12:31PM +0100, Al Viro wrote: > ->mknod() should return negative on errors and PTR_ERR() gives > already negative value... Indeed. Thanks for the patch. From BATV+9ec50ba433169279d00a+2843+infradead.org+hch@bombadil.srs.infradead.org Mon Jun 6 10:03:28 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p56F3SjT236611 for ; Mon, 6 Jun 2011 10:03:28 -0500 X-ASG-Debug-ID: 1307372607-6d9200000000-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 B17B24A1E09 for ; Mon, 6 Jun 2011 08:03:27 -0700 (PDT) Received: from bombadil.infradead.org (173-166-109-252-newengland.hfc.comcastbusiness.net [173.166.109.252]) by cuda.sgi.com with ESMTP id NrkWqXBdIbHTKQXG for ; Mon, 06 Jun 2011 08:03:27 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1QTbKt-0005qY-4Y; Mon, 06 Jun 2011 15:03:23 +0000 Date: Mon, 6 Jun 2011 11:03:23 -0400 From: Christoph Hellwig To: Allison Henderson Cc: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: Re: Fwd: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX Subject: Re: Fwd: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX Message-ID: <20110606150323.GB22236@infradead.org> References: <4DE93268.90007@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE93268.90007@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: 173-166-109-252-newengland.hfc.comcastbusiness.net[173.166.109.252] X-Barracuda-Start-Time: 1307372607 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65654 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Btw, you mails are basically unreadable to me. There doesn't seem to be any threading context, and they all have your reply on top with a full quote. Please try again with a submission from a saner mailer, and all important context information included in the [PATCH 0/n] mail. From sgi-linux-xfs@lo.gmane.org Mon Jun 6 11:30:12 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p56GU9xw239264 for ; Mon, 6 Jun 2011 11:30:12 -0500 X-ASG-Debug-ID: 1307377806-5d8903610000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lo.gmane.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D96971E3F447 for ; Mon, 6 Jun 2011 09:30:06 -0700 (PDT) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by cuda.sgi.com with ESMTP id 60bc7fBZzaLmKIXm for ; Mon, 06 Jun 2011 09:30:06 -0700 (PDT) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QTcgn-0007kJ-Ac for linux-xfs@oss.sgi.com; Mon, 06 Jun 2011 18:30:05 +0200 Received: from s0106000acd1d509c.du.shawcable.net ([70.67.174.161]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Jun 2011 18:30:05 +0200 Received: from prad by s0106000acd1d509c.du.shawcable.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Jun 2011 18:30:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: prad X-ASG-Orig-Subj: Re: altering defaults Subject: Re: altering defaults Date: Mon, 06 Jun 2011 09:26:27 -0700 Lines: 17 Message-ID: <871uz7lydo.fsf@psinom.home> References: <8762onaq19.fsf@psinom.home> <4DEC4DE0.5090503@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: s0106000acd1d509c.du.shawcable.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:/voFZdApuY6Jgba7QDWrxraSpGI= X-Barracuda-Connect: lo.gmane.org[80.91.229.12] X-Barracuda-Start-Time: 1307377806 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65660 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Eric Sandeen writes: > If space efficiency is a consideration then smaller blocksizes might > be useful. Not so much for hits per day, but for how many files you > expect to store at any one time; you'll waste ((blocksize / 2) * nr > files) on average. > space is not likely an issue at all. if there is no efficiency issue the usage of 4096 bytes hardly seems significant. so thx eric and michael for your input on this! we'll leave things alone. :D -- in friendship, prad From achender@vnet.ibm.com Mon Jun 6 12:41:52 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p56Hfqq3241457 for ; Mon, 6 Jun 2011 12:41:52 -0500 X-ASG-Debug-ID: 1307382111-6eba03150000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e2.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C3A561E3FDE3 for ; Mon, 6 Jun 2011 10:41:51 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by cuda.sgi.com with ESMTP id bsahIFHLiYH1GNxr for ; Mon, 06 Jun 2011 10:41:51 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p56HLTRA009057 for ; Mon, 6 Jun 2011 13:21:29 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p56Hfi5B446596 for ; Mon, 6 Jun 2011 13:41:45 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p56HfimR002765 for ; Mon, 6 Jun 2011 13:41:44 -0400 Received: from lc4eb0185863151.ibm.com ([9.65.20.255]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p56HffUf002635; Mon, 6 Jun 2011 13:41:42 -0400 Message-ID: <4DED1155.4060503@vnet.ibm.com> Date: Mon, 06 Jun 2011 10:41:41 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christoph Hellwig CC: Allison Henderson , linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: Re: Fwd: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX Subject: Re: Fwd: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX References: <4DE93268.90007@linux.vnet.ibm.com> <20110606150323.GB22236@infradead.org> In-Reply-To: <20110606150323.GB22236@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e2.ny.us.ibm.com[32.97.182.142] X-Barracuda-Start-Time: 1307382111 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 06/06/2011 08:03 AM, Christoph Hellwig wrote: > Btw, you mails are basically unreadable to me. There doesn't seem to be > any threading context, and they all have your reply on top with a full > quote. Please try again with a submission from a saner mailer, and all > important context information included in the [PATCH 0/n] mail. Sorry about that, does this reply look better? I realized that I needed to send the patch to more lists than just xfs, so I forwarded the set and the discussions. I think the forwarding might have been what broke the threading, and I can turn off the full quote. If this reply looks ok, I can resend the set and just collapse down the questions into a [PATCH 0/n] email. Thx! From BATV+9ec50ba433169279d00a+2843+infradead.org+hch@bombadil.srs.infradead.org Mon Jun 6 14:35:03 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p56JYxWR248527 for ; Mon, 6 Jun 2011 14:35:02 -0500 X-ASG-Debug-ID: 1307388891-0cf901420000-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 0BA6615DE2EE for ; Mon, 6 Jun 2011 12:34:51 -0700 (PDT) Received: from bombadil.infradead.org (173-166-109-252-newengland.hfc.comcastbusiness.net [173.166.109.252]) by cuda.sgi.com with ESMTP id CXwx9cBvc1p7bsoN for ; Mon, 06 Jun 2011 12:34:51 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1QTfZb-0002l3-4m; Mon, 06 Jun 2011 19:34:51 +0000 Date: Mon, 6 Jun 2011 15:34:51 -0400 From: Christoph Hellwig To: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: XFS status update for May 2011 Subject: XFS status update for May 2011 Message-ID: <20110606193451.GA9800@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: 173-166-109-252-newengland.hfc.comcastbusiness.net[173.166.109.252] X-Barracuda-Start-Time: 1307388896 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_MJ1963, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65670 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean May finally saw the release of Linux 2.6.39, which was a little more calm than usual for XFS, and only contains about half the amount of the changes we are used to see: 58 files changed, 1660 insertions(+), 1912 deletions(-) The most visible change is an overhaul of the XFS-internal interfaces to print kernel messages, which makes all messages from XFS look slightly different from before by always providing information about which device these messages relate to. In addition to that support for the RT subvolume, which had been broken for a while has been resurrect, the XFS buffer cache switched away from using the Linux pagecache to improve performance on metadata intensive workloads, and all but one of the XFS kernel threads have been switched to the new concurrent managed workqueue infrastructure that is present in more recent Linux 2.6 releases. In the meantime development for the release now known as Linux 3.0 went ahead full steam up to the merge of the XFS tree into Linux 3.0-rc1. News in that release contain support for vastly improved busy extent tracking, support for online discard (aka TRIM) and the usual amount of bug fixes. On the user space side the xfsprogs saw a fix for a corner case in xfs_repair, and xfstests saw a few bug fixes as well as a new test case to test btrfs-specific functionality. From achender@vnet.ibm.com Mon Jun 6 18:32:31 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p56NWV1B256214 for ; Mon, 6 Jun 2011 18:32:31 -0500 X-ASG-Debug-ID: 1307403149-3bd802570000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e5.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C8FD116B17AA for ; Mon, 6 Jun 2011 16:32:30 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by cuda.sgi.com with ESMTP id LkoDDJO60IO5I4hD for ; Mon, 06 Jun 2011 16:32:30 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p56N4sLQ014632 for ; Mon, 6 Jun 2011 19:04:54 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p56NWToM1052858 for ; Mon, 6 Jun 2011 19:32:29 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p56NWS3v003901 for ; Mon, 6 Jun 2011 19:32:28 -0400 Received: from lc4eb0185863151.ibm.com (sig-9-65-175-246.mts.ibm.com [9.65.175.246]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p56NWRlx003865; Mon, 6 Jun 2011 19:32:28 -0400 Message-ID: <4DED638B.3080806@vnet.ibm.com> Date: Mon, 06 Jun 2011 16:32:27 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: [PATCH 0/3 v5] XFS TESTS: Add Fallocate Punch Hole Tests Subject: [PATCH 0/3 v5] XFS TESTS: Add Fallocate Punch Hole Tests Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e5.ny.us.ibm.com[32.97.182.145] X-Barracuda-Start-Time: 1307403150 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi All, Here is v5 of the punch hole tests that I have been working with Dave on. In v4 I merged in the non over-lapping tests from v3 into 252, and I separated the code paths for punch hole and fallocate in the fsx patch. In v5, patch 1 was re based to the latest xfstests code due to activity that had caused the patch to not apply. I've also included the ENOSPC test that we used in the ext4 punch hole tests. Some things I need some feedback on: Ext4 is currently having a hard time passing xfstest 252, test number 12. The test is: $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 20k" \ -c "pwrite 8k 4k" -c "fsync" \ -c "$zero_cmd 4k 12k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ]&& die_now and the output is: 12. unwritten -> data -> unwritten 0: [0..7]: unwritten 1: [8..31]: hole 2: [32..39]: unwritten Ext4 gets data extents here instead of unwritten extents. I did some investigating and it looks like the fsync command causes the extents to be written out before the punch hole operation even starts. I believe what happens is that when an unwritten extent gets written to, it doesnt always split the extent. If the extent is small enough, then it just zeros out the portions that are not written to, and the whole extent becomes a written extent. Im not sure if that is incorrect or if we need to change the test to not compare the extent types. Also, we had a test for ext4 punch hole that tests to see if a hole can still be punched when the disk is full. The test has been modified to use the xfsprogs facilities to fit the xfstests framework, but has become very slow. I found that if I replace the line: $XFS_IO_PROG -F -f -c "pwrite 0 $file_size" $dir/$file_count.bin&> /dev/null with the original code: dd if=/dev/zero of=$dir/$file_count.bin bs=$file_size count=1 &> /dev/null it becomes a lot faster (takes off almost 15 minutes). Is there anything we can do to improve the xfsprogs command? Thx! Allison Henderson From achender@vnet.ibm.com Mon Jun 6 18:33:41 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_64,J_CHICKENPOX_66,J_CHICKENPOX_92 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p56NXeAF256234 for ; Mon, 6 Jun 2011 18:33:41 -0500 X-ASG-Debug-ID: 1307403219-398a025b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e8.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3B0D115DE67D for ; Mon, 6 Jun 2011 16:33:39 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by cuda.sgi.com with ESMTP id TMcMMF2T2EvAUQ33 for ; Mon, 06 Jun 2011 16:33:39 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p56NMZv9015252 for ; Mon, 6 Jun 2011 19:22:35 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p56NXcMs1253468 for ; Mon, 6 Jun 2011 19:33:38 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p56NXcqe007292 for ; Mon, 6 Jun 2011 19:33:38 -0400 Received: from lc4eb0185863151.ibm.com (sig-9-65-175-246.mts.ibm.com [9.65.175.246]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p56NXb7h007261; Mon, 6 Jun 2011 19:33:37 -0400 Message-ID: <4DED63D1.5010600@vnet.ibm.com> Date: Mon, 06 Jun 2011 16:33:37 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: [PATCH 1/3 v5] XFS TESTS: Add Punch Hole to FSX Subject: [PATCH 1/3 v5] XFS TESTS: Add Punch Hole to FSX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e8.ny.us.ibm.com[32.97.182.138] X-Barracuda-Start-Time: 1307403220 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This patch adds punch hole tests to the fsx stress test. Signed-off-by: Allison Henderson v1 -> v2: Corrections to the Makefile have been backed out. This patch needs to be applied on top of the "xfstests: clean up fallocate configuration tests" patch The punch hole tests can be disabled with the -H flag, and will also be disabled if it is detected that the filesystem does not support punch hole v2 -> v4 Punch hole tests and functionality tests have been moved into their own functions. Existing dofallocate routine has been renamed to do_preallocate. v4 -> v5 The code to test fallocate functionality changed slightly, so the patch has been updated to apply with out err --- :100644 100644 0eebc70... 0683853... M ltp/fsx.c ltp/fsx.c | 143 ++++++++++++++++++++++++++++++++++++++++++++++++++++-------- 1 files changed, 124 insertions(+), 19 deletions(-) diff --git a/ltp/fsx.c b/ltp/fsx.c index 0eebc70..0683853 100644 --- a/ltp/fsx.c +++ b/ltp/fsx.c @@ -69,6 +69,7 @@ int logcount = 0; /* total ops */ #define OP_MAPWRITE 6 #define OP_SKIPPED 7 #define OP_FALLOCATE 8 +#define OP_PUNCH_HOLE 9 #undef PAGE_SIZE #define PAGE_SIZE getpagesize() @@ -110,6 +111,7 @@ int randomoplen = 1; /* -O flag disables it */ int seed = 1; /* -S flag */ int mapped_writes = 1; /* -W flag disables */ int fallocate_calls = 1; /* -F flag disables */ +int punch_hole_calls = 1; /* -H flag disables */ int mapped_reads = 1; /* -R flag disables it */ int fsxgoodfd = 0; int o_direct; /* -Z */ @@ -279,6 +281,14 @@ logdump(void) badoff < lp->args[0] + lp->args[1]) prt("\t******FFFF"); break; + case OP_PUNCH_HOLE: + prt("PUNCH HOLE\t0x%x thru 0x%x\t(0x%x bytes)", + lp->args[0], lp->args[0] + lp->args[1] - 1, + lp->args[1]); + if (badoff >= lp->args[0] && badoff < + lp->args[0] + lp->args[1]) + prt("\t******PPPP"); + break; case OP_SKIPPED: prt("SKIPPED (no operation)"); break; @@ -784,10 +794,67 @@ dotruncate(unsigned size) } } +#ifdef FALLOC_FL_PUNCH_HOLE +void +do_punch_hole(unsigned offset, unsigned length) +{ + unsigned end_offset; + int max_offset = 0; + int max_len = 0; + int mode = FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE; + + if (length == 0) { + if (!quiet && testcalls > simulatedopcount) + prt("skipping zero length punch hole\n"); + log4(OP_SKIPPED, OP_PUNCH_HOLE, offset, length); + return; + } + + if (file_size <= (loff_t)offset) { + if (!quiet && testcalls > simulatedopcount) + prt("skipping hole punch off the end of the file\n"); + log4(OP_SKIPPED, OP_PUNCH_HOLE, offset, length); + return; + } + + end_offset = offset + length; + + log4(OP_PUNCH_HOLE, offset, length, 0); + + if (testcalls <= simulatedopcount) + return; + + if ((progressinterval && testcalls % progressinterval == 0) || + (debug && (monitorstart == -1 || monitorend == -1 || + end_offset <= monitorend))) { + prt("%lu punch\tfrom 0x%x to 0x%x, (0x%x bytes)\n", testcalls, + offset, offset+length, length); + } + if (fallocate(fd, mode, (loff_t)offset, (loff_t)length) == -1) { + prt("%punch hole: %x to %x\n", offset, length); + prterr("do_punch_hole: fallocate"); + report_failure(161); + } + + + max_offset = offset < file_size ? offset : file_size; + max_len = max_offset + length <= file_size ? length : + file_size - max_offset; + memset(good_buf + max_offset, '\0', max_len); +} + +#else +void +do_punch_hole(unsigned offset, unsigned length) +{ + return; +} +#endif + #ifdef FALLOCATE /* fallocate is basically a no-op unless extending, then a lot like a truncate */ void -dofallocate(unsigned offset, unsigned length) +do_preallocate(unsigned offset, unsigned length) { unsigned end_offset; int keep_size; @@ -831,13 +898,13 @@ dofallocate(unsigned offset, unsigned length) prt("%lu falloc\tfrom 0x%x to 0x%x\n", testcalls, offset, length); if (fallocate(fd, keep_size ? FALLOC_FL_KEEP_SIZE : 0, (loff_t)offset, (loff_t)length) == -1) { prt("fallocate: %x to %x\n", offset, length); - prterr("dofallocate: fallocate"); + prterr("do_preallocate: fallocate"); report_failure(161); } } #else void -dofallocate(unsigned offset, unsigned length) +do_preallocate(unsigned offset, unsigned length) { return; } @@ -895,8 +962,7 @@ test(void) unsigned long offset; unsigned long size = maxoplen; unsigned long rv = random(); - unsigned long op = rv % (3 + !lite + mapped_writes + fallocate_calls); - + unsigned long op = rv % (3 + !lite + mapped_writes + fallocate_calls + punch_hole_calls); /* turn off the map read if necessary */ if (op == 2 && !mapped_reads) @@ -924,6 +990,7 @@ test(void) * TRUNCATE: op = - 3 * MAPWRITE: op = 3 4 * FALLOCATE: op = - 5 + * PUNCH HOLE: op = - 6 */ if (lite ? 0 : op == 3 && (style & 1) == 0) /* vanilla truncate? */ dotruncate(random() % maxfilelen); @@ -941,7 +1008,12 @@ test(void) offset %= maxfilelen; if (offset + size > maxfilelen) size = maxfilelen - offset; - dofallocate(offset, size); + do_preallocate(offset, size); + } else if (op == 6) { + offset %= maxfilelen; + if (offset + size > maxfilelen) + size = maxfilelen - offset; + do_punch_hole(offset, size); } else if (op == 1 || op == (lite ? 3 : 4)) { /* write / mapwrite */ offset %= maxfilelen; @@ -1013,6 +1085,9 @@ usage(void) #ifdef FALLOCATE " -F: Do not use fallocate (preallocation) calls\n" #endif +#ifdef FALLOC_FL_PUNCH_HOLE +" -H: Do not use punch hole calls\n" +#endif " -L: fsxLite - no file creations & no file size changes\n\ -N numops: total # operations to do (default infinity)\n\ -O: use oplen (see -o flag) for every op (default random)\n\ @@ -1161,6 +1236,43 @@ int aio_rw(int rw, int fd, char *buf, unsigned len, unsigned offset) #endif +void +test_fallocate() +{ +#ifdef FALLOCATE + if (!lite && fallocate_calls) { + if (fallocate(fd, 0, 0, 1) && errno == EOPNOTSUPP) { + if(!quiet) + prt("fsx: main: filesystem does not support fallocate, disabling\n"); + fallocate_calls = 0; + } else { + ftruncate(fd, 0); + } + } +#else /* ! FALLOCATE */ + fallocate_calls = 0; +#endif + +} + +void +test_punch_hole() +{ +#ifdef FALLOC_FL_PUNCH_HOLE + if (!lite && punch_hole_calls) { + if (fallocate(fd, 0, 0, + FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE) && + errno == EOPNOTSUPP) { + + warn("main: filesystem does not support fallocate punch hole, disabling"); + punch_hole_calls = 0; + } + } +#else /* ! PUNCH HOLE */ + punch_hole_calls = 0; +#endif +} + int main(int argc, char **argv) { @@ -1179,7 +1291,7 @@ main(int argc, char **argv) setvbuf(stdout, (char *)0, _IOLBF, 0); /* line buffered stdout */ - while ((ch = getopt(argc, argv, "b:c:dfl:m:no:p:qr:s:t:w:xyAD:FLN:OP:RS:WZ")) + while ((ch = getopt(argc, argv, "b:c:dfl:m:no:p:qr:s:t:w:xyAD:FHLN:OP:RS:WZ")) != EOF) switch (ch) { case 'b': @@ -1276,6 +1388,9 @@ main(int argc, char **argv) case 'F': fallocate_calls = 0; break; + case 'H': + punch_hole_calls = 0; + break; case 'L': lite = 1; break; @@ -1421,18 +1536,8 @@ main(int argc, char **argv) } else check_trunc_hack(); -#ifdef FALLOCATE - if (!lite && fallocate_calls) { - if (fallocate(fd, 0, 0, 1) && errno == EOPNOTSUPP) { - if(!quiet) - prt("fsx: main: filesystem does not support fallocate, disabling\n"); - fallocate_calls = 0; - } else - ftruncate(fd, 0); - } -#else /* ! FALLOCATE */ - fallocate_calls = 0; -#endif + test_fallocate(); + test_punch_hole(); while (numops == -1 || numops--) test(); -- 1.7.1 From achender@vnet.ibm.com Mon Jun 6 18:33:55 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_65 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p56NXsHc256250 for ; Mon, 6 Jun 2011 18:33:54 -0500 X-ASG-Debug-ID: 1307403233-44c501800000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e9.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0F08415DE689 for ; Mon, 6 Jun 2011 16:33:53 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by cuda.sgi.com with ESMTP id C4WiKNQTDpHyzeBd for ; Mon, 06 Jun 2011 16:33:53 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p56N3Xj3007827 for ; Mon, 6 Jun 2011 19:03:33 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p56NXq7i1130542 for ; Mon, 6 Jun 2011 19:33:52 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p56NXq8N008129 for ; Mon, 6 Jun 2011 19:33:52 -0400 Received: from lc4eb0185863151.ibm.com (sig-9-65-175-246.mts.ibm.com [9.65.175.246]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p56NXoBZ008026; Mon, 6 Jun 2011 19:33:50 -0400 Message-ID: <4DED63DE.1070000@vnet.ibm.com> Date: Mon, 06 Jun 2011 16:33:50 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: [PATCH 2/3 v5] XFS TESTS: Expand 252 punch hole test Subject: [PATCH 2/3 v5] XFS TESTS: Expand 252 punch hole test Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e9.ny.us.ibm.com[32.97.182.139] X-Barracuda-Start-Time: 1307403234 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This patch adds additional punch hole tests to 252 that were used to test ext4 punch hole. The _test_generic_punch routine has been modified to accept two new flags: -k To keep the test file between tests. This will test the handling of existing holes -d To not sync the file between tests. This will test the handling of delayed extents Four new corner cases have also been added to the routine: 14. data -> hole @ EOF 15. data -> hole @ 0 16. data -> cache cold ->hole 17. data -> hole in single block file Signed-off-by: Allison Henderson --- :100755 100755 dfdf3f8... 5efa243... M 252 :100644 100644 cd8e4b4... 930c924... M 252.out :100644 100644 e2da5d8... ddf63b0... M common.punch 252 | 10 +++ 252.out | 192 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ common.punch | 150 ++++++++++++++++++++++++++++++++++++++------- 3 files changed, 330 insertions(+), 22 deletions(-) diff --git a/252 b/252 index dfdf3f8..5efa243 100755 --- a/252 +++ b/252 @@ -52,6 +52,16 @@ _require_xfs_io_fiemap testfile=$TEST_DIR/252.$$ +# Standard punch hole tests _test_generic_punch falloc fpunch fpunch fiemap _filter_fiemap $testfile -F +# Delayed allocation punch hole tests +_test_generic_punch -d falloc fpunch fpunch fiemap _filter_fiemap $testfile -F + +# Multi hole punch tests +_test_generic_punch -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F + +# Delayed allocation multi punch hole tests +_test_generic_punch -d -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F + status=0 ; exit diff --git a/252.out b/252.out index cd8e4b4..930c924 100644 --- a/252.out +++ b/252.out @@ -45,3 +45,195 @@ QA output created by 252 0: [0..7]: data 1: [8..31]: hole 2: [32..39]: data + 14. data -> hole @ EOF +0: [0..23]: data +1: [24..39]: hole + 15. data -> hole @ 0 +0: [0..15]: hole +1: [16..39]: data + 16. data -> cache cold ->hole +0: [0..15]: hole +1: [16..39]: data + 17. data -> hole in single block file +0: [0..7]: data + 1. into a hole + 2. into allocated space +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 3. into unwritten space +0: [0..7]: unwritten +1: [8..23]: hole +2: [24..39]: unwritten + 4. hole -> data +0: [0..23]: hole +1: [24..31]: data +2: [32..39]: hole + 5. hole -> unwritten +0: [0..23]: hole +1: [24..31]: unwritten +2: [32..39]: hole + 6. data -> hole +0: [0..7]: data +1: [8..39]: hole + 7. data -> unwritten +0: [0..7]: data +1: [8..23]: hole +2: [24..31]: unwritten +3: [32..39]: hole + 8. unwritten -> hole +0: [0..7]: unwritten +1: [8..39]: hole + 9. unwritten -> data +0: [0..7]: unwritten +1: [8..23]: hole +2: [24..31]: data +3: [32..39]: hole + 10. hole -> data -> hole + 11. data -> hole -> data +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 12. unwritten -> data -> unwritten +0: [0..7]: unwritten +1: [8..31]: hole +2: [32..39]: unwritten + 13. data -> unwritten -> data +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 14. data -> hole @ EOF +0: [0..23]: data +1: [24..39]: hole + 15. data -> hole @ 0 +0: [0..15]: hole +1: [16..39]: data + 16. data -> cache cold ->hole +0: [0..15]: hole +1: [16..39]: data + 17. data -> hole in single block file +0: [0..7]: data + 1. into a hole +0: [0..7]: data +1: [8..39]: hole + 2. into allocated space +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 3. into unwritten space +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 4. hole -> data +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 5. hole -> unwritten +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 6. data -> hole +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 7. data -> unwritten +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 8. unwritten -> hole +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 9. unwritten -> data +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 10. hole -> data -> hole +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 11. data -> hole -> data +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 12. unwritten -> data -> unwritten +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 13. data -> unwritten -> data +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 14. data -> hole @ EOF +0: [0..23]: data +1: [24..39]: hole + 15. data -> hole @ 0 +0: [0..15]: hole +1: [16..39]: data + 16. data -> cache cold ->hole +0: [0..15]: hole +1: [16..39]: data + 17. data -> hole in single block file +0: [0..7]: data + 1. into a hole +0: [0..7]: data +1: [8..39]: hole + 2. into allocated space +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 3. into unwritten space +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 4. hole -> data +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 5. hole -> unwritten +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 6. data -> hole +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 7. data -> unwritten +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 8. unwritten -> hole +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 9. unwritten -> data +0: [0..7]: data +1: [8..23]: hole +2: [24..39]: data + 10. hole -> data -> hole +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 11. data -> hole -> data +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 12. unwritten -> data -> unwritten +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 13. data -> unwritten -> data +0: [0..7]: data +1: [8..31]: hole +2: [32..39]: data + 14. data -> hole @ EOF +0: [0..23]: data +1: [24..39]: hole + 15. data -> hole @ 0 +0: [0..15]: hole +1: [16..39]: data + 16. data -> cache cold ->hole +0: [0..15]: hole +1: [16..39]: data + 17. data -> hole in single block file +0: [0..7]: data diff --git a/common.punch b/common.punch index e2da5d8..ddf63b0 100644 --- a/common.punch +++ b/common.punch @@ -256,8 +256,39 @@ die_now() # 11. data -> hole -> data # 12. unwritten -> data -> unwritten # 13. data -> unwritten -> data +# 14. data -> hole @ EOF +# 15. data -> hole @ 0 +# 16. data -> cache cold ->hole +# 17. data -> hole in single block file +# +# Test file is removed, created and sync'd between tests. +# +# Use -k flag to keep the file between tests. This will +# test the handling of pre-existing holes. +# +# Use the -d flag to not sync the file between tests. +# This will test the handling of delayed extents +# _test_generic_punch() { + + remove_testfile=1 + sync_cmd="-c fsync" + OPTIND=1 + while getopts 'dk' OPTION + do + case $OPTION in + k) remove_testfile= + ;; + d) sync_cmd= + ;; + ?) echo Invalid flag + exit 1 + ;; + esac + done + shift $(($OPTIND - 1)) + alloc_cmd=$1 punch_cmd=$2 zero_cmd=$3 #if not testing zero just set to punch @@ -267,22 +298,28 @@ _test_generic_punch() xfs_io_opt=$7 #needs to be -F if not testing xfs echo " 1. into a hole" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$zero_cmd 4k 8k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 2. into allocated space" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ - -c "pwrite 0 20k" -c "fsync" \ + -c "pwrite 0 20k" $sync_cmd \ -c "$zero_cmd 4k 8k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 3. into unwritten space" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 20k" \ -c "$zero_cmd 4k 8k" \ @@ -290,15 +327,19 @@ _test_generic_punch() [ $? -ne 0 ] && die_now echo " 4. hole -> data" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ - -c "pwrite 8k 8k" -c "fsync" \ + -c "pwrite 8k 8k" $sync_cmd \ -c "$zero_cmd 4k 8k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 5. hole -> unwritten" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 8k 8k" \ -c "$zero_cmd 4k 8k" \ @@ -306,24 +347,30 @@ _test_generic_punch() [ $? -ne 0 ] && die_now echo " 6. data -> hole" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ - -c "pwrite 0 8k" -c "fsync" \ + -c "pwrite 0 8k" $sync_cmd \ -c "$zero_cmd 4k 8k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 7. data -> unwritten" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ - -c "pwrite 0 8k" -c "fsync" \ + -c "pwrite 0 8k" $sync_cmd \ -c "$alloc_cmd 8k 8k" \ -c "$zero_cmd 4k 8k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 8. unwritten -> hole" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 8k" \ -c "$zero_cmd 4k 8k" \ @@ -331,49 +378,108 @@ _test_generic_punch() [ $? -ne 0 ] && die_now echo " 9. unwritten -> data" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 8k" \ - -c "pwrite 8k 8k" -c "fsync" \ + -c "pwrite 8k 8k" $sync_cmd \ -c "$zero_cmd 4k 8k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 10. hole -> data -> hole" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ - -c "pwrite 8k 4k" -c "fsync" \ + -c "pwrite 8k 4k" $sync_cmd \ -c "$zero_cmd 4k 12k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 11. data -> hole -> data" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 20k" \ -c "pwrite 0 8k" \ - -c "pwrite 12k 8k" -c "fsync" \ + -c "pwrite 12k 8k" $sync_cmd \ -c "$punch_cmd 8k 4k" \ -c "$zero_cmd 4k 12k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 12. unwritten -> data -> unwritten" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 20k" \ - -c "pwrite 8k 4k" -c "fsync" \ + -c "pwrite 8k 4k" $sync_cmd \ -c "$zero_cmd 4k 12k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now echo " 13. data -> unwritten -> data" - rm -f $testfile + if [ "$remove_testfile" ]; then + rm -f $testfile + fi $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ -c "$alloc_cmd 0 20k" \ - -c "pwrite 0k 8k" -c "fsync" \ + -c "pwrite 0k 8k" $sync_cmd \ -c "pwrite 12k 8k" -c "fsync" \ -c "$zero_cmd 4k 12k" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now + + echo " 14. data -> hole @ EOF" + rm -f $testfile + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ + -c "pwrite 0 20k" $sync_cmd \ + -c "$zero_cmd 12k 8k" \ + -c "$map_cmd -v" $testfile | $filter_cmd + [ $? -ne 0 ] && die_now + + echo " 15. data -> hole @ 0" + if [ "$remove_testfile" ]; then + rm -f $testfile + fi + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ + -c "pwrite 0 20k" $sync_cmd \ + -c "$zero_cmd 0k 8k" \ + -c "$map_cmd -v" $testfile | $filter_cmd + [ $? -ne 0 ] && die_now + + echo " 16. data -> cache cold ->hole" + if [ "$remove_testfile" ]; then + rm -f $testfile + rm -f $testfile.2 + else + cp $testfile $testfile.2 + fi + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ + -c "pwrite 8k 12k" -c "fsync" $testfile.2 \ + > /dev/null + $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \ + -c "pwrite 0 20k" $sync_cmd \ + -c "$zero_cmd 0k 8k" \ + -c "fadvise -d" \ + -c "$map_cmd -v" $testfile | $filter_cmd + diff $testfile $testfile.2 + [ $? -ne 0 ] && die_now + rm -f $testfile.2 + + echo " 17. data -> hole in single block file" + if [ "$remove_testfile" ]; then + rm -f $testfile + fi + block_size=`stat -f $TEST_DEV | grep "Block size" | cut -d " " -f3` + $XFS_IO_PROG $xfs_io_opt -f -c "truncate $block_size" \ + -c "pwrite 0 $block_size" $sync_cmd \ + -c "$zero_cmd 128 128" \ + -c "$map_cmd -v" $testfile | $filter_cmd + [ $? -ne 0 ] && die_now + } -- 1.7.1 From achender@vnet.ibm.com Mon Jun 6 18:34:32 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_65 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p56NYWSt256273 for ; Mon, 6 Jun 2011 18:34:32 -0500 X-ASG-Debug-ID: 1307403271-730a03070000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e6.ny.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 42D154A3E22 for ; Mon, 6 Jun 2011 16:34:31 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by cuda.sgi.com with ESMTP id TJQImIphZRUES3CS for ; Mon, 06 Jun 2011 16:34:31 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p56NAMXl017941 for ; Mon, 6 Jun 2011 19:10:22 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p56NYUbT434300 for ; Mon, 6 Jun 2011 19:34:30 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p56NYUdV009382 for ; Mon, 6 Jun 2011 19:34:30 -0400 Received: from lc4eb0185863151.ibm.com (sig-9-65-175-246.mts.ibm.com [9.65.175.246]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p56NYTlr009368; Mon, 6 Jun 2011 19:34:29 -0400 Message-ID: <4DED6405.7020104@vnet.ibm.com> Date: Mon, 06 Jun 2011 16:34:29 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: [PATCH 3/3 v5] XFS TESTS: Add ENOSPC Hole Punch Test Subject: [PATCH 3/3 v5] XFS TESTS: Add ENOSPC Hole Punch Test Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e6.ny.us.ibm.com[32.97.182.146] X-Barracuda-Start-Time: 1307403272 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This patch adds a test to 252 that tests that a hole can be punched even when the disk is full. Reserved blocks should be used to allow a punch hole to proceed even when there is not enough blocks to further fragment the file. To test this, the file system is fragmented by punching holes in regular intervals and filling the file system between punches. This will eventually force the file system to use reserved blocks to proceed with the punch hole operation. Signed-off-by: Allison Henderson --- :100755 100755 5efa243... b5204fe... M 252 :100644 100644 ddf63b0... fc6123c... M common.punch 252 | 12 +++++++ common.punch | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 107 insertions(+), 0 deletions(-) diff --git a/252 b/252 index 5efa243..b5204fe 100755 --- a/252 +++ b/252 @@ -49,6 +49,7 @@ _supported_os Linux _require_xfs_io_falloc_punch _require_xfs_io_fiemap +_require_scratch testfile=$TEST_DIR/252.$$ @@ -64,4 +65,15 @@ _test_generic_punch -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F # Delayed allocation multi punch hole tests _test_generic_punch -d -k falloc fpunch fpunch fiemap _filter_fiemap $testfile -F +# Test full filesystem hole punching. +# Make a small file system to fill +umount $SCRATCH_DEV &> /dev/null +_scratch_mkfs_sized $(( 1024 * 1024 * 1024 )) &> /dev/null +_scratch_mount +# Test must be able to write files with non-root permissions +chmod 777 $SCRATCH_MNT + +block_size=`stat -f $SCRATCH_DEV | grep "Block size" | cut -d " " -f3` +_test_full_fs_punch $(( $block_size * 2 )) $block_size 500 $SCRATCH_MNT/252.$$ + status=0 ; exit diff --git a/common.punch b/common.punch index ddf63b0..fc6123c 100644 --- a/common.punch +++ b/common.punch @@ -481,5 +481,100 @@ _test_generic_punch() -c "$zero_cmd 128 128" \ -c "$map_cmd -v" $testfile | $filter_cmd [ $? -ne 0 ] && die_now +} + +# _fill_fs() +# +# Fills a file system by repeatedly creating files in the given folder +# starting with the given file size. Files are reduced in size when +# they can no longer fit untill no more files can be created. +# +# This routine is used by _test_full_fs_punch to test that a hole may +# still be punched when the disk is full by borrowing reserved blocks. +# All files are created as a non root user to prevent reserved blocks +# from being consumed. +# +_fill_fs() { + local file_size=$1 + local dir=$2 + local file_count=1 + + if [ $# -ne 2 ] + then + echo "USAGE: $0 filesize dir" + exit 1 + fi + + mkdir -p $dir &> /dev/null + if [[ $? != 0 ]] ; then + return 0 + fi + chmod 777 $dir + + rc=0 + while [ $file_size -gt 0 -a $rc == 0 ] + do + # This part must not be done as root or + # reserved blocks will be consumed + sudo -u nobody $XFS_IO_PROG -F -f -c "pwrite 0 $file_size" $dir/$file_count.bin &> /dev/null + rc=$? + + # If there was no room to make the file, + # and the file size can still be made smaller, + # then divide it in half, and keep going + if [ $file_size -gt 1 -a $rc != 0 ] + then + file_size=$(( $file_size / 2 )) + rc=0 + fi + file_count=$(( $file_count + 1 )) + + done +} +# _test_full_fs_punch() +# +# This function will test that a hole may be punched +# even when the file system is full. Reserved blocks +# should be used to allow a punch hole to proceed even +# when there is not enough blocks to further fragment the +# file. To test this, this function will fragment the file +# system by punching holes in regular intervals and filling +# the file system between punches. +# +_test_full_fs_punch() +{ + hole_len=$1 # The length of the holes to punch + hole_interval=$2 # The interval between the holes + iterations=$3 # The number of holes to punch + file_name=$4 # File to punch holes in + file_len=$(( $(( $hole_len + $hole_interval )) * $iterations )) + path=`dirname $file_name` + hole_offset=0 + + rm -f $file_name &> /dev/null + + $XFS_IO_PROG -F -f -c "pwrite 0 $file_len" \ + -c "fsync" $file_name &> /dev/null + chmod 666 $file_name + + _fill_fs $(( 1024 * 1024 * 1024 )) $path/fill + + for (( i=0; i<$iterations; i++ )) + do + # This part must not be done as root in order to + # test that reserved blocks are used when needed + sudo -u nobody $XFS_IO_PROG -F -f -c "fpunch $hole_offset $hole_len" $file_name + rc=$? + if [[ $? != 0 ]] ; then + echo Punch hole failed + break + fi + + hole_offset=$(( $hole_offset + $hole_len + $hole_interval )) + + _fill_fs $hole_len $path/fill.$i + + done } + -- 1.7.1 From tytso@thunk.org Mon Jun 6 19:44:53 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p570iqEl257375 for ; Mon, 6 Jun 2011 19:44:53 -0500 X-ASG-Debug-ID: 1307407490-3a2303cf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from test.thunk.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3C37615DE865 for ; Mon, 6 Jun 2011 17:44:51 -0700 (PDT) Received: from test.thunk.org (li9-11.members.linode.com [67.18.176.11]) by cuda.sgi.com with ESMTP id 9cvXpG6tdn4A2WiT for ; Mon, 06 Jun 2011 17:44:51 -0700 (PDT) Received: from root (helo=tytso-glaptop) by test.thunk.org with local-esmtp (Exim 4.69) (envelope-from ) id 1QTkPW-0003d8-UM; Tue, 07 Jun 2011 00:44:47 +0000 Received: from tytso by tytso-glaptop with local (Exim 4.71) (envelope-from ) id 1QTkPV-0004G3-SY; Mon, 06 Jun 2011 20:44:45 -0400 Date: Mon, 6 Jun 2011 20:44:45 -0400 From: "Ted Ts'o" To: Allison Henderson Cc: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: Re: [PATCH 1/3 v5] XFS TESTS: Add Punch Hole to FSX Subject: Re: [PATCH 1/3 v5] XFS TESTS: Add Punch Hole to FSX Message-ID: <20110607004445.GG20818@thunk.org> References: <4DED63D1.5010600@vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DED63D1.5010600@vnet.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on test.thunk.org); SAEximRunCond expanded to false X-Barracuda-Connect: li9-11.members.linode.com[67.18.176.11] X-Barracuda-Start-Time: 1307407491 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65692 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Jun 06, 2011 at 04:33:37PM -0700, Allison Henderson wrote: > This patch adds punch hole tests to the fsx stress test. > > Signed-off-by: Allison Henderson > Hey Allison, there are two things you can do that will make life much easier for people to review and apply your patches. First of all, move the version information below to after the "---" line. If you want to keep this information in the git commit log, just move the "---" line after you run the "git format-patch" command. Secondly, run the command "git config format.thread true"; this is the default in newer versions of git, but apparently you're not using a new enough version of git. You can also use "git send-email --thread" if you don't want to set the git configuration variable. The other possibility is that your mailer is stripping the in-reply-to: and references: header, so the mail threading is disappearing. I never used vnet.ibm.com's mailer, so I don't know if it's responsible for stripping mail headers, but I tend not to trust VM or Lotus Notes' standard adherence... fortunately for IBM the CIO's who make the purchasing decisions tend not to know the first thing about Internet Mail Standers or RFC's. :-) - Ted > v1 -> v2: > Corrections to the Makefile have been backed out. > This patch needs to be applied on top of > the "xfstests: clean up fallocate configuration tests" > patch > > The punch hole tests can be disabled with the > -H flag, and will also be disabled if it is > detected that the filesystem does not support > punch hole > > v2 -> v4 > Punch hole tests and functionality tests have been moved > into their own functions. Existing dofallocate routine > has been renamed to do_preallocate. > > v4 -> v5 > The code to test fallocate functionality changed slightly, > so the patch has been updated to apply with out err > --- > :100644 100644 0eebc70... 0683853... M ltp/fsx.c > ltp/fsx.c | 143 ++++++++++++++++++++++++++++++++++++++++++++++++++++-------- > 1 files changed, 124 insertions(+), 19 deletions(-) > > diff --git a/ltp/fsx.c b/ltp/fsx.c > index 0eebc70..0683853 100644 ... From achender@vnet.ibm.com Mon Jun 6 20:41:29 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_21, J_CHICKENPOX_66 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p571fSI4258205 for ; Mon, 6 Jun 2011 20:41:28 -0500 X-ASG-Debug-ID: 1307410888-729d02c50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e36.co.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5ECE24A00FF for ; Mon, 6 Jun 2011 18:41:28 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by cuda.sgi.com with ESMTP id cnGSBygJaM4bi0LJ for ; Mon, 06 Jun 2011 18:41:28 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p571ZWL1007802 for ; Mon, 6 Jun 2011 19:35:32 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p571fNpX361608 for ; Mon, 6 Jun 2011 19:41:24 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p571kcu7001787 for ; Mon, 6 Jun 2011 19:46:38 -0600 Received: from lc4eb0185863151.ibm.com (sig-9-65-175-246.mts.ibm.com [9.65.175.246]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p571ka8M001774; Mon, 6 Jun 2011 19:46:37 -0600 Message-ID: <4DED81C1.6000204@vnet.ibm.com> Date: Mon, 06 Jun 2011 18:41:21 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Ted Ts'o" CC: linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: Re: [PATCH 1/3 v5] XFS TESTS: Add Punch Hole to FSX Subject: Re: [PATCH 1/3 v5] XFS TESTS: Add Punch Hole to FSX References: <4DED63D1.5010600@vnet.ibm.com> <20110607004445.GG20818@thunk.org> In-Reply-To: <20110607004445.GG20818@thunk.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e36.co.us.ibm.com[32.97.110.154] X-Barracuda-Start-Time: 1307410888 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 06/06/2011 05:44 PM, Ted Ts'o wrote: > Hey Allison, there are two things you can do that will make life much > easier for people to review and apply your patches. First of all, > move the version information below to after the "---" line. If you > want to keep this information in the git commit log, just move the > "---" line after you run the "git format-patch" command. > > Secondly, run the command "git config format.thread true"; this is the > default in newer versions of git, but apparently you're not using a > new enough version of git. You can also use "git send-email --thread" > if you don't want to set the git configuration variable. The other > possibility is that your mailer is stripping the in-reply-to: and > references: header, so the mail threading is disappearing. I never > used vnet.ibm.com's mailer, so I don't know if it's responsible for > stripping mail headers, but I tend not to trust VM or Lotus Notes' > standard adherence... fortunately for IBM the CIO's who make the > purchasing decisions tend not to know the first thing about Internet > Mail Standers or RFC's.:-) > > - Ted Thx Ted! I didn't realize the patches were hard for people to read. I will see if I can get those commands to work, and I will make sure the "---" comes before the version info. Initially I had tried the send-email, but not all of the patches seemed to make it to the lists, so I started using Thunderbird, but I will see if I can figure out what went wrong with send-email. Thx! Allison Henderson From kenneth.emerson@gmail.com Mon Jun 6 22:52:53 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p573qqZW001949 for ; Mon, 6 Jun 2011 22:52:53 -0500 X-ASG-Debug-ID: 1307418769-0cd302630000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-bw0-f53.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C428EF67ED5 for ; Mon, 6 Jun 2011 20:52:49 -0700 (PDT) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by cuda.sgi.com with ESMTP id KskKiXHFSCVFIaqx for ; Mon, 06 Jun 2011 20:52:49 -0700 (PDT) Received: by bwg12 with SMTP id 12so4317713bwg.26 for ; Mon, 06 Jun 2011 20:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=hrjVfAudA1TPw8MxB5TIYXOxatafiJHwT5Pe2/tkqEA=; b=p5E3UxfAYuphEy3oz2ucrxWa3a9ctv9vWr3r7dmmZMQ/xrzFu7SSnDzF+cgVNHZeIf 0HeKyDfpdbHZncUWieL8+gi8PSiz4goHX3MPkkFB24xS2j83NbA5m1FIRk8j4dOXRn+v Js/Ml9LdE4tiuYO92TG92Ym7YcFecZt1uX+ew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JSmwS3s29cSf8MLDjfTC4sR3xYfuMvinVyTxsvuLh1mG9+0A7HQJX+lMsmTQ4wT7lM M4ujjSLcc2GZbQH9yPRLJ8qoVAdAq5Hh4Y8kTJZjF+T/kVbghudbFEwi98TmEMbIrKLQ ePcDKqrwclA4SeK9ZZkLcUhUbmaI9GERPI3Xw= MIME-Version: 1.0 Received: by 10.204.62.4 with SMTP id v4mr2661081bkh.169.1307418769022; Mon, 06 Jun 2011 20:52:49 -0700 (PDT) Received: by 10.204.60.196 with HTTP; Mon, 6 Jun 2011 20:52:48 -0700 (PDT) Date: Mon, 6 Jun 2011 22:52:48 -0500 Message-ID: X-ASG-Orig-Subj: Defragging XFS File Systems Subject: Defragging XFS File Systems From: Kenneth Emerson To: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=001636c599114ce14a04a5172759 X-Barracuda-Connect: mail-bw0-f53.google.com[209.85.214.53] X-Barracuda-Start-Time: 1307418770 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0005 1.0000 -2.0181 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65705 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --001636c599114ce14a04a5172759 Content-Type: text/plain; charset=ISO-8859-1 I hadn't given much thought to fragmentation of my TV recordings volume (XFS) until reading through some MythTV-users threads recently that mentioned how fragmented an XFS file system could become. After running xfs_db, I found out that my fs appeared to be quite bad: $ sudo xfs_db -c frag -r /dev/mapper/appl_vg-appl_lv actual 1138668, ideal 11023, fragmentation factor 99.03% I then ran xfs_fsr with all defaults (ran for two hours) and then re-ran xfs_db and got the following results: $ sudo xfs_db -c frag -r /dev/mapper/appl_vg-appl_lv invalid numrecs (27111) in bmapbtd block invalid numrecs (4716) in bmapbtd block invalid numrecs (58978) in bmapbtd block actual 1034793, ideal 11024, fragmentation factor 98.93% The fragmentation level was reduced, but I was concerned about the error messages. Before I go any further, am I corrupting my file system with the defragging or are these "invalid numrecs" messages unimportant? Google didn't offer much help. Regards, Ken E. --001636c599114ce14a04a5172759 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I hadn't given much thought to fragmentation of my TV recordings volume= =20 (XFS) until reading through some MythTV-users threads recently that mention= ed=20 how fragmented an XFS file system could become. =A0After running xfs_db, I found out that my fs appeared to be quite bad:

$ sudo xfs_db -c frag -r /dev/mapper/appl_vg-appl_lv
=A0actual 1138668, ideal 11023, fragmentation factor 99.03%

I then ran xfs_fsr with all defaults (ran for two h= ours) and then re-ran xfs_db and got the following results:

$ sudo xfs_db -c frag -r /dev/mapper/appl_vg-appl_= lv
invalid numrecs (27111) in bmapbtd block
invalid num= recs (4716) in bmapbtd block
invalid numrecs (58978) in bmapbtd b= lock
actual 1034793, ideal 11024, fragmentation factor 98.93%

The fragmentation level was reduced, but I was concerned about the error=20 messages. =A0Before I go any further, am I corrupting my file system with= =20 the defragging or are these "invalid numrecs" messages unimportan= t?

Google didn't offer much help.

=
Regards,

Ken E.
--001636c599114ce14a04a5172759-- From gongfan193@gmail.com Tue Jun 7 00:20:46 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p575Kj9l005746 for ; Tue, 7 Jun 2011 00:20:45 -0500 X-ASG-Debug-ID: 1307424043-0cd503d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-gw0-f53.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8CB6516B5043; Mon, 6 Jun 2011 22:20:43 -0700 (PDT) Received: from mail-gw0-f53.google.com (mail-gw0-f53.google.com [74.125.83.53]) by cuda.sgi.com with ESMTP id 3c4gsLqBFGVZvwGz; Mon, 06 Jun 2011 22:20:43 -0700 (PDT) Received: by gwj20 with SMTP id 20so2228579gwj.26 for ; Mon, 06 Jun 2011 22:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to:cc :content-type; bh=M8oEQsTgWrddUG82QFW+sMMVdT0ghkToc6ReNIGDBoA=; b=av1xO2P2LNg38ruZNHoz6OTPjtzf4duK4eGnmiUYQ1RcwrOzZZ0GlS+39s07WdNonh gnllI/zWBSnndeCs37fKfRaEZ0WFE7F1+F+fsnmJMsO56cYQaVDG9kHAvqy4bS3HcoZb obzG9jo0E46RI7Gx11F3ekDafLV3X6xyMzusU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; b=C8pDYuu3jUXpkev5HIqGYCOZko7yl/+NjxGL883gTcH2kCpJ7D0aaTEA4USYgvmTLU XEVJzwpG/Z22BYSZev5Q9BvMaIykaE/YETz15LW3UVy9/kgbPxh4GyFv6HYnxoqhI9qp nY9dpfw7PzvZJi6rTcmaA82/VBYKuANdqX3vA= Received: by 10.100.24.27 with SMTP id 27mr4348413anx.39.1307424043220; Mon, 06 Jun 2011 22:20:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.198.3 with HTTP; Mon, 6 Jun 2011 22:20:23 -0700 (PDT) From: Drunkard Zhang Date: Tue, 7 Jun 2011 13:20:23 +0800 Message-ID: X-ASG-Orig-Subj: bug in xfs: can't recovery metadata log Subject: bug in xfs: can't recovery metadata log To: Alex Elder , xfs-masters@oss.sgi.com, xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Content-Type: multipart/mixed; boundary=0016e64698baaac01704a518615e X-Barracuda-Connect: mail-gw0-f53.google.com[74.125.83.53] X-Barracuda-Start-Time: 1307424044 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.02 X-Barracuda-Spam-Status: No, SCORE=-1.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, BSF_RULE_7582B, DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65711 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.50 BSF_RULE7568M Custom Rule 7568M 0.50 BSF_RULE_7582B Custom Rule 7582B X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0016e64698baaac01704a518615e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The log recovery failure happened after a hard reboot, I did "mount /dev/lg/log /mnt/temp/" twice, but the similar dmesg error. The xfs lives on LVM, with 4x2TB SATA II disk. The first time: [ 1479.130446] XFS mounting filesystem dm-0 [ 1479.226525] Starting XFS recovery on filesystem: dm-0 (logdev: internal) [ 1506.217842] BUG: unable to handle kernel NULL pointer dereference at 00000000000000f8 [ 1506.218468] IP: [] xfs_cmn_err+0x6b/0x92 [ 1506.218680] PGD 2175c4067 PUD 22f4ff067 PMD 0 [ 1506.218887] Oops: 0000 [#1] PREEMPT SMP [ 1506.219138] last sysfs file: /sys/devices/virtual/block/dm-0/dev [ 1506.219345] CPU 1 [ 1506.219353] Modules linked in: [ 1506.219732] [ 1506.219923] Pid: 21233, comm: mount Not tainted 2.6.38.5 #2 System manufacturer S=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF/Z8NA-D6(C) [ 1506.220989] RIP: 0010:[] [] xfs_cmn_err+0x6b/0x92 [ 1506.221424] RSP: 0018:ffff88021752da08 EFLAGS: 00010246 [ 1506.221627] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff816= be16c [ 1506.221837] RDX: ffff88021752da28 RSI: ffffffff816bdced RDI: 00000000000= 00008 [ 1506.222079] RBP: ffff88021752da88 R08: ffffffff816bdb79 R09: 00000000000= 005f6 [ 1506.222289] R10: ffff8802177c32c0 R11: 00000530e8002000 R12: 00000000000= 00000 [ 1506.222572] R13: ffffffff816be16c R14: ffff88021752db04 R15: 00000000000= 008e2 [ 1506.222830] FS: 00007fa0c93d2740(0000) GS:ffff8800bf440000(0000) knlGS:0000000000000000 [ 1506.223265] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1506.223471] CR2: 00000000000000f8 CR3: 000000021754e000 CR4: 00000000000= 006e0 [ 1506.223728] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000= 00000 [ 1506.223938] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000= 00400 [ 1506.224190] Process mount (pid: 21233, threadinfo ffff88021752c000, task ffff88022e239440) [ 1506.224585] Stack: [ 1506.224776] 0000000000000020 ffff88021752da98 ffff88021752da38 ffff88021752da48 [ 1506.225216] ffffffff816be16c ffff88021752da08 2d0100008de51400 ffffffff8122922b [ 1506.225616] ffff880202000000 ffff8802176e8af0 ffffffff816bdb79 00000000000005f6 [ 1506.226058] Call Trace: [ 1506.226301] [] ? kmem_zone_zalloc+0x1f/0x30 [ 1506.226549] [] xfs_error_report+0x39/0x40 [ 1506.226805] [] ? xfs_free_extent+0x8e/0xae [ 1506.227056] [] xfs_free_ag_extent+0x3e7/0x70b [ 1506.227306] [] xfs_free_extent+0x8e/0xae [ 1506.227514] [] xlog_recover_process_efi+0x113/0x16c [ 1506.227724] [] ? xfs_trans_ail_cursor_set+0x15/0x1c [ 1506.227934] [] xlog_recover_process_efis+0x64/0xad [ 1506.228182] [] xlog_recover_finish+0x15/0xb6 [ 1506.228390] [] xfs_log_mount_finish+0x1b/0x1d [ 1506.228597] [] xfs_mountfs+0x4ec/0x615 [ 1506.228803] [] xfs_fs_fill_super+0x1e5/0x2e8 [ 1506.229055] [] mount_bdev+0x13b/0x19e [ 1506.229259] [] ? xfs_fs_fill_super+0x0/0x2e8 [ 1506.229467] [] xfs_fs_mount+0x10/0x12 [ 1506.229672] [] vfs_kern_mount+0xb8/0x1f3 [ 1506.229877] [] do_kern_mount+0x48/0xd8 [ 1506.230127] [] do_mount+0x729/0x791 [ 1506.230375] [] ? memdup_user+0x43/0x63 [ 1506.230629] [] ? strndup_user+0x39/0x4f [ 1506.230834] [] sys_mount+0x83/0xbe [ 1506.231080] [] system_call_fastpath+0x16/0x1b [ 1506.231285] Code: 31 e4 48 8d 45 80 48 8d 55 10 48 89 45 a8 48 89 55 88 31 c0 48 8d 55 b0 c7 45 80 20 00 00 00 48 89 55 90 4c 89 6d a0 48 8d 55 a0 <48> 8b b3 f8 00 00 00 48 c7 c7 78 14 6c 81 e8 1f ff 2b 00 45 85 [ 1506.232093] RIP [] xfs_cmn_err+0x6b/0x92 [ 1506.232300] RSP [ 1506.232498] CR2: 00000000000000f8 [ 1506.233086] ---[ end trace 6ff9d0214348600a ]--- The second time: [ 725.637712] BUG: unable to handle kernel NULL pointer dereference at 00000000000000f8 [ 725.638302] IP: [] xfs_cmn_err+0x6b/0x92 [ 725.638579] PGD 22b1d3067 PUD 22b21f067 PMD 0 [ 725.638787] Oops: 0000 [#1] PREEMPT SMP [ 725.638993] last sysfs file: /sys/devices/virtual/block/dm-0/dev [ 725.639202] CPU 0 [ 725.639210] Modules linked in: [ 725.639664] [ 725.639857] Pid: 2537, comm: mount Not tainted 2.6.38.5 #2 System manufacturer S=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF/Z8NA-D6(C) [ 725.640841] RIP: 0010:[] [] xfs_cmn_err+0x6b/0x92 [ 725.641241] RSP: 0018:ffff88022b28ba08 EFLAGS: 00010246 [ 725.641512] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff816= be16c [ 725.641723] RDX: ffff88022b28ba28 RSI: ffffffff816bdced RDI: 00000000000= 00008 [ 725.641936] RBP: ffff88022b28ba88 R08: ffffffff816bdb79 R09: 00000000000= 005f6 [ 725.642148] R10: ffff8802217c9680 R11: 00000530e8002000 R12: 00000000000= 00000 [ 725.642428] R13: ffffffff816be16c R14: ffff88022b28bb04 R15: 00000000000= 008e2 [ 725.642641] FS: 00007f857cd34740(0000) GS:ffff8800bf400000(0000) knlGS:0000000000000000 [ 725.643041] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 725.643248] CR2: 00000000000000f8 CR3: 000000022b24a000 CR4: 00000000000= 006f0 [ 725.643565] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000= 00000 [ 725.643778] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000= 00400 [ 725.643990] Process mount (pid: 2537, threadinfo ffff88022b28a000, task ffff88022e4f2f40) [ 725.644478] Stack: [ 725.644671] 0000000000000020 ffff88022b28ba98 ffff88022b28ba38 ffff88022b28ba48 [ 725.645072] ffffffff816be16c ffff88022b28ba08 2d0100008de51400 ffffffff8122922b [ 725.645607] ffff880202000000 ffff88022b2d28c0 ffffffff816bdb79 00000000000005f6 [ 725.646010] Call Trace: [ 725.646211] [] ? kmem_zone_zalloc+0x1f/0x30 [ 725.646491] [] xfs_error_report+0x39/0x40 [ 725.646700] [] ? xfs_free_extent+0x8e/0xae [ 725.646909] [] xfs_free_ag_extent+0x3e7/0x70b [ 725.647119] [] xfs_free_extent+0x8e/0xae [ 725.647329] [] xlog_recover_process_efi+0x113/0x16c [ 725.647632] [] ? xfs_trans_ail_cursor_set+0x15/0x1c [ 725.647844] [] xlog_recover_process_efis+0x64/0xad [ 725.648056] [] xlog_recover_finish+0x15/0xb6 [ 725.648266] [] xfs_log_mount_finish+0x1b/0x1d [ 725.648539] [] xfs_mountfs+0x4ec/0x615 [ 725.648747] [] xfs_fs_fill_super+0x1e5/0x2e8 [ 725.648958] [] mount_bdev+0x13b/0x19e [ 725.649164] [] ? xfs_fs_fill_super+0x0/0x2e8 [ 725.649438] [] xfs_fs_mount+0x10/0x12 [ 725.649646] [] vfs_kern_mount+0xb8/0x1f3 [ 725.649854] [] do_kern_mount+0x48/0xd8 [ 725.650063] [] do_mount+0x729/0x791 [ 725.650271] [] ? memdup_user+0x43/0x63 [ 725.650545] [] ? strndup_user+0x39/0x4f [ 725.650753] [] sys_mount+0x83/0xbe [ 725.650961] [] system_call_fastpath+0x16/0x1b [ 725.651169] Code: 31 e4 48 8d 45 80 48 8d 55 10 48 89 45 a8 48 89 55 88 31 c0 48 8d 55 b0 c7 45 80 20 00 00 00 48 89 55 90 4c 89 6d a0 48 8d 55 a0 <48> 8b b3 f8 00 00 00 48 c7 c7 78 14 6c 81 e8 1f ff 2b 00 45 85 [ 725.652012] RIP [] xfs_cmn_err+0x6b/0x92 [ 725.652221] RSP [ 725.652484] CR2: 00000000000000f8 [ 725.653295] ---[ end trace 1dadc2ff14d7c60f ]--- --0016e64698baaac01704a518615e Content-Type: application/octet-stream; name="config-2.6.38.5" Content-Disposition: attachment; filename="config-2.6.38.5" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gomecptk0 IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIG1ha2UgY29uZmlnOiBkb24ndCBlZGl0CiMgTGlu dXgveDg2XzY0IDIuNi4zOC41IEtlcm5lbCBDb25maWd1cmF0aW9uCiMgVGh1IE1heSAgNSAxMzoz NTo0NSAyMDExCiMKQ09ORklHXzY0QklUPXkKIyBDT05GSUdfWDg2XzMyIGlzIG5vdCBzZXQKQ09O RklHX1g4Nl82ND15CkNPTkZJR19YODY9eQpDT05GSUdfSU5TVFJVQ1RJT05fREVDT0RFUj15CkNP TkZJR19PVVRQVVRfRk9STUFUPSJlbGY2NC14ODYtNjQiCkNPTkZJR19BUkNIX0RFRkNPTkZJRz0i YXJjaC94ODYvY29uZmlncy94ODZfNjRfZGVmY29uZmlnIgpDT05GSUdfR0VORVJJQ19DTU9TX1VQ REFURT15CkNPTkZJR19DTE9DS1NPVVJDRV9XQVRDSERPRz15CkNPTkZJR19HRU5FUklDX0NMT0NL RVZFTlRTPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNfQlJPQURDQVNUPXkKQ09ORklHX0xP Q0tERVBfU1VQUE9SVD15CkNPTkZJR19TVEFDS1RSQUNFX1NVUFBPUlQ9eQpDT05GSUdfSEFWRV9M QVRFTkNZVE9QX1NVUFBPUlQ9eQpDT05GSUdfTU1VPXkKQ09ORklHX1pPTkVfRE1BPXkKQ09ORklH X05FRURfRE1BX01BUF9TVEFURT15CkNPTkZJR19ORUVEX1NHX0RNQV9MRU5HVEg9eQpDT05GSUdf R0VORVJJQ19JU0FfRE1BPXkKQ09ORklHX0dFTkVSSUNfSU9NQVA9eQpDT05GSUdfR0VORVJJQ19C VUc9eQpDT05GSUdfR0VORVJJQ19CVUdfUkVMQVRJVkVfUE9JTlRFUlM9eQpDT05GSUdfR0VORVJJ Q19IV0VJR0hUPXkKQ09ORklHX0FSQ0hfTUFZX0hBVkVfUENfRkRDPXkKIyBDT05GSUdfUldTRU1f R0VORVJJQ19TUElOTE9DSyBpcyBub3Qgc2V0CkNPTkZJR19SV1NFTV9YQ0hHQUREX0FMR09SSVRI TT15CkNPTkZJR19BUkNIX0hBU19DUFVfSURMRV9XQUlUPXkKQ09ORklHX0dFTkVSSUNfQ0FMSUJS QVRFX0RFTEFZPXkKQ09ORklHX0dFTkVSSUNfVElNRV9WU1lTQ0FMTD15CkNPTkZJR19BUkNIX0hB U19DUFVfUkVMQVg9eQpDT05GSUdfQVJDSF9IQVNfREVGQVVMVF9JRExFPXkKQ09ORklHX0FSQ0hf SEFTX0NBQ0hFX0xJTkVfU0laRT15CkNPTkZJR19IQVZFX1NFVFVQX1BFUl9DUFVfQVJFQT15CkNP TkZJR19ORUVEX1BFUl9DUFVfRU1CRURfRklSU1RfQ0hVTks9eQpDT05GSUdfTkVFRF9QRVJfQ1BV X1BBR0VfRklSU1RfQ0hVTks9eQpDT05GSUdfSEFWRV9DUFVNQVNLX09GX0NQVV9NQVA9eQpDT05G SUdfQVJDSF9ISUJFUk5BVElPTl9QT1NTSUJMRT15CkNPTkZJR19BUkNIX1NVU1BFTkRfUE9TU0lC TEU9eQpDT05GSUdfWk9ORV9ETUEzMj15CkNPTkZJR19BUkNIX1BPUFVMQVRFU19OT0RFX01BUD15 CkNPTkZJR19BVURJVF9BUkNIPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfT1BUSU1JWkVEX0lOTElO SU5HPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfREVCVUdfUEFHRUFMTE9DPXkKQ09ORklHX0hBVkVf SU5URUxfVFhUPXkKQ09ORklHX1g4Nl82NF9TTVA9eQpDT05GSUdfWDg2X0hUPXkKQ09ORklHX1g4 Nl9UUkFNUE9MSU5FPXkKQ09ORklHX0FSQ0hfSFdFSUdIVF9DRkxBR1M9Ii1mY2FsbC1zYXZlZC1y ZGkgLWZjYWxsLXNhdmVkLXJzaSAtZmNhbGwtc2F2ZWQtcmR4IC1mY2FsbC1zYXZlZC1yY3ggLWZj YWxsLXNhdmVkLXI4IC1mY2FsbC1zYXZlZC1yOSAtZmNhbGwtc2F2ZWQtcjEwIC1mY2FsbC1zYXZl ZC1yMTEiCiMgQ09ORklHX0tUSU1FX1NDQUxBUiBpcyBub3Qgc2V0CkNPTkZJR19BUkNIX0NQVV9Q Uk9CRV9SRUxFQVNFPXkKQ09ORklHX0RFRkNPTkZJR19MSVNUPSIvbGliL21vZHVsZXMvJFVOQU1F X1JFTEVBU0UvLmNvbmZpZyIKQ09ORklHX0NPTlNUUlVDVE9SUz15CkNPTkZJR19IQVZFX0lSUV9X T1JLPXkKQ09ORklHX0lSUV9XT1JLPXkKCiMKIyBHZW5lcmFsIHNldHVwCiMKQ09ORklHX0VYUEVS SU1FTlRBTD15CkNPTkZJR19JTklUX0VOVl9BUkdfTElNSVQ9MzIKQ09ORklHX0NST1NTX0NPTVBJ TEU9IiIKQ09ORklHX0xPQ0FMVkVSU0lPTj0iIgojIENPTkZJR19MT0NBTFZFUlNJT05fQVVUTyBp cyBub3Qgc2V0CkNPTkZJR19IQVZFX0tFUk5FTF9HWklQPXkKQ09ORklHX0hBVkVfS0VSTkVMX0Ja SVAyPXkKQ09ORklHX0hBVkVfS0VSTkVMX0xaTUE9eQpDT05GSUdfSEFWRV9LRVJORUxfWFo9eQpD T05GSUdfSEFWRV9LRVJORUxfTFpPPXkKQ09ORklHX0tFUk5FTF9HWklQPXkKIyBDT05GSUdfS0VS TkVMX0JaSVAyIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VSTkVMX0xaTUEgaXMgbm90IHNldAojIENP TkZJR19LRVJORUxfWFogaXMgbm90IHNldAojIENPTkZJR19LRVJORUxfTFpPIGlzIG5vdCBzZXQK Q09ORklHX1NXQVA9eQpDT05GSUdfU1lTVklQQz15CkNPTkZJR19TWVNWSVBDX1NZU0NUTD15CkNP TkZJR19QT1NJWF9NUVVFVUU9eQpDT05GSUdfUE9TSVhfTVFVRVVFX1NZU0NUTD15CkNPTkZJR19C U0RfUFJPQ0VTU19BQ0NUPXkKQ09ORklHX0JTRF9QUk9DRVNTX0FDQ1RfVjM9eQpDT05GSUdfVEFT S1NUQVRTPXkKQ09ORklHX1RBU0tfREVMQVlfQUNDVD15CkNPTkZJR19UQVNLX1hBQ0NUPXkKQ09O RklHX1RBU0tfSU9fQUNDT1VOVElORz15CkNPTkZJR19BVURJVD15CkNPTkZJR19BVURJVFNZU0NB TEw9eQpDT05GSUdfQVVESVRfV0FUQ0g9eQpDT05GSUdfQVVESVRfVFJFRT15CkNPTkZJR19IQVZF X0dFTkVSSUNfSEFSRElSUVM9eQoKIwojIElSUSBzdWJzeXN0ZW0KIwpDT05GSUdfR0VORVJJQ19I QVJESVJRUz15CiMgQ09ORklHX0dFTkVSSUNfSEFSRElSUVNfTk9fREVQUkVDQVRFRCBpcyBub3Qg c2V0CkNPTkZJR19IQVZFX1NQQVJTRV9JUlE9eQpDT05GSUdfR0VORVJJQ19JUlFfUFJPQkU9eQpD T05GSUdfR0VORVJJQ19QRU5ESU5HX0lSUT15CiMgQ09ORklHX0FVVE9fSVJRX0FGRklOSVRZIGlz IG5vdCBzZXQKIyBDT05GSUdfSVJRX1BFUl9DUFUgaXMgbm90IHNldAojIENPTkZJR19IQVJESVJR U19TV19SRVNFTkQgaXMgbm90IHNldApDT05GSUdfU1BBUlNFX0lSUT15CgojCiMgUkNVIFN1YnN5 c3RlbQojCkNPTkZJR19UUkVFX1BSRUVNUFRfUkNVPXkKQ09ORklHX1BSRUVNUFRfUkNVPXkKIyBD T05GSUdfUkNVX1RSQUNFIGlzIG5vdCBzZXQKQ09ORklHX1JDVV9GQU5PVVQ9NjQKIyBDT05GSUdf UkNVX0ZBTk9VVF9FWEFDVCBpcyBub3Qgc2V0CiMgQ09ORklHX1RSRUVfUkNVX1RSQUNFIGlzIG5v dCBzZXQKQ09ORklHX0lLQ09ORklHPXkKQ09ORklHX0lLQ09ORklHX1BST0M9eQpDT05GSUdfTE9H X0JVRl9TSElGVD0xNwpDT05GSUdfSEFWRV9VTlNUQUJMRV9TQ0hFRF9DTE9DSz15CkNPTkZJR19D R1JPVVBTPXkKIyBDT05GSUdfQ0dST1VQX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0NHUk9VUF9O Uz15CkNPTkZJR19DR1JPVVBfRlJFRVpFUj15CkNPTkZJR19DR1JPVVBfREVWSUNFPXkKQ09ORklH X0NQVVNFVFM9eQpDT05GSUdfUFJPQ19QSURfQ1BVU0VUPXkKQ09ORklHX0NHUk9VUF9DUFVBQ0NU PXkKQ09ORklHX1JFU09VUkNFX0NPVU5URVJTPXkKQ09ORklHX0NHUk9VUF9NRU1fUkVTX0NUTFI9 eQpDT05GSUdfQ0dST1VQX01FTV9SRVNfQ1RMUl9TV0FQPXkKQ09ORklHX0NHUk9VUF9NRU1fUkVT X0NUTFJfU1dBUF9FTkFCTEVEPXkKQ09ORklHX0NHUk9VUF9TQ0hFRD15CkNPTkZJR19GQUlSX0dS T1VQX1NDSEVEPXkKQ09ORklHX1JUX0dST1VQX1NDSEVEPXkKQ09ORklHX0JMS19DR1JPVVA9eQoj IENPTkZJR19ERUJVR19CTEtfQ0dST1VQIGlzIG5vdCBzZXQKQ09ORklHX05BTUVTUEFDRVM9eQpD T05GSUdfVVRTX05TPXkKQ09ORklHX0lQQ19OUz15CkNPTkZJR19VU0VSX05TPXkKQ09ORklHX1BJ RF9OUz15CkNPTkZJR19ORVRfTlM9eQpDT05GSUdfU0NIRURfQVVUT0dST1VQPXkKQ09ORklHX01N X09XTkVSPXkKIyBDT05GSUdfU1lTRlNfREVQUkVDQVRFRCBpcyBub3Qgc2V0CkNPTkZJR19SRUxB WT15CiMgQ09ORklHX0JMS19ERVZfSU5JVFJEIGlzIG5vdCBzZXQKQ09ORklHX0NDX09QVElNSVpF X0ZPUl9TSVpFPXkKQ09ORklHX1NZU0NUTD15CkNPTkZJR19BTk9OX0lOT0RFUz15CiMgQ09ORklH X0VYUEVSVCBpcyBub3Qgc2V0CiMgQ09ORklHX0VNQkVEREVEIGlzIG5vdCBzZXQKQ09ORklHX1VJ RDE2PXkKQ09ORklHX1NZU0NUTF9TWVNDQUxMPXkKQ09ORklHX0tBTExTWU1TPXkKQ09ORklHX0tB TExTWU1TX0VYVFJBX1BBU1M9eQpDT05GSUdfSE9UUExVRz15CkNPTkZJR19QUklOVEs9eQpDT05G SUdfQlVHPXkKQ09ORklHX0VMRl9DT1JFPXkKQ09ORklHX1BDU1BLUl9QTEFURk9STT15CkNPTkZJ R19CQVNFX0ZVTEw9eQpDT05GSUdfRlVURVg9eQpDT05GSUdfRVBPTEw9eQpDT05GSUdfU0lHTkFM RkQ9eQpDT05GSUdfVElNRVJGRD15CkNPTkZJR19FVkVOVEZEPXkKQ09ORklHX1NITUVNPXkKQ09O RklHX0FJTz15CkNPTkZJR19IQVZFX1BFUkZfRVZFTlRTPXkKCiMKIyBLZXJuZWwgUGVyZm9ybWFu Y2UgRXZlbnRzIEFuZCBDb3VudGVycwojCkNPTkZJR19QRVJGX0VWRU5UUz15CiMgQ09ORklHX1BF UkZfQ09VTlRFUlMgaXMgbm90IHNldApDT05GSUdfVk1fRVZFTlRfQ09VTlRFUlM9eQpDT05GSUdf UENJX1FVSVJLUz15CkNPTkZJR19TTFVCX0RFQlVHPXkKIyBDT05GSUdfQ09NUEFUX0JSSyBpcyBu b3Qgc2V0CiMgQ09ORklHX1NMQUIgaXMgbm90IHNldApDT05GSUdfU0xVQj15CkNPTkZJR19QUk9G SUxJTkc9eQpDT05GSUdfVFJBQ0VQT0lOVFM9eQpDT05GSUdfT1BST0ZJTEU9bQojIENPTkZJR19P UFJPRklMRV9FVkVOVF9NVUxUSVBMRVggaXMgbm90IHNldApDT05GSUdfSEFWRV9PUFJPRklMRT15 CkNPTkZJR19LUFJPQkVTPXkKIyBDT05GSUdfSlVNUF9MQUJFTCBpcyBub3Qgc2V0CkNPTkZJR19I QVZFX0VGRklDSUVOVF9VTkFMSUdORURfQUNDRVNTPXkKQ09ORklHX0tSRVRQUk9CRVM9eQpDT05G SUdfSEFWRV9JT1JFTUFQX1BST1Q9eQpDT05GSUdfSEFWRV9LUFJPQkVTPXkKQ09ORklHX0hBVkVf S1JFVFBST0JFUz15CkNPTkZJR19IQVZFX09QVFBST0JFUz15CkNPTkZJR19IQVZFX0FSQ0hfVFJB Q0VIT09LPXkKQ09ORklHX0hBVkVfRE1BX0FUVFJTPXkKQ09ORklHX1VTRV9HRU5FUklDX1NNUF9I RUxQRVJTPXkKQ09ORklHX0hBVkVfUkVHU19BTkRfU1RBQ0tfQUNDRVNTX0FQST15CkNPTkZJR19I QVZFX0RNQV9BUElfREVCVUc9eQpDT05GSUdfSEFWRV9IV19CUkVBS1BPSU5UPXkKQ09ORklHX0hB VkVfTUlYRURfQlJFQUtQT0lOVFNfUkVHUz15CkNPTkZJR19IQVZFX1VTRVJfUkVUVVJOX05PVElG SUVSPXkKQ09ORklHX0hBVkVfUEVSRl9FVkVOVFNfTk1JPXkKQ09ORklHX0hBVkVfQVJDSF9KVU1Q X0xBQkVMPXkKCiMKIyBHQ09WLWJhc2VkIGtlcm5lbCBwcm9maWxpbmcKIwojIENPTkZJR19HQ09W X0tFUk5FTCBpcyBub3Qgc2V0CiMgQ09ORklHX0hBVkVfR0VORVJJQ19ETUFfQ09IRVJFTlQgaXMg bm90IHNldApDT05GSUdfU0xBQklORk89eQpDT05GSUdfUlRfTVVURVhFUz15CkNPTkZJR19CQVNF X1NNQUxMPTAKQ09ORklHX01PRFVMRVM9eQojIENPTkZJR19NT0RVTEVfRk9SQ0VfTE9BRCBpcyBu b3Qgc2V0CkNPTkZJR19NT0RVTEVfVU5MT0FEPXkKQ09ORklHX01PRFVMRV9GT1JDRV9VTkxPQUQ9 eQojIENPTkZJR19NT0RWRVJTSU9OUyBpcyBub3Qgc2V0CkNPTkZJR19NT0RVTEVfU1JDVkVSU0lP Tl9BTEw9eQpDT05GSUdfU1RPUF9NQUNISU5FPXkKQ09ORklHX0JMT0NLPXkKQ09ORklHX0JMS19E RVZfQlNHPXkKQ09ORklHX0JMS19ERVZfSU5URUdSSVRZPXkKQ09ORklHX0JMS19ERVZfVEhST1RU TElORz15CkNPTkZJR19CTE9DS19DT01QQVQ9eQoKIwojIElPIFNjaGVkdWxlcnMKIwpDT05GSUdf SU9TQ0hFRF9OT09QPXkKQ09ORklHX0lPU0NIRURfREVBRExJTkU9eQpDT05GSUdfSU9TQ0hFRF9D RlE9eQpDT05GSUdfQ0ZRX0dST1VQX0lPU0NIRUQ9eQpDT05GSUdfREVGQVVMVF9ERUFETElORT15 CiMgQ09ORklHX0RFRkFVTFRfQ0ZRIGlzIG5vdCBzZXQKIyBDT05GSUdfREVGQVVMVF9OT09QIGlz IG5vdCBzZXQKQ09ORklHX0RFRkFVTFRfSU9TQ0hFRD0iZGVhZGxpbmUiCiMgQ09ORklHX0lOTElO RV9TUElOX1RSWUxPQ0sgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9UUllMT0NLX0JI IGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1NQSU5fTE9DSyBpcyBub3Qgc2V0CiMgQ09ORklH X0lOTElORV9TUElOX0xPQ0tfQkggaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9MT0NL X0lSUSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElOX0xPQ0tfSVJRU0FWRSBpcyBub3Qg c2V0CiMgQ09ORklHX0lOTElORV9TUElOX1VOTE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElO RV9TUElOX1VOTE9DS19CSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElOX1VOTE9DS19J UlEgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9VTkxPQ0tfSVJRUkVTVE9SRSBpcyBu b3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX1RSWUxPQ0sgaXMgbm90IHNldAojIENPTkZJR19J TkxJTkVfUkVBRF9MT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1JFQURfTE9DS19CSCBp cyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX0xPQ0tfSVJRIGlzIG5vdCBzZXQKIyBDT05G SUdfSU5MSU5FX1JFQURfTE9DS19JUlFTQVZFIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1JF QURfVU5MT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1JFQURfVU5MT0NLX0JIIGlzIG5v dCBzZXQKIyBDT05GSUdfSU5MSU5FX1JFQURfVU5MT0NLX0lSUSBpcyBub3Qgc2V0CiMgQ09ORklH X0lOTElORV9SRUFEX1VOTE9DS19JUlFSRVNUT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5F X1dSSVRFX1RSWUxPQ0sgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfV1JJVEVfTE9DSyBpcyBu b3Qgc2V0CiMgQ09ORklHX0lOTElORV9XUklURV9MT0NLX0JIIGlzIG5vdCBzZXQKIyBDT05GSUdf SU5MSU5FX1dSSVRFX0xPQ0tfSVJRIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1dSSVRFX0xP Q0tfSVJRU0FWRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9XUklURV9VTkxPQ0sgaXMgbm90 IHNldAojIENPTkZJR19JTkxJTkVfV1JJVEVfVU5MT0NLX0JIIGlzIG5vdCBzZXQKIyBDT05GSUdf SU5MSU5FX1dSSVRFX1VOTE9DS19JUlEgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfV1JJVEVf VU5MT0NLX0lSUVJFU1RPUkUgaXMgbm90IHNldApDT05GSUdfTVVURVhfU1BJTl9PTl9PV05FUj15 CkNPTkZJR19GUkVFWkVSPXkKCiMKIyBQcm9jZXNzb3IgdHlwZSBhbmQgZmVhdHVyZXMKIwpDT05G SUdfVElDS19PTkVTSE9UPXkKQ09ORklHX05PX0haPXkKQ09ORklHX0hJR0hfUkVTX1RJTUVSUz15 CkNPTkZJR19HRU5FUklDX0NMT0NLRVZFTlRTX0JVSUxEPXkKQ09ORklHX1NNUD15CkNPTkZJR19Y ODZfWDJBUElDPXkKIyBDT05GSUdfWDg2X01QUEFSU0UgaXMgbm90IHNldApDT05GSUdfWDg2X0VY VEVOREVEX1BMQVRGT1JNPXkKIyBDT05GSUdfWDg2X1ZTTVAgaXMgbm90IHNldAojIENPTkZJR19Y ODZfVVYgaXMgbm90IHNldApDT05GSUdfWDg2X1NVUFBPUlRTX01FTU9SWV9GQUlMVVJFPXkKQ09O RklHX1NDSEVEX09NSVRfRlJBTUVfUE9JTlRFUj15CiMgQ09ORklHX1BBUkFWSVJUX0dVRVNUIGlz IG5vdCBzZXQKQ09ORklHX05PX0JPT1RNRU09eQpDT05GSUdfTUVNVEVTVD15CiMgQ09ORklHX01L OCBpcyBub3Qgc2V0CiMgQ09ORklHX01QU0MgaXMgbm90IHNldApDT05GSUdfTUNPUkUyPXkKIyBD T05GSUdfTUFUT00gaXMgbm90IHNldAojIENPTkZJR19HRU5FUklDX0NQVSBpcyBub3Qgc2V0CkNP TkZJR19YODZfQ1BVPXkKQ09ORklHX1g4Nl9JTlRFUk5PREVfQ0FDSEVfU0hJRlQ9NwpDT05GSUdf WDg2X0NNUFhDSEc9eQpDT05GSUdfQ01QWENIR19MT0NBTD15CkNPTkZJR19YODZfTDFfQ0FDSEVf U0hJRlQ9NgpDT05GSUdfWDg2X1hBREQ9eQpDT05GSUdfWDg2X1dQX1dPUktTX09LPXkKQ09ORklH X1g4Nl9JTlRFTF9VU0VSQ09QWT15CkNPTkZJR19YODZfVVNFX1BQUk9fQ0hFQ0tTVU09eQpDT05G SUdfWDg2X1A2X05PUD15CkNPTkZJR19YODZfVFNDPXkKQ09ORklHX1g4Nl9DTVBYQ0hHNjQ9eQpD T05GSUdfWDg2X0NNT1Y9eQpDT05GSUdfWDg2X01JTklNVU1fQ1BVX0ZBTUlMWT02NApDT05GSUdf WDg2X0RFQlVHQ1RMTVNSPXkKQ09ORklHX0NQVV9TVVBfSU5URUw9eQpDT05GSUdfQ1BVX1NVUF9B TUQ9eQpDT05GSUdfQ1BVX1NVUF9DRU5UQVVSPXkKQ09ORklHX0hQRVRfVElNRVI9eQpDT05GSUdf SFBFVF9FTVVMQVRFX1JUQz15CkNPTkZJR19ETUk9eQpDT05GSUdfR0FSVF9JT01NVT15CiMgQ09O RklHX0NBTEdBUllfSU9NTVUgaXMgbm90IHNldAojIENPTkZJR19BTURfSU9NTVUgaXMgbm90IHNl dApDT05GSUdfU1dJT1RMQj15CkNPTkZJR19JT01NVV9IRUxQRVI9eQpDT05GSUdfSU9NTVVfQVBJ PXkKQ09ORklHX05SX0NQVVM9OApDT05GSUdfU0NIRURfU01UPXkKQ09ORklHX1NDSEVEX01DPXkK Q09ORklHX0lSUV9USU1FX0FDQ09VTlRJTkc9eQojIENPTkZJR19QUkVFTVBUX05PTkUgaXMgbm90 IHNldAojIENPTkZJR19QUkVFTVBUX1ZPTFVOVEFSWSBpcyBub3Qgc2V0CkNPTkZJR19QUkVFTVBU PXkKQ09ORklHX1g4Nl9MT0NBTF9BUElDPXkKQ09ORklHX1g4Nl9JT19BUElDPXkKQ09ORklHX1g4 Nl9SRVJPVVRFX0ZPUl9CUk9LRU5fQk9PVF9JUlFTPXkKQ09ORklHX1g4Nl9NQ0U9eQpDT05GSUdf WDg2X01DRV9JTlRFTD15CiMgQ09ORklHX1g4Nl9NQ0VfQU1EIGlzIG5vdCBzZXQKQ09ORklHX1g4 Nl9NQ0VfVEhSRVNIT0xEPXkKIyBDT05GSUdfWDg2X01DRV9JTkpFQ1QgaXMgbm90IHNldApDT05G SUdfWDg2X1RIRVJNQUxfVkVDVE9SPXkKIyBDT05GSUdfSThLIGlzIG5vdCBzZXQKIyBDT05GSUdf TUlDUk9DT0RFIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9NU1I9eQpDT05GSUdfWDg2X0NQVUlEPXkK Q09ORklHX0FSQ0hfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfQVJDSF9ETUFfQUREUl9UXzY0 QklUPXkKQ09ORklHX0RJUkVDVF9HQlBBR0VTPXkKQ09ORklHX05VTUE9eQojIENPTkZJR19BTURf TlVNQSBpcyBub3Qgc2V0CkNPTkZJR19YODZfNjRfQUNQSV9OVU1BPXkKQ09ORklHX05PREVTX1NQ QU5fT1RIRVJfTk9ERVM9eQojIENPTkZJR19OVU1BX0VNVSBpcyBub3Qgc2V0CkNPTkZJR19OT0RF U19TSElGVD02CkNPTkZJR19BUkNIX1BST0NfS0NPUkVfVEVYVD15CkNPTkZJR19BUkNIX1NQQVJT RU1FTV9ERUZBVUxUPXkKQ09ORklHX0FSQ0hfU1BBUlNFTUVNX0VOQUJMRT15CkNPTkZJR19BUkNI X1NFTEVDVF9NRU1PUllfTU9ERUw9eQpDT05GSUdfQVJDSF9NRU1PUllfUFJPQkU9eQpDT05GSUdf SUxMRUdBTF9QT0lOVEVSX1ZBTFVFPTB4ZGVhZDAwMDAwMDAwMDAwMApDT05GSUdfU0VMRUNUX01F TU9SWV9NT0RFTD15CkNPTkZJR19TUEFSU0VNRU1fTUFOVUFMPXkKQ09ORklHX1NQQVJTRU1FTT15 CkNPTkZJR19ORUVEX01VTFRJUExFX05PREVTPXkKQ09ORklHX0hBVkVfTUVNT1JZX1BSRVNFTlQ9 eQpDT05GSUdfU1BBUlNFTUVNX0VYVFJFTUU9eQpDT05GSUdfU1BBUlNFTUVNX1ZNRU1NQVBfRU5B QkxFPXkKQ09ORklHX1NQQVJTRU1FTV9BTExPQ19NRU1fTUFQX1RPR0VUSEVSPXkKQ09ORklHX1NQ QVJTRU1FTV9WTUVNTUFQPXkKQ09ORklHX0hBVkVfTUVNQkxPQ0s9eQpDT05GSUdfTUVNT1JZX0hP VFBMVUc9eQpDT05GSUdfTUVNT1JZX0hPVFBMVUdfU1BBUlNFPXkKQ09ORklHX01FTU9SWV9IT1RS RU1PVkU9eQpDT05GSUdfUEFHRUZMQUdTX0VYVEVOREVEPXkKQ09ORklHX1NQTElUX1BUTE9DS19D UFVTPTQKQ09ORklHX0NPTVBBQ1RJT049eQpDT05GSUdfTUlHUkFUSU9OPXkKQ09ORklHX1BIWVNf QUREUl9UXzY0QklUPXkKQ09ORklHX1pPTkVfRE1BX0ZMQUc9MQpDT05GSUdfQk9VTkNFPXkKQ09O RklHX1ZJUlRfVE9fQlVTPXkKQ09ORklHX0tTTT15CkNPTkZJR19ERUZBVUxUX01NQVBfTUlOX0FE RFI9NDA5NgpDT05GSUdfQVJDSF9TVVBQT1JUU19NRU1PUllfRkFJTFVSRT15CkNPTkZJR19NRU1P UllfRkFJTFVSRT15CkNPTkZJR19UUkFOU1BBUkVOVF9IVUdFUEFHRT15CkNPTkZJR19UUkFOU1BB UkVOVF9IVUdFUEFHRV9BTFdBWVM9eQojIENPTkZJR19UUkFOU1BBUkVOVF9IVUdFUEFHRV9NQURW SVNFIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9DSEVDS19CSU9TX0NPUlJVUFRJT049eQpDT05GSUdf WDg2X0JPT1RQQVJBTV9NRU1PUllfQ09SUlVQVElPTl9DSEVDSz15CkNPTkZJR19YODZfUkVTRVJW RV9MT1c9NjQKQ09ORklHX01UUlI9eQpDT05GSUdfTVRSUl9TQU5JVElaRVI9eQpDT05GSUdfTVRS Ul9TQU5JVElaRVJfRU5BQkxFX0RFRkFVTFQ9MApDT05GSUdfTVRSUl9TQU5JVElaRVJfU1BBUkVf UkVHX05SX0RFRkFVTFQ9MQpDT05GSUdfWDg2X1BBVD15CkNPTkZJR19BUkNIX1VTRVNfUEdfVU5D QUNIRUQ9eQpDT05GSUdfRUZJPXkKQ09ORklHX1NFQ0NPTVA9eQojIENPTkZJR19DQ19TVEFDS1BS T1RFQ1RPUiBpcyBub3Qgc2V0CiMgQ09ORklHX0haXzEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0ha XzI1MCBpcyBub3Qgc2V0CiMgQ09ORklHX0haXzMwMCBpcyBub3Qgc2V0CkNPTkZJR19IWl8xMDAw PXkKQ09ORklHX0haPTEwMDAKQ09ORklHX1NDSEVEX0hSVElDSz15CkNPTkZJR19LRVhFQz15CiMg Q09ORklHX0NSQVNIX0RVTVAgaXMgbm90IHNldApDT05GSUdfUEhZU0lDQUxfU1RBUlQ9MHgxMDAw MDAwCkNPTkZJR19SRUxPQ0FUQUJMRT15CkNPTkZJR19QSFlTSUNBTF9BTElHTj0weDEwMDAwMDAK Q09ORklHX0hPVFBMVUdfQ1BVPXkKIyBDT05GSUdfQ09NUEFUX1ZEU08gaXMgbm90IHNldAojIENP TkZJR19DTURMSU5FX0JPT0wgaXMgbm90IHNldApDT05GSUdfQVJDSF9FTkFCTEVfTUVNT1JZX0hP VFBMVUc9eQpDT05GSUdfQVJDSF9FTkFCTEVfTUVNT1JZX0hPVFJFTU9WRT15CkNPTkZJR19IQVZF X0FSQ0hfRUFSTFlfUEZOX1RPX05JRD15CkNPTkZJR19VU0VfUEVSQ1BVX05VTUFfTk9ERV9JRD15 CgojCiMgUG93ZXIgbWFuYWdlbWVudCBhbmQgQUNQSSBvcHRpb25zCiMKQ09ORklHX1BNPXkKIyBD T05GSUdfUE1fREVCVUcgaXMgbm90IHNldApDT05GSUdfUE1fU0xFRVBfU01QPXkKQ09ORklHX1BN X1NMRUVQPXkKQ09ORklHX1NVU1BFTkQ9eQpDT05GSUdfU1VTUEVORF9GUkVFWkVSPXkKIyBDT05G SUdfSElCRVJOQVRJT04gaXMgbm90IHNldApDT05GSUdfUE1fUlVOVElNRT15CkNPTkZJR19QTV9P UFM9eQpDT05GSUdfQUNQST15CkNPTkZJR19BQ1BJX1NMRUVQPXkKIyBDT05GSUdfQUNQSV9QUk9D RlMgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX1BST0NGU19QT1dFUiBpcyBub3Qgc2V0CiMgQ09O RklHX0FDUElfUE9XRVJfTUVURVIgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX0VDX0RFQlVHRlMg aXMgbm90IHNldAojIENPTkZJR19BQ1BJX1BST0NfRVZFTlQgaXMgbm90IHNldAojIENPTkZJR19B Q1BJX0FDIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNQSV9CQVRURVJZIGlzIG5vdCBzZXQKQ09ORklH X0FDUElfQlVUVE9OPXkKQ09ORklHX0FDUElfRkFOPXkKQ09ORklHX0FDUElfRE9DSz15CkNPTkZJ R19BQ1BJX1BST0NFU1NPUj15CkNPTkZJR19BQ1BJX0hPVFBMVUdfQ1BVPXkKIyBDT05GSUdfQUNQ SV9QUk9DRVNTT1JfQUdHUkVHQVRPUiBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX1RIRVJNQUw9eQpD T05GSUdfQUNQSV9OVU1BPXkKIyBDT05GSUdfQUNQSV9DVVNUT01fRFNEVCBpcyBub3Qgc2V0CkNP TkZJR19BQ1BJX0JMQUNLTElTVF9ZRUFSPTAKIyBDT05GSUdfQUNQSV9ERUJVRyBpcyBub3Qgc2V0 CkNPTkZJR19BQ1BJX1BDSV9TTE9UPXkKQ09ORklHX1g4Nl9QTV9USU1FUj15CkNPTkZJR19BQ1BJ X0NPTlRBSU5FUj15CiMgQ09ORklHX0FDUElfSE9UUExVR19NRU1PUlkgaXMgbm90IHNldAojIENP TkZJR19BQ1BJX1NCUyBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX0hFRD15CkNPTkZJR19BQ1BJX0FQ RUk9eQpDT05GSUdfQUNQSV9BUEVJX0dIRVM9eQojIENPTkZJR19BQ1BJX0FQRUlfRUlOSiBpcyBu b3Qgc2V0CiMgQ09ORklHX0FDUElfQVBFSV9FUlNUX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdf U0ZJIGlzIG5vdCBzZXQKCiMKIyBDUFUgRnJlcXVlbmN5IHNjYWxpbmcKIwpDT05GSUdfQ1BVX0ZS RVE9eQpDT05GSUdfQ1BVX0ZSRVFfVEFCTEU9eQojIENPTkZJR19DUFVfRlJFUV9ERUJVRyBpcyBu b3Qgc2V0CkNPTkZJR19DUFVfRlJFUV9TVEFUPXkKIyBDT05GSUdfQ1BVX0ZSRVFfU1RBVF9ERVRB SUxTIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9HT1ZfUEVSRk9STUFOQ0Ug aXMgbm90IHNldAojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9VU0VSU1BBQ0UgaXMgbm90 IHNldApDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9HT1ZfT05ERU1BTkQ9eQojIENPTkZJR19DUFVf RlJFUV9ERUZBVUxUX0dPVl9DT05TRVJWQVRJVkUgaXMgbm90IHNldApDT05GSUdfQ1BVX0ZSRVFf R09WX1BFUkZPUk1BTkNFPXkKQ09ORklHX0NQVV9GUkVRX0dPVl9QT1dFUlNBVkU9eQpDT05GSUdf Q1BVX0ZSRVFfR09WX1VTRVJTUEFDRT15CkNPTkZJR19DUFVfRlJFUV9HT1ZfT05ERU1BTkQ9eQoj IENPTkZJR19DUFVfRlJFUV9HT1ZfQ09OU0VSVkFUSVZFIGlzIG5vdCBzZXQKCiMKIyBDUFVGcmVx IHByb2Nlc3NvciBkcml2ZXJzCiMKQ09ORklHX1g4Nl9QQ0NfQ1BVRlJFUT15CkNPTkZJR19YODZf QUNQSV9DUFVGUkVRPXkKIyBDT05GSUdfWDg2X1BPV0VSTk9XX0s4IGlzIG5vdCBzZXQKIyBDT05G SUdfWDg2X1NQRUVEU1RFUF9DRU5UUklOTyBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9QNF9DTE9D S01PRCBpcyBub3Qgc2V0CgojCiMgc2hhcmVkIG9wdGlvbnMKIwojIENPTkZJR19YODZfU1BFRURT VEVQX0xJQiBpcyBub3Qgc2V0CkNPTkZJR19DUFVfSURMRT15CkNPTkZJR19DUFVfSURMRV9HT1Zf TEFEREVSPXkKQ09ORklHX0NQVV9JRExFX0dPVl9NRU5VPXkKIyBDT05GSUdfSU5URUxfSURMRSBp cyBub3Qgc2V0CgojCiMgTWVtb3J5IHBvd2VyIHNhdmluZ3MKIwpDT05GSUdfSTczMDBfSURMRV9J T0FUX0NIQU5ORUw9eQpDT05GSUdfSTczMDBfSURMRT15CgojCiMgQnVzIG9wdGlvbnMgKFBDSSBl dGMuKQojCkNPTkZJR19QQ0k9eQpDT05GSUdfUENJX0RJUkVDVD15CkNPTkZJR19QQ0lfTU1DT05G SUc9eQpDT05GSUdfUENJX0RPTUFJTlM9eQojIENPTkZJR19QQ0lfQ05CMjBMRV9RVUlSSyBpcyBu b3Qgc2V0CkNPTkZJR19ETUFSPXkKQ09ORklHX0RNQVJfREVGQVVMVF9PTj15CkNPTkZJR19ETUFS X0ZMT1BQWV9XQT15CkNPTkZJR19JTlRSX1JFTUFQPXkKQ09ORklHX1BDSUVQT1JUQlVTPXkKQ09O RklHX0hPVFBMVUdfUENJX1BDSUU9eQpDT05GSUdfUENJRUFFUj15CkNPTkZJR19QQ0lFX0VDUkM9 eQojIENPTkZJR19QQ0lFQUVSX0lOSkVDVCBpcyBub3Qgc2V0CkNPTkZJR19QQ0lFQVNQTT15CiMg Q09ORklHX1BDSUVBU1BNX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1BDSUVfUE1FPXkKQ09ORklH X0FSQ0hfU1VQUE9SVFNfTVNJPXkKQ09ORklHX1BDSV9NU0k9eQojIENPTkZJR19QQ0lfU1RVQiBp cyBub3Qgc2V0CkNPTkZJR19IVF9JUlE9eQojIENPTkZJR19QQ0lfSU9WIGlzIG5vdCBzZXQKQ09O RklHX1BDSV9JT0FQSUM9eQpDT05GSUdfSVNBX0RNQV9BUEk9eQpDT05GSUdfQU1EX05CPXkKIyBD T05GSUdfUENDQVJEIGlzIG5vdCBzZXQKQ09ORklHX0hPVFBMVUdfUENJPXkKIyBDT05GSUdfSE9U UExVR19QQ0lfRkFLRSBpcyBub3Qgc2V0CiMgQ09ORklHX0hPVFBMVUdfUENJX0FDUEkgaXMgbm90 IHNldAojIENPTkZJR19IT1RQTFVHX1BDSV9DUENJIGlzIG5vdCBzZXQKQ09ORklHX0hPVFBMVUdf UENJX1NIUEM9eQoKIwojIEV4ZWN1dGFibGUgZmlsZSBmb3JtYXRzIC8gRW11bGF0aW9ucwojCkNP TkZJR19CSU5GTVRfRUxGPXkKQ09ORklHX0NPTVBBVF9CSU5GTVRfRUxGPXkKIyBDT05GSUdfQ09S RV9EVU1QX0RFRkFVTFRfRUxGX0hFQURFUlMgaXMgbm90IHNldAojIENPTkZJR19IQVZFX0FPVVQg aXMgbm90IHNldApDT05GSUdfQklORk1UX01JU0M9eQpDT05GSUdfSUEzMl9FTVVMQVRJT049eQoj IENPTkZJR19JQTMyX0FPVVQgaXMgbm90IHNldApDT05GSUdfQ09NUEFUPXkKQ09ORklHX0NPTVBB VF9GT1JfVTY0X0FMSUdOTUVOVD15CkNPTkZJR19TWVNWSVBDX0NPTVBBVD15CkNPTkZJR19IQVZF X1RFWFRfUE9LRV9TTVA9eQpDT05GSUdfTkVUPXkKCiMKIyBOZXR3b3JraW5nIG9wdGlvbnMKIwpD T05GSUdfUEFDS0VUPXkKQ09ORklHX1VOSVg9eQpDT05GSUdfWEZSTT15CkNPTkZJR19YRlJNX1VT RVI9eQpDT05GSUdfWEZSTV9TVUJfUE9MSUNZPXkKQ09ORklHX1hGUk1fTUlHUkFURT15CkNPTkZJ R19YRlJNX1NUQVRJU1RJQ1M9eQpDT05GSUdfWEZSTV9JUENPTVA9eQpDT05GSUdfTkVUX0tFWT1t CkNPTkZJR19ORVRfS0VZX01JR1JBVEU9eQpDT05GSUdfSU5FVD15CkNPTkZJR19JUF9NVUxUSUNB U1Q9eQpDT05GSUdfSVBfQURWQU5DRURfUk9VVEVSPXkKQ09ORklHX0FTS19JUF9GSUJfSEFTSD15 CiMgQ09ORklHX0lQX0ZJQl9UUklFIGlzIG5vdCBzZXQKQ09ORklHX0lQX0ZJQl9IQVNIPXkKQ09O RklHX0lQX01VTFRJUExFX1RBQkxFUz15CkNPTkZJR19JUF9ST1VURV9NVUxUSVBBVEg9eQpDT05G SUdfSVBfUk9VVEVfVkVSQk9TRT15CiMgQ09ORklHX0lQX1BOUCBpcyBub3Qgc2V0CkNPTkZJR19O RVRfSVBJUD1tCiMgQ09ORklHX05FVF9JUEdSRV9ERU1VWCBpcyBub3Qgc2V0CkNPTkZJR19JUF9N Uk9VVEU9eQojIENPTkZJR19JUF9NUk9VVEVfTVVMVElQTEVfVEFCTEVTIGlzIG5vdCBzZXQKQ09O RklHX0lQX1BJTVNNX1YxPXkKQ09ORklHX0lQX1BJTVNNX1YyPXkKQ09ORklHX0FSUEQ9eQpDT05G SUdfU1lOX0NPT0tJRVM9eQpDT05GSUdfSU5FVF9BSD1tCkNPTkZJR19JTkVUX0VTUD1tCkNPTkZJ R19JTkVUX0lQQ09NUD1tCkNPTkZJR19JTkVUX1hGUk1fVFVOTkVMPW0KQ09ORklHX0lORVRfVFVO TkVMPXkKQ09ORklHX0lORVRfWEZSTV9NT0RFX1RSQU5TUE9SVD1tCkNPTkZJR19JTkVUX1hGUk1f TU9ERV9UVU5ORUw9bQpDT05GSUdfSU5FVF9YRlJNX01PREVfQkVFVD1tCkNPTkZJR19JTkVUX0xS Tz15CkNPTkZJR19JTkVUX0RJQUc9bQpDT05GSUdfSU5FVF9UQ1BfRElBRz1tCkNPTkZJR19UQ1Bf Q09OR19BRFZBTkNFRD15CiMgQ09ORklHX1RDUF9DT05HX0JJQyBpcyBub3Qgc2V0CkNPTkZJR19U Q1BfQ09OR19DVUJJQz15CiMgQ09ORklHX1RDUF9DT05HX1dFU1RXT09EIGlzIG5vdCBzZXQKIyBD T05GSUdfVENQX0NPTkdfSFRDUCBpcyBub3Qgc2V0CiMgQ09ORklHX1RDUF9DT05HX0hTVENQIGlz IG5vdCBzZXQKIyBDT05GSUdfVENQX0NPTkdfSFlCTEEgaXMgbm90IHNldAojIENPTkZJR19UQ1Bf Q09OR19WRUdBUyBpcyBub3Qgc2V0CiMgQ09ORklHX1RDUF9DT05HX1NDQUxBQkxFIGlzIG5vdCBz ZXQKIyBDT05GSUdfVENQX0NPTkdfTFAgaXMgbm90IHNldAojIENPTkZJR19UQ1BfQ09OR19WRU5P IGlzIG5vdCBzZXQKIyBDT05GSUdfVENQX0NPTkdfWUVBSCBpcyBub3Qgc2V0CiMgQ09ORklHX1RD UF9DT05HX0lMTElOT0lTIGlzIG5vdCBzZXQKQ09ORklHX0RFRkFVTFRfQ1VCSUM9eQojIENPTkZJ R19ERUZBVUxUX1JFTk8gaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9UQ1BfQ09ORz0iY3ViaWMi CkNPTkZJR19UQ1BfTUQ1U0lHPXkKQ09ORklHX0lQVjY9eQpDT05GSUdfSVBWNl9QUklWQUNZPXkK Q09ORklHX0lQVjZfUk9VVEVSX1BSRUY9eQpDT05GSUdfSVBWNl9ST1VURV9JTkZPPXkKQ09ORklH X0lQVjZfT1BUSU1JU1RJQ19EQUQ9eQpDT05GSUdfSU5FVDZfQUg9eQpDT05GSUdfSU5FVDZfRVNQ PXkKQ09ORklHX0lORVQ2X0lQQ09NUD15CkNPTkZJR19JUFY2X01JUDY9eQpDT05GSUdfSU5FVDZf WEZSTV9UVU5ORUw9eQpDT05GSUdfSU5FVDZfVFVOTkVMPXkKQ09ORklHX0lORVQ2X1hGUk1fTU9E RV9UUkFOU1BPUlQ9eQpDT05GSUdfSU5FVDZfWEZSTV9NT0RFX1RVTk5FTD15CkNPTkZJR19JTkVU Nl9YRlJNX01PREVfQkVFVD15CkNPTkZJR19JTkVUNl9YRlJNX01PREVfUk9VVEVPUFRJTUlaQVRJ T049eQpDT05GSUdfSVBWNl9TSVQ9eQpDT05GSUdfSVBWNl9TSVRfNlJEPXkKQ09ORklHX0lQVjZf TkRJU0NfTk9ERVRZUEU9eQpDT05GSUdfSVBWNl9UVU5ORUw9eQpDT05GSUdfSVBWNl9NVUxUSVBM RV9UQUJMRVM9eQpDT05GSUdfSVBWNl9TVUJUUkVFUz15CkNPTkZJR19JUFY2X01ST1VURT15CiMg Q09ORklHX0lQVjZfTVJPVVRFX01VTFRJUExFX1RBQkxFUyBpcyBub3Qgc2V0CkNPTkZJR19JUFY2 X1BJTVNNX1YyPXkKIyBDT05GSUdfTkVUTEFCRUwgaXMgbm90IHNldApDT05GSUdfTkVUV09SS19T RUNNQVJLPXkKIyBDT05GSUdfTkVUV09SS19QSFlfVElNRVNUQU1QSU5HIGlzIG5vdCBzZXQKQ09O RklHX05FVEZJTFRFUj15CiMgQ09ORklHX05FVEZJTFRFUl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJ R19ORVRGSUxURVJfQURWQU5DRUQ9eQoKIwojIENvcmUgTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24K IwpDT05GSUdfTkVURklMVEVSX05FVExJTks9eQpDT05GSUdfTkVURklMVEVSX05FVExJTktfUVVF VUU9bQpDT05GSUdfTkVURklMVEVSX05FVExJTktfTE9HPXkKQ09ORklHX05GX0NPTk5UUkFDSz15 CkNPTkZJR19ORl9DT05OVFJBQ0tfTUFSSz15CkNPTkZJR19ORl9DT05OVFJBQ0tfU0VDTUFSSz15 CkNPTkZJR19ORl9DT05OVFJBQ0tfWk9ORVM9eQpDT05GSUdfTkZfQ09OTlRSQUNLX0VWRU5UUz15 CkNPTkZJR19ORl9DVF9QUk9UT19EQ0NQPW0KQ09ORklHX05GX0NUX1BST1RPX0dSRT1tCkNPTkZJ R19ORl9DVF9QUk9UT19TQ1RQPW0KQ09ORklHX05GX0NUX1BST1RPX1VEUExJVEU9bQpDT05GSUdf TkZfQ09OTlRSQUNLX0FNQU5EQT1tCkNPTkZJR19ORl9DT05OVFJBQ0tfRlRQPW0KQ09ORklHX05G X0NPTk5UUkFDS19IMzIzPW0KQ09ORklHX05GX0NPTk5UUkFDS19JUkM9bQpDT05GSUdfTkZfQ09O TlRSQUNLX05FVEJJT1NfTlM9bQpDT05GSUdfTkZfQ09OTlRSQUNLX1BQVFA9bQpDT05GSUdfTkZf Q09OTlRSQUNLX1NBTkU9bQpDT05GSUdfTkZfQ09OTlRSQUNLX1NJUD1tCkNPTkZJR19ORl9DT05O VFJBQ0tfVEZUUD1tCkNPTkZJR19ORl9DVF9ORVRMSU5LPXkKQ09ORklHX05FVEZJTFRFUl9UUFJP WFk9bQpDT05GSUdfTkVURklMVEVSX1hUQUJMRVM9eQoKIwojIFh0YWJsZXMgY29tYmluZWQgbW9k dWxlcwojCkNPTkZJR19ORVRGSUxURVJfWFRfTUFSSz15CkNPTkZJR19ORVRGSUxURVJfWFRfQ09O Tk1BUks9eQoKIwojIFh0YWJsZXMgdGFyZ2V0cwojCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VU X0NIRUNLU1VNPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQ0xBU1NJRlk9bQpDT05GSUdf TkVURklMVEVSX1hUX1RBUkdFVF9DT05OTUFSSz15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VU X0NPTk5TRUNNQVJLPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQ1Q9eQpDT05GSUdfTkVU RklMVEVSX1hUX1RBUkdFVF9EU0NQPXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfSEw9eQpD T05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9JRExFVElNRVI9bQpDT05GSUdfTkVURklMVEVSX1hU X1RBUkdFVF9NQVJLPXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfTkZMT0c9bQpDT05GSUdf TkVURklMVEVSX1hUX1RBUkdFVF9ORlFVRVVFPXkKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRf Tk9UUkFDSz15CkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1JBVEVFU1Q9bQpDT05GSUdfTkVU RklMVEVSX1hUX1RBUkdFVF9URUU9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UUFJPWFk9 bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UUkFDRT1tCkNPTkZJR19ORVRGSUxURVJfWFRf VEFSR0VUX1NFQ01BUks9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UQ1BNU1M9bQpDT05G SUdfTkVURklMVEVSX1hUX1RBUkdFVF9UQ1BPUFRTVFJJUD1tCgojCiMgWHRhYmxlcyBtYXRjaGVz CiMKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DTFVTVEVSPW0KQ09ORklHX05FVEZJTFRFUl9Y VF9NQVRDSF9DT01NRU5UPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OQllURVM9bQpD T05GSUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5MSU1JVD15CkNPTkZJR19ORVRGSUxURVJfWFRf TUFUQ0hfQ09OTk1BUks9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5UUkFDSz15CkNP TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ1BVPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9E Q0NQPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9EU0NQPXkKQ09ORklHX05FVEZJTFRFUl9Y VF9NQVRDSF9FU1A9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0hBU0hMSU1JVD15CkNPTkZJ R19ORVRGSUxURVJfWFRfTUFUQ0hfSEVMUEVSPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9I TD15CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSVBSQU5HRT15CkNPTkZJR19ORVRGSUxURVJf WFRfTUFUQ0hfTEVOR1RIPXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9MSU1JVD15CkNPTkZJ R19ORVRGSUxURVJfWFRfTUFUQ0hfTUFDPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9NQVJL PXkKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9NVUxUSVBPUlQ9eQpDT05GSUdfTkVURklMVEVS X1hUX01BVENIX09TRj1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfT1dORVI9eQpDT05GSUdf TkVURklMVEVSX1hUX01BVENIX1BPTElDWT1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUEtU VFlQRT1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUVVPVEE9bQpDT05GSUdfTkVURklMVEVS X1hUX01BVENIX1JBVEVFU1Q9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1JFQUxNPW0KQ09O RklHX05FVEZJTFRFUl9YVF9NQVRDSF9SRUNFTlQ9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENI X1NDVFA9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NPQ0tFVD1tCkNPTkZJR19ORVRGSUxU RVJfWFRfTUFUQ0hfU1RBVEU9eQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NUQVRJU1RJQz15 CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfU1RSSU5HPXkKQ09ORklHX05FVEZJTFRFUl9YVF9N QVRDSF9UQ1BNU1M9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1RJTUU9bQpDT05GSUdfTkVU RklMVEVSX1hUX01BVENIX1UzMj1tCiMgQ09ORklHX0lQX1ZTIGlzIG5vdCBzZXQKCiMKIyBJUDog TmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24KIwpDT05GSUdfTkZfREVGUkFHX0lQVjQ9eQpDT05GSUdf TkZfQ09OTlRSQUNLX0lQVjQ9eQpDT05GSUdfTkZfQ09OTlRSQUNLX1BST0NfQ09NUEFUPXkKQ09O RklHX0lQX05GX1FVRVVFPXkKQ09ORklHX0lQX05GX0lQVEFCTEVTPXkKQ09ORklHX0lQX05GX01B VENIX0FERFJUWVBFPXkKQ09ORklHX0lQX05GX01BVENIX0FIPW0KQ09ORklHX0lQX05GX01BVENI X0VDTj1tCkNPTkZJR19JUF9ORl9NQVRDSF9UVEw9bQpDT05GSUdfSVBfTkZfRklMVEVSPXkKQ09O RklHX0lQX05GX1RBUkdFVF9SRUpFQ1Q9eQpDT05GSUdfSVBfTkZfVEFSR0VUX0xPRz15CkNPTkZJ R19JUF9ORl9UQVJHRVRfVUxPRz1tCkNPTkZJR19ORl9OQVQ9eQpDT05GSUdfTkZfTkFUX05FRURF RD15CkNPTkZJR19JUF9ORl9UQVJHRVRfTUFTUVVFUkFERT15CkNPTkZJR19JUF9ORl9UQVJHRVRf TkVUTUFQPXkKQ09ORklHX0lQX05GX1RBUkdFVF9SRURJUkVDVD15CkNPTkZJR19ORl9OQVRfU05N UF9CQVNJQz1tCkNPTkZJR19ORl9OQVRfUFJPVE9fRENDUD1tCkNPTkZJR19ORl9OQVRfUFJPVE9f R1JFPW0KQ09ORklHX05GX05BVF9QUk9UT19VRFBMSVRFPW0KQ09ORklHX05GX05BVF9QUk9UT19T Q1RQPW0KQ09ORklHX05GX05BVF9GVFA9bQpDT05GSUdfTkZfTkFUX0lSQz1tCkNPTkZJR19ORl9O QVRfVEZUUD1tCkNPTkZJR19ORl9OQVRfQU1BTkRBPW0KQ09ORklHX05GX05BVF9QUFRQPW0KQ09O RklHX05GX05BVF9IMzIzPW0KQ09ORklHX05GX05BVF9TSVA9bQpDT05GSUdfSVBfTkZfTUFOR0xF PXkKQ09ORklHX0lQX05GX1RBUkdFVF9DTFVTVEVSSVA9bQpDT05GSUdfSVBfTkZfVEFSR0VUX0VD Tj1tCkNPTkZJR19JUF9ORl9UQVJHRVRfVFRMPW0KQ09ORklHX0lQX05GX1JBVz15CiMgQ09ORklH X0lQX05GX1NFQ1VSSVRZIGlzIG5vdCBzZXQKQ09ORklHX0lQX05GX0FSUFRBQkxFUz15CkNPTkZJ R19JUF9ORl9BUlBGSUxURVI9bQpDT05GSUdfSVBfTkZfQVJQX01BTkdMRT1tCgojCiMgSVB2Njog TmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24KIwpDT05GSUdfTkZfREVGUkFHX0lQVjY9eQpDT05GSUdf TkZfQ09OTlRSQUNLX0lQVjY9eQpDT05GSUdfSVA2X05GX1FVRVVFPXkKQ09ORklHX0lQNl9ORl9J UFRBQkxFUz15CkNPTkZJR19JUDZfTkZfTUFUQ0hfQUg9bQpDT05GSUdfSVA2X05GX01BVENIX0VV STY0PW0KQ09ORklHX0lQNl9ORl9NQVRDSF9GUkFHPW0KQ09ORklHX0lQNl9ORl9NQVRDSF9PUFRT PW0KQ09ORklHX0lQNl9ORl9NQVRDSF9ITD1tCkNPTkZJR19JUDZfTkZfTUFUQ0hfSVBWNkhFQURF Uj1tCkNPTkZJR19JUDZfTkZfTUFUQ0hfTUg9bQpDT05GSUdfSVA2X05GX01BVENIX1JUPW0KQ09O RklHX0lQNl9ORl9UQVJHRVRfSEw9bQpDT05GSUdfSVA2X05GX1RBUkdFVF9MT0c9bQpDT05GSUdf SVA2X05GX0ZJTFRFUj15CkNPTkZJR19JUDZfTkZfVEFSR0VUX1JFSkVDVD15CkNPTkZJR19JUDZf TkZfTUFOR0xFPXkKQ09ORklHX0lQNl9ORl9SQVc9eQojIENPTkZJR19JUDZfTkZfU0VDVVJJVFkg aXMgbm90IHNldAojIENPTkZJR19JUF9EQ0NQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfU0NUUCBp cyBub3Qgc2V0CiMgQ09ORklHX1JEUyBpcyBub3Qgc2V0CiMgQ09ORklHX1RJUEMgaXMgbm90IHNl dAojIENPTkZJR19BVE0gaXMgbm90IHNldAojIENPTkZJR19MMlRQIGlzIG5vdCBzZXQKQ09ORklH X1NUUD1tCkNPTkZJR19HQVJQPW0KIyBDT05GSUdfQlJJREdFIGlzIG5vdCBzZXQKIyBDT05GSUdf TkVUX0RTQSBpcyBub3Qgc2V0CkNPTkZJR19WTEFOXzgwMjFRPW0KQ09ORklHX1ZMQU5fODAyMVFf R1ZSUD15CiMgQ09ORklHX0RFQ05FVCBpcyBub3Qgc2V0CkNPTkZJR19MTEM9bQojIENPTkZJR19M TEMyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEFQQiBpcyBub3Qgc2V0CiMgQ09ORklHX0VDT05FVCBp cyBub3Qgc2V0CiMgQ09ORklHX1dBTl9ST1VURVIgaXMgbm90IHNldAojIENPTkZJR19QSE9ORVQg aXMgbm90IHNldAojIENPTkZJR19JRUVFODAyMTU0IGlzIG5vdCBzZXQKQ09ORklHX05FVF9TQ0hF RD15CgojCiMgUXVldWVpbmcvU2NoZWR1bGluZwojCkNPTkZJR19ORVRfU0NIX0NCUT1tCkNPTkZJ R19ORVRfU0NIX0hUQj1tCkNPTkZJR19ORVRfU0NIX0hGU0M9bQpDT05GSUdfTkVUX1NDSF9QUklP PW0KQ09ORklHX05FVF9TQ0hfTVVMVElRPW0KQ09ORklHX05FVF9TQ0hfUkVEPW0KQ09ORklHX05F VF9TQ0hfU0ZRPW0KQ09ORklHX05FVF9TQ0hfVEVRTD1tCkNPTkZJR19ORVRfU0NIX1RCRj1tCkNP TkZJR19ORVRfU0NIX0dSRUQ9bQpDT05GSUdfTkVUX1NDSF9EU01BUks9bQpDT05GSUdfTkVUX1ND SF9ORVRFTT1tCkNPTkZJR19ORVRfU0NIX0RSUj1tCkNPTkZJR19ORVRfU0NIX0lOR1JFU1M9bQoK IwojIENsYXNzaWZpY2F0aW9uCiMKQ09ORklHX05FVF9DTFM9eQpDT05GSUdfTkVUX0NMU19CQVNJ Qz1tCkNPTkZJR19ORVRfQ0xTX1RDSU5ERVg9bQpDT05GSUdfTkVUX0NMU19ST1VURTQ9bQpDT05G SUdfTkVUX0NMU19ST1VURT15CkNPTkZJR19ORVRfQ0xTX0ZXPW0KQ09ORklHX05FVF9DTFNfVTMy PW0KQ09ORklHX0NMU19VMzJfUEVSRj15CkNPTkZJR19DTFNfVTMyX01BUks9eQpDT05GSUdfTkVU X0NMU19SU1ZQPW0KQ09ORklHX05FVF9DTFNfUlNWUDY9bQpDT05GSUdfTkVUX0NMU19GTE9XPW0K Q09ORklHX05FVF9DTFNfQ0dST1VQPW0KQ09ORklHX05FVF9FTUFUQ0g9eQpDT05GSUdfTkVUX0VN QVRDSF9TVEFDSz0zMgpDT05GSUdfTkVUX0VNQVRDSF9DTVA9bQpDT05GSUdfTkVUX0VNQVRDSF9O QllURT1tCkNPTkZJR19ORVRfRU1BVENIX1UzMj1tCkNPTkZJR19ORVRfRU1BVENIX01FVEE9bQpD T05GSUdfTkVUX0VNQVRDSF9URVhUPW0KQ09ORklHX05FVF9DTFNfQUNUPXkKQ09ORklHX05FVF9B Q1RfUE9MSUNFPW0KQ09ORklHX05FVF9BQ1RfR0FDVD1tCkNPTkZJR19HQUNUX1BST0I9eQpDT05G SUdfTkVUX0FDVF9NSVJSRUQ9bQpDT05GSUdfTkVUX0FDVF9JUFQ9bQpDT05GSUdfTkVUX0FDVF9O QVQ9bQpDT05GSUdfTkVUX0FDVF9QRURJVD1tCkNPTkZJR19ORVRfQUNUX1NJTVA9bQpDT05GSUdf TkVUX0FDVF9TS0JFRElUPW0KQ09ORklHX05FVF9BQ1RfQ1NVTT1tCkNPTkZJR19ORVRfQ0xTX0lO RD15CkNPTkZJR19ORVRfU0NIX0ZJRk89eQojIENPTkZJR19EQ0IgaXMgbm90IHNldAojIENPTkZJ R19ETlNfUkVTT0xWRVIgaXMgbm90IHNldAojIENPTkZJR19CQVRNQU5fQURWIGlzIG5vdCBzZXQK Q09ORklHX1JQUz15CkNPTkZJR19YUFM9eQoKIwojIE5ldHdvcmsgdGVzdGluZwojCkNPTkZJR19O RVRfUEtUR0VOPW0KQ09ORklHX05FVF9UQ1BQUk9CRT1tCiMgQ09ORklHX05FVF9EUk9QX01PTklU T1IgaXMgbm90IHNldAojIENPTkZJR19IQU1SQURJTyBpcyBub3Qgc2V0CiMgQ09ORklHX0NBTiBp cyBub3Qgc2V0CiMgQ09ORklHX0lSREEgaXMgbm90IHNldAojIENPTkZJR19CVCBpcyBub3Qgc2V0 CiMgQ09ORklHX0FGX1JYUlBDIGlzIG5vdCBzZXQKQ09ORklHX0ZJQl9SVUxFUz15CiMgQ09ORklH X1dJUkVMRVNTIGlzIG5vdCBzZXQKIyBDT05GSUdfV0lNQVggaXMgbm90IHNldAojIENPTkZJR19S RktJTEwgaXMgbm90IHNldAojIENPTkZJR19ORVRfOVAgaXMgbm90IHNldAojIENPTkZJR19DQUlG IGlzIG5vdCBzZXQKIyBDT05GSUdfQ0VQSF9MSUIgaXMgbm90IHNldAoKIwojIERldmljZSBEcml2 ZXJzCiMKCiMKIyBHZW5lcmljIERyaXZlciBPcHRpb25zCiMKQ09ORklHX1VFVkVOVF9IRUxQRVJf UEFUSD0iL3NiaW4vaG90cGx1ZyIKIyBDT05GSUdfREVWVE1QRlMgaXMgbm90IHNldApDT05GSUdf U1RBTkRBTE9ORT15CiMgQ09ORklHX1BSRVZFTlRfRklSTVdBUkVfQlVJTEQgaXMgbm90IHNldApD T05GSUdfRldfTE9BREVSPXkKQ09ORklHX0ZJUk1XQVJFX0lOX0tFUk5FTD15CkNPTkZJR19FWFRS QV9GSVJNV0FSRT0iIgojIENPTkZJR19TWVNfSFlQRVJWSVNPUiBpcyBub3Qgc2V0CiMgQ09ORklH X0NPTk5FQ1RPUiBpcyBub3Qgc2V0CiMgQ09ORklHX01URCBpcyBub3Qgc2V0CiMgQ09ORklHX1BB UlBPUlQgaXMgbm90IHNldApDT05GSUdfUE5QPXkKIyBDT05GSUdfUE5QX0RFQlVHX01FU1NBR0VT IGlzIG5vdCBzZXQKCiMKIyBQcm90b2NvbHMKIwpDT05GSUdfUE5QQUNQST15CkNPTkZJR19CTEtf REVWPXkKIyBDT05GSUdfQkxLX0RFVl9GRCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19DUFFfREEg aXMgbm90IHNldAojIENPTkZJR19CTEtfQ1BRX0NJU1NfREEgaXMgbm90IHNldAojIENPTkZJR19C TEtfREVWX0RBQzk2MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfVU1FTSBpcyBub3Qgc2V0 CiMgQ09ORklHX0JMS19ERVZfQ09XX0NPTU1PTiBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0xP T1A9eQpDT05GSUdfQkxLX0RFVl9DUllQVE9MT09QPXkKCiMKIyBEUkJEIGRpc2FibGVkIGJlY2F1 c2UgUFJPQ19GUywgSU5FVCBvciBDT05ORUNUT1Igbm90IHNlbGVjdGVkCiMKIyBDT05GSUdfQkxL X0RFVl9OQkQgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1NYOCBpcyBub3Qgc2V0CiMgQ09O RklHX0JMS19ERVZfVUIgaXMgbm90IHNldApDT05GSUdfQkxLX0RFVl9SQU09eQpDT05GSUdfQkxL X0RFVl9SQU1fQ09VTlQ9NApDT05GSUdfQkxLX0RFVl9SQU1fU0laRT01MjQyODgwCiMgQ09ORklH X0JMS19ERVZfWElQIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0RST01fUEtUQ0RWRCBpcyBub3Qgc2V0 CiMgQ09ORklHX0FUQV9PVkVSX0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfSEQgaXMg bm90IHNldAojIENPTkZJR19CTEtfREVWX1JCRCBpcyBub3Qgc2V0CiMgQ09ORklHX01JU0NfREVW SUNFUyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0lERT15CiMgQ09ORklHX0lERSBpcyBub3Qgc2V0 CgojCiMgU0NTSSBkZXZpY2Ugc3VwcG9ydAojCkNPTkZJR19TQ1NJX01PRD15CkNPTkZJR19SQUlE X0FUVFJTPW0KQ09ORklHX1NDU0k9eQpDT05GSUdfU0NTSV9ETUE9eQojIENPTkZJR19TQ1NJX1RH VCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfTkVUTElOSyBpcyBub3Qgc2V0CiMgQ09ORklHX1ND U0lfUFJPQ19GUyBpcyBub3Qgc2V0CgojCiMgU0NTSSBzdXBwb3J0IHR5cGUgKGRpc2ssIHRhcGUs IENELVJPTSkKIwpDT05GSUdfQkxLX0RFVl9TRD15CiMgQ09ORklHX0NIUl9ERVZfU1QgaXMgbm90 IHNldAojIENPTkZJR19DSFJfREVWX09TU1QgaXMgbm90IHNldApDT05GSUdfQkxLX0RFVl9TUj15 CkNPTkZJR19CTEtfREVWX1NSX1ZFTkRPUj15CkNPTkZJR19DSFJfREVWX1NHPXkKIyBDT05GSUdf Q0hSX0RFVl9TQ0ggaXMgbm90IHNldApDT05GSUdfU0NTSV9NVUxUSV9MVU49eQojIENPTkZJR19T Q1NJX0NPTlNUQU5UUyBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX0xPR0dJTkc9eQpDT05GSUdfU0NT SV9TQ0FOX0FTWU5DPXkKQ09ORklHX1NDU0lfV0FJVF9TQ0FOPW0KCiMKIyBTQ1NJIFRyYW5zcG9y dHMKIwojIENPTkZJR19TQ1NJX1NQSV9BVFRSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfRkNf QVRUUlMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0lTQ1NJX0FUVFJTIGlzIG5vdCBzZXQKQ09O RklHX1NDU0lfU0FTX0FUVFJTPXkKIyBDT05GSUdfU0NTSV9TQVNfTElCU0FTIGlzIG5vdCBzZXQK IyBDT05GSUdfU0NTSV9TUlBfQVRUUlMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0xPV0xFVkVM IGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9ESCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfT1NE X0lOSVRJQVRPUiBpcyBub3Qgc2V0CkNPTkZJR19BVEE9eQojIENPTkZJR19BVEFfTk9OU1RBTkRB UkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZFUkJPU0VfRVJST1I9eQpDT05GSUdfQVRBX0FDUEk9 eQpDT05GSUdfU0FUQV9QTVA9eQoKIwojIENvbnRyb2xsZXJzIHdpdGggbm9uLVNGRiBuYXRpdmUg aW50ZXJmYWNlCiMKQ09ORklHX1NBVEFfQUhDST15CiMgQ09ORklHX1NBVEFfQUhDSV9QTEFURk9S TSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfSU5JQzE2MlggaXMgbm90IHNldAojIENPTkZJR19T QVRBX0FDQVJEX0FIQ0kgaXMgbm90IHNldAojIENPTkZJR19TQVRBX1NJTDI0IGlzIG5vdCBzZXQK Q09ORklHX0FUQV9TRkY9eQoKIwojIFNGRiBjb250cm9sbGVycyB3aXRoIGN1c3RvbSBETUEgaW50 ZXJmYWNlCiMKIyBDT05GSUdfUERDX0FETUEgaXMgbm90IHNldAojIENPTkZJR19TQVRBX1FTVE9S IGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9TWDQgaXMgbm90IHNldApDT05GSUdfQVRBX0JNRE1B PXkKCiMKIyBTQVRBIFNGRiBjb250cm9sbGVycyB3aXRoIEJNRE1BCiMKIyBDT05GSUdfQVRBX1BJ SVggaXMgbm90IHNldAojIENPTkZJR19TQVRBX01WIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9O ViBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfUFJPTUlTRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NB VEFfU0lMIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9TSVMgaXMgbm90IHNldAojIENPTkZJR19T QVRBX1NWVyBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfVUxJIGlzIG5vdCBzZXQKIyBDT05GSUdf U0FUQV9WSUEgaXMgbm90IHNldAojIENPTkZJR19TQVRBX1ZJVEVTU0UgaXMgbm90IHNldAoKIwoj IFBBVEEgU0ZGIGNvbnRyb2xsZXJzIHdpdGggQk1ETUEKIwojIENPTkZJR19QQVRBX0FMSSBpcyBu b3Qgc2V0CiMgQ09ORklHX1BBVEFfQU1EIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9BUlRPUCBp cyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfQVRJSVhQIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9B VFA4NjdYIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9DTUQ2NFggaXMgbm90IHNldAojIENPTkZJ R19QQVRBX0NTNTUyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfQ1M1NTMwIGlzIG5vdCBzZXQK IyBDT05GSUdfUEFUQV9DUzU1MzYgaXMgbm90IHNldAojIENPTkZJR19QQVRBX0NZUFJFU1MgaXMg bm90IHNldAojIENPTkZJR19QQVRBX0VGQVIgaXMgbm90IHNldAojIENPTkZJR19QQVRBX0hQVDM2 NiBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfSFBUMzdYIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFU QV9IUFQzWDJOIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9IUFQzWDMgaXMgbm90IHNldAojIENP TkZJR19QQVRBX0lUODIxMyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfSVQ4MjFYIGlzIG5vdCBz ZXQKIyBDT05GSUdfUEFUQV9KTUlDUk9OIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9NQVJWRUxM IGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9ORVRDRUxMIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFU QV9OSU5KQTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9OUzg3NDE1IGlzIG5vdCBzZXQKIyBD T05GSUdfUEFUQV9PTERQSUlYIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9PUFRJRE1BIGlzIG5v dCBzZXQKIyBDT05GSUdfUEFUQV9QREMyMDI3WCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfUERD X09MRCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfUkFESVNZUyBpcyBub3Qgc2V0CiMgQ09ORklH X1BBVEFfUkRDIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9TQzEyMDAgaXMgbm90IHNldAojIENP TkZJR19QQVRBX1NDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfU0VSVkVSV09SS1MgaXMgbm90 IHNldAojIENPTkZJR19QQVRBX1NJTDY4MCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfU0lTIGlz IG5vdCBzZXQKIyBDT05GSUdfUEFUQV9UT1NISUJBIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9U UklGTEVYIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9WSUEgaXMgbm90IHNldAojIENPTkZJR19Q QVRBX1dJTkJPTkQgaXMgbm90IHNldAoKIwojIFBJTy1vbmx5IFNGRiBjb250cm9sbGVycwojCiMg Q09ORklHX1BBVEFfQ01ENjQwX1BDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfTVBJSVggaXMg bm90IHNldAojIENPTkZJR19QQVRBX05TODc0MTAgaXMgbm90IHNldAojIENPTkZJR19QQVRBX09Q VEkgaXMgbm90IHNldAojIENPTkZJR19QQVRBX1JaMTAwMCBpcyBub3Qgc2V0CgojCiMgR2VuZXJp YyBmYWxsYmFjayAvIGxlZ2FjeSBkcml2ZXJzCiMKQ09ORklHX1BBVEFfQUNQST15CkNPTkZJR19B VEFfR0VORVJJQz15CiMgQ09ORklHX1BBVEFfTEVHQUNZIGlzIG5vdCBzZXQKQ09ORklHX01EPXkK Q09ORklHX0JMS19ERVZfTUQ9eQpDT05GSUdfTURfQVVUT0RFVEVDVD15CkNPTkZJR19NRF9MSU5F QVI9eQpDT05GSUdfTURfUkFJRDA9eQpDT05GSUdfTURfUkFJRDE9eQojIENPTkZJR19NRF9SQUlE MTAgaXMgbm90IHNldApDT05GSUdfTURfUkFJRDQ1Nj15CiMgQ09ORklHX01VTFRJQ09SRV9SQUlE NDU2IGlzIG5vdCBzZXQKIyBDT05GSUdfTURfTVVMVElQQVRIIGlzIG5vdCBzZXQKIyBDT05GSUdf TURfRkFVTFRZIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfRE09eQojIENPTkZJR19ETV9ERUJV RyBpcyBub3Qgc2V0CkNPTkZJR19ETV9DUllQVD15CkNPTkZJR19ETV9TTkFQU0hPVD15CkNPTkZJ R19ETV9NSVJST1I9eQpDT05GSUdfRE1fUkFJRD15CiMgQ09ORklHX0RNX0xPR19VU0VSU1BBQ0Ug aXMgbm90IHNldApDT05GSUdfRE1fWkVSTz15CiMgQ09ORklHX0RNX01VTFRJUEFUSCBpcyBub3Qg c2V0CiMgQ09ORklHX0RNX0RFTEFZIGlzIG5vdCBzZXQKQ09ORklHX0RNX1VFVkVOVD15CiMgQ09O RklHX1RBUkdFVF9DT1JFIGlzIG5vdCBzZXQKQ09ORklHX0ZVU0lPTj15CiMgQ09ORklHX0ZVU0lP Tl9TUEkgaXMgbm90IHNldAojIENPTkZJR19GVVNJT05fRkMgaXMgbm90IHNldApDT05GSUdfRlVT SU9OX1NBUz15CkNPTkZJR19GVVNJT05fTUFYX1NHRT0xMjgKQ09ORklHX0ZVU0lPTl9DVEw9eQoj IENPTkZJR19GVVNJT05fTE9HR0lORyBpcyBub3Qgc2V0CgojCiMgSUVFRSAxMzk0IChGaXJlV2ly ZSkgc3VwcG9ydAojCiMgQ09ORklHX0ZJUkVXSVJFIGlzIG5vdCBzZXQKIyBDT05GSUdfRklSRVdJ UkVfTk9TWSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyTyBpcyBub3Qgc2V0CiMgQ09ORklHX01BQ0lO VE9TSF9EUklWRVJTIGlzIG5vdCBzZXQKQ09ORklHX05FVERFVklDRVM9eQpDT05GSUdfSUZCPW0K Q09ORklHX0RVTU1ZPW0KQ09ORklHX0JPTkRJTkc9bQpDT05GSUdfTUFDVkxBTj1tCkNPTkZJR19N QUNWVEFQPW0KQ09ORklHX0VRVUFMSVpFUj1tCkNPTkZJR19UVU49bQpDT05GSUdfVkVUSD1tCiMg Q09ORklHX05FVF9TQjEwMDAgaXMgbm90IHNldAojIENPTkZJR19BUkNORVQgaXMgbm90IHNldAoj IENPTkZJR19NSUkgaXMgbm90IHNldAojIENPTkZJR19QSFlMSUIgaXMgbm90IHNldAojIENPTkZJ R19ORVRfRVRIRVJORVQgaXMgbm90IHNldApDT05GSUdfTkVUREVWXzEwMDA9eQojIENPTkZJR19B Q0VOSUMgaXMgbm90IHNldAojIENPTkZJR19ETDJLIGlzIG5vdCBzZXQKIyBDT05GSUdfRTEwMDAg aXMgbm90IHNldApDT05GSUdfRTEwMDBFPXkKIyBDT05GSUdfSVAxMDAwIGlzIG5vdCBzZXQKIyBD T05GSUdfSUdCIGlzIG5vdCBzZXQKIyBDT05GSUdfSUdCVkYgaXMgbm90IHNldAojIENPTkZJR19O UzgzODIwIGlzIG5vdCBzZXQKIyBDT05GSUdfSEFNQUNISSBpcyBub3Qgc2V0CiMgQ09ORklHX1lF TExPV0ZJTiBpcyBub3Qgc2V0CiMgQ09ORklHX1I4MTY5IGlzIG5vdCBzZXQKIyBDT05GSUdfU0lT MTkwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0tHRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NLWTIgaXMg bm90IHNldAojIENPTkZJR19WSUFfVkVMT0NJVFkgaXMgbm90IHNldAojIENPTkZJR19USUdPTjMg aXMgbm90IHNldAojIENPTkZJR19CTlgyIGlzIG5vdCBzZXQKIyBDT05GSUdfQ05JQyBpcyBub3Qg c2V0CiMgQ09ORklHX1FMQTNYWFggaXMgbm90IHNldAojIENPTkZJR19BVEwxIGlzIG5vdCBzZXQK IyBDT05GSUdfQVRMMUUgaXMgbm90IHNldAojIENPTkZJR19BVEwxQyBpcyBub3Qgc2V0CiMgQ09O RklHX0pNRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NUTU1BQ19FVEggaXMgbm90IHNldAojIENPTkZJ R19QQ0hfR0JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUREVWXzEwMDAwIGlzIG5vdCBzZXQKIyBD T05GSUdfVFIgaXMgbm90IHNldAojIENPTkZJR19XTEFOIGlzIG5vdCBzZXQKCiMKIyBFbmFibGUg V2lNQVggKE5ldHdvcmtpbmcgb3B0aW9ucykgdG8gc2VlIHRoZSBXaU1BWCBkcml2ZXJzCiMKCiMK IyBVU0IgTmV0d29yayBBZGFwdGVycwojCiMgQ09ORklHX1VTQl9DQVRDIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX0tBV0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QRUdBU1VTIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX1JUTDgxNTAgaXMgbm90IHNldAojIENPTkZJR19VU0JfVVNCTkVUIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX0lQSEVUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1dBTiBpcyBu b3Qgc2V0CgojCiMgQ0FJRiB0cmFuc3BvcnQgZHJpdmVycwojCiMgQ09ORklHX0ZEREkgaXMgbm90 IHNldAojIENPTkZJR19ISVBQSSBpcyBub3Qgc2V0CiMgQ09ORklHX1BQUCBpcyBub3Qgc2V0CiMg Q09ORklHX1NMSVAgaXMgbm90IHNldAojIENPTkZJR19ORVRfRkMgaXMgbm90IHNldAojIENPTkZJ R19ORVRDT05TT0xFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUUE9MTCBpcyBub3Qgc2V0CiMgQ09O RklHX05FVF9QT0xMX0NPTlRST0xMRVIgaXMgbm90IHNldAojIENPTkZJR19WTVhORVQzIGlzIG5v dCBzZXQKIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0CiMgQ09ORklHX1BIT05FIGlzIG5vdCBzZXQK CiMKIyBJbnB1dCBkZXZpY2Ugc3VwcG9ydAojCkNPTkZJR19JTlBVVD15CiMgQ09ORklHX0lOUFVU X0ZGX01FTUxFU1MgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9QT0xMREVWIGlzIG5vdCBzZXQK IyBDT05GSUdfSU5QVVRfU1BBUlNFS01BUCBpcyBub3Qgc2V0CgojCiMgVXNlcmxhbmQgaW50ZXJm YWNlcwojCkNPTkZJR19JTlBVVF9NT1VTRURFVj15CiMgQ09ORklHX0lOUFVUX01PVVNFREVWX1BT QVVYIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX01PVVNFREVWX1NDUkVFTl9YPTEwMjQKQ09ORklH X0lOUFVUX01PVVNFREVWX1NDUkVFTl9ZPTc2OAojIENPTkZJR19JTlBVVF9KT1lERVYgaXMgbm90 IHNldApDT05GSUdfSU5QVVRfRVZERVY9eQojIENPTkZJR19JTlBVVF9FVkJVRyBpcyBub3Qgc2V0 CgojCiMgSW5wdXQgRGV2aWNlIERyaXZlcnMKIwpDT05GSUdfSU5QVVRfS0VZQk9BUkQ9eQojIENP TkZJR19LRVlCT0FSRF9BRFA1NTg4IGlzIG5vdCBzZXQKQ09ORklHX0tFWUJPQVJEX0FUS0JEPXkK IyBDT05GSUdfS0VZQk9BUkRfUVQyMTYwIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTEtL QkQgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9UQ0E2NDE2IGlzIG5vdCBzZXQKIyBDT05G SUdfS0VZQk9BUkRfTUFYNzM1OSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX01DUyBpcyBu b3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX05FV1RPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJP QVJEX09QRU5DT1JFUyBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1NUT1dBV0FZIGlzIG5v dCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfU1VOS0JEIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9B UkRfWFRLQkQgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9NT1VTRSBpcyBub3Qgc2V0CiMgQ09O RklHX0lOUFVUX0pPWVNUSUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfVEFCTEVUIGlzIG5v dCBzZXQKIyBDT05GSUdfSU5QVVRfVE9VQ0hTQ1JFRU4gaXMgbm90IHNldAojIENPTkZJR19JTlBV VF9NSVNDIGlzIG5vdCBzZXQKCiMKIyBIYXJkd2FyZSBJL08gcG9ydHMKIwpDT05GSUdfU0VSSU89 eQpDT05GSUdfU0VSSU9fSTgwNDI9eQojIENPTkZJR19TRVJJT19TRVJQT1JUIGlzIG5vdCBzZXQK IyBDT05GSUdfU0VSSU9fQ1Q4MkM3MTAgaXMgbm90IHNldAojIENPTkZJR19TRVJJT19QQ0lQUzIg aXMgbm90IHNldApDT05GSUdfU0VSSU9fTElCUFMyPXkKIyBDT05GSUdfU0VSSU9fUkFXIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VSSU9fQUxURVJBX1BTMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklP X1BTMk1VTFQgaXMgbm90IHNldAojIENPTkZJR19HQU1FUE9SVCBpcyBub3Qgc2V0CgojCiMgQ2hh cmFjdGVyIGRldmljZXMKIwpDT05GSUdfVlQ9eQpDT05GSUdfQ09OU09MRV9UUkFOU0xBVElPTlM9 eQpDT05GSUdfVlRfQ09OU09MRT15CkNPTkZJR19IV19DT05TT0xFPXkKQ09ORklHX1ZUX0hXX0NP TlNPTEVfQklORElORz15CiMgQ09ORklHX0RFVktNRU0gaXMgbm90IHNldAojIENPTkZJR19TRVJJ QUxfTk9OU1RBTkRBUkQgaXMgbm90IHNldAojIENPTkZJR19OX0dTTSBpcyBub3Qgc2V0CiMgQ09O RklHX05PWk9NSSBpcyBub3Qgc2V0CgojCiMgU2VyaWFsIGRyaXZlcnMKIwojIENPTkZJR19TRVJJ QUxfODI1MCBpcyBub3Qgc2V0CkNPTkZJR19GSVhfRUFSTFlDT05fTUVNPXkKCiMKIyBOb24tODI1 MCBzZXJpYWwgcG9ydCBzdXBwb3J0CiMKIyBDT05GSUdfU0VSSUFMX01GRF9IU1UgaXMgbm90IHNl dAojIENPTkZJR19TRVJJQUxfSlNNIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX1RJTUJFUkRB TEUgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfQUxURVJBX0pUQUdVQVJUIGlzIG5vdCBzZXQK IyBDT05GSUdfU0VSSUFMX0FMVEVSQV9VQVJUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX1BD SF9VQVJUIGlzIG5vdCBzZXQKQ09ORklHX1VOSVg5OF9QVFlTPXkKIyBDT05GSUdfREVWUFRTX01V TFRJUExFX0lOU1RBTkNFUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xFR0FDWV9QVFlTIGlzIG5vdCBz ZXQKIyBDT05GSUdfSVBNSV9IQU5ETEVSIGlzIG5vdCBzZXQKQ09ORklHX0hXX1JBTkRPTT15CiMg Q09ORklHX0hXX1JBTkRPTV9USU1FUklPTUVNIGlzIG5vdCBzZXQKQ09ORklHX0hXX1JBTkRPTV9J TlRFTD15CiMgQ09ORklHX0hXX1JBTkRPTV9BTUQgaXMgbm90IHNldAojIENPTkZJR19IV19SQU5E T01fVklBIGlzIG5vdCBzZXQKIyBDT05GSUdfTlZSQU0gaXMgbm90IHNldAojIENPTkZJR19SMzk2 NCBpcyBub3Qgc2V0CiMgQ09ORklHX0FQUExJQ09NIGlzIG5vdCBzZXQKIyBDT05GSUdfTVdBVkUg aXMgbm90IHNldAojIENPTkZJR19SQVdfRFJJVkVSIGlzIG5vdCBzZXQKQ09ORklHX0hQRVQ9eQpD T05GSUdfSFBFVF9NTUFQPXkKIyBDT05GSUdfSEFOR0NIRUNLX1RJTUVSIGlzIG5vdCBzZXQKIyBD T05GSUdfVENHX1RQTSBpcyBub3Qgc2V0CiMgQ09ORklHX1RFTENMT0NLIGlzIG5vdCBzZXQKQ09O RklHX0RFVlBPUlQ9eQojIENPTkZJR19SQU1PT1BTIGlzIG5vdCBzZXQKQ09ORklHX0kyQz15CkNP TkZJR19JMkNfQk9BUkRJTkZPPXkKQ09ORklHX0kyQ19DT01QQVQ9eQpDT05GSUdfSTJDX0NIQVJE RVY9eQojIENPTkZJR19JMkNfTVVYIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19IRUxQRVJfQVVUTz15 CgojCiMgSTJDIEhhcmR3YXJlIEJ1cyBzdXBwb3J0CiMKCiMKIyBQQyBTTUJ1cyBob3N0IGNvbnRy b2xsZXIgZHJpdmVycwojCiMgQ09ORklHX0kyQ19BTEkxNTM1IGlzIG5vdCBzZXQKIyBDT05GSUdf STJDX0FMSTE1NjMgaXMgbm90IHNldAojIENPTkZJR19JMkNfQUxJMTVYMyBpcyBub3Qgc2V0CiMg Q09ORklHX0kyQ19BTUQ3NTYgaXMgbm90IHNldAojIENPTkZJR19JMkNfQU1EODExMSBpcyBub3Qg c2V0CkNPTkZJR19JMkNfSTgwMT15CkNPTkZJR19JMkNfSVNDSD1tCiMgQ09ORklHX0kyQ19QSUlY NCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ORk9SQ0UyIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJD X1NJUzU1OTUgaXMgbm90IHNldAojIENPTkZJR19JMkNfU0lTNjMwIGlzIG5vdCBzZXQKIyBDT05G SUdfSTJDX1NJUzk2WCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19WSUEgaXMgbm90IHNldAojIENP TkZJR19JMkNfVklBUFJPIGlzIG5vdCBzZXQKCiMKIyBBQ1BJIGRyaXZlcnMKIwojIENPTkZJR19J MkNfU0NNSSBpcyBub3Qgc2V0CgojCiMgSTJDIHN5c3RlbSBidXMgZHJpdmVycyAobW9zdGx5IGVt YmVkZGVkIC8gc3lzdGVtLW9uLWNoaXApCiMKIyBDT05GSUdfSTJDX0lOVEVMX01JRCBpcyBub3Qg c2V0CiMgQ09ORklHX0kyQ19PQ09SRVMgaXMgbm90IHNldAojIENPTkZJR19JMkNfUENBX1BMQVRG T1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1NJTVRFQyBpcyBub3Qgc2V0CiMgQ09ORklHX0ky Q19YSUxJTlggaXMgbm90IHNldAojIENPTkZJR19JMkNfRUcyMFQgaXMgbm90IHNldAoKIwojIEV4 dGVybmFsIEkyQy9TTUJ1cyBhZGFwdGVyIGRyaXZlcnMKIwojIENPTkZJR19JMkNfUEFSUE9SVF9M SUdIVCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19UQU9TX0VWTSBpcyBub3Qgc2V0CiMgQ09ORklH X0kyQ19USU5ZX1VTQiBpcyBub3Qgc2V0CgojCiMgT3RoZXIgSTJDL1NNQnVzIGJ1cyBkcml2ZXJz CiMKIyBDT05GSUdfSTJDX1NUVUIgaXMgbm90IHNldAojIENPTkZJR19JMkNfREVCVUdfQ09SRSBp cyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERUJVR19BTEdPIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJD X0RFQlVHX0JVUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NQSSBpcyBub3Qgc2V0CgojCiMgUFBTIHN1 cHBvcnQKIwojIENPTkZJR19QUFMgaXMgbm90IHNldAoKIwojIFBQUyBnZW5lcmF0b3JzIHN1cHBv cnQKIwpDT05GSUdfQVJDSF9XQU5UX09QVElPTkFMX0dQSU9MSUI9eQojIENPTkZJR19HUElPTElC IGlzIG5vdCBzZXQKIyBDT05GSUdfVzEgaXMgbm90IHNldApDT05GSUdfUE9XRVJfU1VQUExZPXkK IyBDT05GSUdfUE9XRVJfU1VQUExZX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfUERBX1BPV0VS IGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9QT1dFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRF UllfRFMyNzgyIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9CUTIwWjc1IGlzIG5vdCBzZXQK IyBDT05GSUdfQkFUVEVSWV9CUTI3eDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9NQVgx NzA0MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRFUllfTUFYMTcwNDIgaXMgbm90IHNldApDT05G SUdfSFdNT049eQpDT05GSUdfSFdNT05fVklEPXkKIyBDT05GSUdfSFdNT05fREVCVUdfQ0hJUCBp cyBub3Qgc2V0CgojCiMgTmF0aXZlIGRyaXZlcnMKIwojIENPTkZJR19TRU5TT1JTX0FCSVRVR1VS VSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQUJJVFVHVVJVMyBpcyBub3Qgc2V0CiMgQ09O RklHX1NFTlNPUlNfQUQ3NDE0IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRDc0MTggaXMg bm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMjEgaXMgbm90IHNldAojIENPTkZJR19TRU5T T1JTX0FETTEwMjUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMjYgaXMgbm90IHNl dAojIENPTkZJR19TRU5TT1JTX0FETTEwMjkgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FE TTEwMzEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTkyNDAgaXMgbm90IHNldAojIENP TkZJR19TRU5TT1JTX0FEVDc0MTEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEVDc0NjIg aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEVDc0NzAgaXMgbm90IHNldAojIENPTkZJR19T RU5TT1JTX0FEVDc0NzUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FTQzc2MjEgaXMgbm90 IHNldAojIENPTkZJR19TRU5TT1JTX0s4VEVNUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf SzEwVEVNUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQVNCMTAwIGlzIG5vdCBzZXQKIyBD T05GSUdfU0VOU09SU19BVFhQMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRFM2MjAgaXMg bm90IHNldAojIENPTkZJR19TRU5TT1JTX0RTMTYyMSBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JT X0k1S19BTUI9eQojIENPTkZJR19TRU5TT1JTX0Y3MTgwNUYgaXMgbm90IHNldAojIENPTkZJR19T RU5TT1JTX0Y3MTg4MkZHIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19GNzUzNzVTIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19GU0NITUQgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT X0c3NjBBIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUxOFNNIGlzIG5vdCBzZXQKIyBD T05GSUdfU0VOU09SU19HTDUyMFNNIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfQ09SRVRFTVA9 eQojIENPTkZJR19TRU5TT1JTX1BLR1RFTVAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0lU ODcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0pDNDIgaXMgbm90IHNldAojIENPTkZJR19T RU5TT1JTX0xNNjMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNNzMgaXMgbm90IHNldAoj IENPTkZJR19TRU5TT1JTX0xNNzUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNNzcgaXMg bm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNNzggaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT X0xNODAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNODMgaXMgbm90IHNldAojIENPTkZJ R19TRU5TT1JTX0xNODUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNODcgaXMgbm90IHNl dAojIENPTkZJR19TRU5TT1JTX0xNOTAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNOTIg aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNOTMgaXMgbm90IHNldAojIENPTkZJR19TRU5T T1JTX0xUQzQyMTUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xUQzQyNDUgaXMgbm90IHNl dAojIENPTkZJR19TRU5TT1JTX0xUQzQyNjEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xN OTUyNDEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX01BWDE2MTkgaXMgbm90IHNldAojIENP TkZJR19TRU5TT1JTX01BWDY2NTAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1BDODczNjAg aXMgbm90IHNldApDT05GSUdfU0VOU09SU19QQzg3NDI3PW0KIyBDT05GSUdfU0VOU09SU19QQ0Y4 NTkxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TSFQyMSBpcyBub3Qgc2V0CiMgQ09ORklH X1NFTlNPUlNfU0lTNTU5NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU01NNjY1IGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19ETUUxNzM3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19FTUMxNDAzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19FTUMyMTAzIGlzIG5vdCBzZXQK IyBDT05GSUdfU0VOU09SU19TTVNDNDdNMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU01T QzQ3TTE5MiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU01TQzQ3QjM5NyBpcyBub3Qgc2V0 CiMgQ09ORklHX1NFTlNPUlNfQURTNzgyOCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQU1D NjgyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVEhNQzUwIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19UTVAxMDIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1RNUDQwMSBpcyBu b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVE1QNDIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19WSUFfQ1BVVEVNUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVklBNjg2QSBpcyBub3Qg c2V0CiMgQ09ORklHX1NFTlNPUlNfVlQxMjExIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19W VDgyMzEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc4MUQgaXMgbm90IHNldAojIENP TkZJR19TRU5TT1JTX1c4Mzc5MUQgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc5MkQg aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc5MyBpcyBub3Qgc2V0CkNPTkZJR19TRU5T T1JTX1c4Mzc5NT15CiMgQ09ORklHX1NFTlNPUlNfVzgzNzk1X0ZBTkNUUkwgaXMgbm90IHNldAoj IENPTkZJR19TRU5TT1JTX1c4M0w3ODVUUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVzgz TDc4Nk5HIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM2MjdIRiBpcyBub3Qgc2V0CkNP TkZJR19TRU5TT1JTX1c4MzYyN0VIRj15CiMgQ09ORklHX1NFTlNPUlNfTElTM19JMkMgaXMgbm90 IHNldAojIENPTkZJR19TRU5TT1JTX0FQUExFU01DIGlzIG5vdCBzZXQKCiMKIyBBQ1BJIGRyaXZl cnMKIwojIENPTkZJR19TRU5TT1JTX0FUSzAxMTAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT X0xJUzNMVjAyRCBpcyBub3Qgc2V0CkNPTkZJR19USEVSTUFMPXkKQ09ORklHX1RIRVJNQUxfSFdN T049eQpDT05GSUdfV0FUQ0hET0c9eQojIENPTkZJR19XQVRDSERPR19OT1dBWU9VVCBpcyBub3Qg c2V0CgojCiMgV2F0Y2hkb2cgRGV2aWNlIERyaXZlcnMKIwojIENPTkZJR19TT0ZUX1dBVENIRE9H IGlzIG5vdCBzZXQKIyBDT05GSUdfQUNRVUlSRV9XRFQgaXMgbm90IHNldAojIENPTkZJR19BRFZB TlRFQ0hfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfQUxJTTE1MzVfV0RUIGlzIG5vdCBzZXQKIyBD T05GSUdfQUxJTTcxMDFfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfRjcxODA4RV9XRFQgaXMgbm90 IHNldAojIENPTkZJR19TUDUxMDBfVENPIGlzIG5vdCBzZXQKIyBDT05GSUdfU0M1MjBfV0RUIGlz IG5vdCBzZXQKIyBDT05GSUdfU0JDX0ZJVFBDMl9XQVRDSERPRyBpcyBub3Qgc2V0CiMgQ09ORklH X0VVUk9URUNIX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lCNzAwX1dEVCBpcyBub3Qgc2V0CiMg Q09ORklHX0lCTUFTUiBpcyBub3Qgc2V0CiMgQ09ORklHX1dBRkVSX1dEVCBpcyBub3Qgc2V0CiMg Q09ORklHX0k2MzAwRVNCX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lUQ09fV0RUIGlzIG5vdCBz ZXQKIyBDT05GSUdfSVQ4NzEyRl9XRFQgaXMgbm90IHNldAojIENPTkZJR19JVDg3X1dEVCBpcyBu b3Qgc2V0CiMgQ09ORklHX0hQX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfU0MxMjAwX1dE VCBpcyBub3Qgc2V0CiMgQ09ORklHX1BDODc0MTNfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfTlZf VENPIGlzIG5vdCBzZXQKIyBDT05GSUdfNjBYWF9XRFQgaXMgbm90IHNldAojIENPTkZJR19TQkM4 MzYwX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVTVfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdf U01TQ19TQ0gzMTFYX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NNU0MzN0I3ODdfV0RUIGlzIG5v dCBzZXQKIyBDT05GSUdfVzgzNjI3SEZfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfVzgzNjk3SEZf V0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfVzgzNjk3VUdfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdf VzgzODc3Rl9XRFQgaXMgbm90IHNldAojIENPTkZJR19XODM5NzdGX1dEVCBpcyBub3Qgc2V0CiMg Q09ORklHX01BQ0haX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NCQ19FUFhfQzNfV0FUQ0hET0cg aXMgbm90IHNldAoKIwojIFBDSS1iYXNlZCBXYXRjaGRvZyBDYXJkcwojCiMgQ09ORklHX1BDSVBD V0FUQ0hET0cgaXMgbm90IHNldAojIENPTkZJR19XRFRQQ0kgaXMgbm90IHNldAoKIwojIFVTQi1i YXNlZCBXYXRjaGRvZyBDYXJkcwojCiMgQ09ORklHX1VTQlBDV0FUQ0hET0cgaXMgbm90IHNldApD T05GSUdfU1NCX1BPU1NJQkxFPXkKCiMKIyBTb25pY3MgU2lsaWNvbiBCYWNrcGxhbmUKIwojIENP TkZJR19TU0IgaXMgbm90IHNldAojIENPTkZJR19NRkRfU1VQUE9SVCBpcyBub3Qgc2V0CkNPTkZJ R19NRkRfQ09SRT1tCkNPTkZJR19MUENfU0NIPW0KIyBDT05GSUdfUkVHVUxBVE9SIGlzIG5vdCBz ZXQKIyBDT05GSUdfTUVESUFfU1VQUE9SVCBpcyBub3Qgc2V0CgojCiMgR3JhcGhpY3Mgc3VwcG9y dAojCkNPTkZJR19BR1A9eQojIENPTkZJR19BR1BfQU1ENjQgaXMgbm90IHNldAojIENPTkZJR19B R1BfSU5URUwgaXMgbm90IHNldAojIENPTkZJR19BR1BfU0lTIGlzIG5vdCBzZXQKIyBDT05GSUdf QUdQX1ZJQSBpcyBub3Qgc2V0CkNPTkZJR19WR0FfQVJCPXkKQ09ORklHX1ZHQV9BUkJfTUFYX0dQ VVM9MTYKIyBDT05GSUdfVkdBX1NXSVRDSEVST08gaXMgbm90IHNldAojIENPTkZJR19EUk0gaXMg bm90IHNldAojIENPTkZJR19TVFVCX1BPVUxTQk8gaXMgbm90IHNldAojIENPTkZJR19WR0FTVEFU RSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX09VVFBVVF9DT05UUk9MIGlzIG5vdCBzZXQKIyBD T05GSUdfRkIgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfTENEX1NVUFBPUlQgaXMgbm90 IHNldAoKIwojIERpc3BsYXkgZGV2aWNlIHN1cHBvcnQKIwojIENPTkZJR19ESVNQTEFZX1NVUFBP UlQgaXMgbm90IHNldAoKIwojIENvbnNvbGUgZGlzcGxheSBkcml2ZXIgc3VwcG9ydAojCkNPTkZJ R19WR0FfQ09OU09MRT15CkNPTkZJR19WR0FDT05fU09GVF9TQ1JPTExCQUNLPXkKQ09ORklHX1ZH QUNPTl9TT0ZUX1NDUk9MTEJBQ0tfU0laRT01MTIKQ09ORklHX0RVTU1ZX0NPTlNPTEU9eQojIENP TkZJR19TT1VORCBpcyBub3Qgc2V0CkNPTkZJR19ISURfU1VQUE9SVD15CkNPTkZJR19ISUQ9eQoj IENPTkZJR19ISURSQVcgaXMgbm90IHNldAoKIwojIFVTQiBJbnB1dCBEZXZpY2VzCiMKQ09ORklH X1VTQl9ISUQ9eQojIENPTkZJR19ISURfUElEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0hJRERF ViBpcyBub3Qgc2V0CgojCiMgU3BlY2lhbCBISUQgZHJpdmVycwojCiMgQ09ORklHX0hJRF8zTV9Q Q1QgaXMgbm90IHNldApDT05GSUdfSElEX0E0VEVDSD15CiMgQ09ORklHX0hJRF9BQ1JVWCBpcyBu b3Qgc2V0CkNPTkZJR19ISURfQVBQTEU9eQpDT05GSUdfSElEX0JFTEtJTj15CiMgQ09ORklHX0hJ RF9DQU5ETyBpcyBub3Qgc2V0CkNPTkZJR19ISURfQ0hFUlJZPXkKQ09ORklHX0hJRF9DSElDT05Z PXkKQ09ORklHX0hJRF9DWVBSRVNTPXkKIyBDT05GSUdfSElEX0RSQUdPTlJJU0UgaXMgbm90IHNl dAojIENPTkZJR19ISURfRU1TX0ZGIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0VHQUxBWCBpcyBu b3Qgc2V0CkNPTkZJR19ISURfRVpLRVk9eQpDT05GSUdfSElEX0tZRT15CiMgQ09ORklHX0hJRF9V Q0xPR0lDIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1dBTFRPUCBpcyBub3Qgc2V0CiMgQ09ORklH X0hJRF9HWVJBVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9UV0lOSEFOIGlzIG5vdCBzZXQK Q09ORklHX0hJRF9LRU5TSU5HVE9OPXkKQ09ORklHX0hJRF9MT0dJVEVDSD15CiMgQ09ORklHX0xP R0lURUNIX0ZGIGlzIG5vdCBzZXQKIyBDT05GSUdfTE9HSVJVTUJMRVBBRDJfRkYgaXMgbm90IHNl dAojIENPTkZJR19MT0dJRzk0MF9GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0xPR0lXSUlfRkYgaXMg bm90IHNldApDT05GSUdfSElEX01JQ1JPU09GVD15CiMgQ09ORklHX0hJRF9NT1NBUlQgaXMgbm90 IHNldApDT05GSUdfSElEX01PTlRFUkVZPXkKIyBDT05GSUdfSElEX01VTFRJVE9VQ0ggaXMgbm90 IHNldAojIENPTkZJR19ISURfTlRSSUcgaXMgbm90IHNldAojIENPTkZJR19ISURfT1JURUsgaXMg bm90IHNldAojIENPTkZJR19ISURfUEFOVEhFUkxPUkQgaXMgbm90IHNldAojIENPTkZJR19ISURf UEVUQUxZTlggaXMgbm90IHNldAojIENPTkZJR19ISURfUElDT0xDRCBpcyBub3Qgc2V0CiMgQ09O RklHX0hJRF9RVUFOVEEgaXMgbm90IHNldAojIENPTkZJR19ISURfUk9DQ0FUIGlzIG5vdCBzZXQK IyBDT05GSUdfSElEX1JPQ0NBVF9LT05FIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1JPQ0NBVF9L T05FUExVUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9ST0NDQVRfUFlSQSBpcyBub3Qgc2V0CiMg Q09ORklHX0hJRF9TQU1TVU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1NPTlkgaXMgbm90IHNl dAojIENPTkZJR19ISURfU1RBTlRVTSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TVU5QTFVTIGlz IG5vdCBzZXQKIyBDT05GSUdfSElEX0dSRUVOQVNJQSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9T TUFSVEpPWVBMVVMgaXMgbm90IHNldAojIENPTkZJR19ISURfVE9QU0VFRCBpcyBub3Qgc2V0CiMg Q09ORklHX0hJRF9USFJVU1RNQVNURVIgaXMgbm90IHNldAojIENPTkZJR19ISURfWkVST1BMVVMg aXMgbm90IHNldAojIENPTkZJR19ISURfWllEQUNST04gaXMgbm90IHNldApDT05GSUdfVVNCX1NV UFBPUlQ9eQpDT05GSUdfVVNCX0FSQ0hfSEFTX0hDRD15CkNPTkZJR19VU0JfQVJDSF9IQVNfT0hD ST15CkNPTkZJR19VU0JfQVJDSF9IQVNfRUhDST15CkNPTkZJR19VU0I9eQojIENPTkZJR19VU0Jf REVCVUcgaXMgbm90IHNldApDT05GSUdfVVNCX0FOTk9VTkNFX05FV19ERVZJQ0VTPXkKCiMKIyBN aXNjZWxsYW5lb3VzIFVTQiBvcHRpb25zCiMKQ09ORklHX1VTQl9ERVZJQ0VGUz15CiMgQ09ORklH X1VTQl9ERVZJQ0VfQ0xBU1MgaXMgbm90IHNldAojIENPTkZJR19VU0JfRFlOQU1JQ19NSU5PUlMg aXMgbm90IHNldAojIENPTkZJR19VU0JfU1VTUEVORCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9N T04gaXMgbm90IHNldAojIENPTkZJR19VU0JfV1VTQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9X VVNCX0NCQUYgaXMgbm90IHNldAoKIwojIFVTQiBIb3N0IENvbnRyb2xsZXIgRHJpdmVycwojCiMg Q09ORklHX1VTQl9DNjdYMDBfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1hIQ0lfSENEIGlz IG5vdCBzZXQKQ09ORklHX1VTQl9FSENJX0hDRD15CkNPTkZJR19VU0JfRUhDSV9ST09UX0hVQl9U VD15CkNPTkZJR19VU0JfRUhDSV9UVF9ORVdTQ0hFRD15CiMgQ09ORklHX1VTQl9PWFUyMTBIUF9I Q0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTE2WF9IQ0QgaXMgbm90IHNldAojIENPTkZJ R19VU0JfSVNQMTc2MF9IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNQMTM2Ml9IQ0QgaXMg bm90IHNldApDT05GSUdfVVNCX09IQ0lfSENEPXkKIyBDT05GSUdfVVNCX09IQ0lfQklHX0VORElB Tl9ERVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX09IQ0lfQklHX0VORElBTl9NTUlPIGlzIG5v dCBzZXQKQ09ORklHX1VTQl9PSENJX0xJVFRMRV9FTkRJQU49eQpDT05GSUdfVVNCX1VIQ0lfSENE PXkKIyBDT05GSUdfVVNCX1NMODExX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9SOEE2NjU5 N19IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfV0hDSV9IQ0QgaXMgbm90IHNldAojIENPTkZJ R19VU0JfSFdBX0hDRCBpcyBub3Qgc2V0CgojCiMgVVNCIERldmljZSBDbGFzcyBkcml2ZXJzCiMK IyBDT05GSUdfVVNCX0FDTSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QUklOVEVSIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX1dETSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9UTUMgaXMgbm90IHNl dAoKIwojIE5PVEU6IFVTQl9TVE9SQUdFIGRlcGVuZHMgb24gU0NTSSBidXQgQkxLX0RFVl9TRCBt YXkKIwoKIwojIGFsc28gYmUgbmVlZGVkOyBzZWUgVVNCX1NUT1JBR0UgSGVscCBmb3IgbW9yZSBp bmZvCiMKQ09ORklHX1VTQl9TVE9SQUdFPXkKIyBDT05GSUdfVVNCX1NUT1JBR0VfREVCVUcgaXMg bm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9EQVRBRkFCIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX1NUT1JBR0VfRlJFRUNPTSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0lTRDIw MCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1VTQkFUIGlzIG5vdCBzZXQKIyBDT05G SUdfVVNCX1NUT1JBR0VfU0REUjA5IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfU0RE UjU1IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfSlVNUFNIT1QgaXMgbm90IHNldAoj IENPTkZJR19VU0JfU1RPUkFHRV9BTEFVREEgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFH RV9PTkVUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0tBUk1BIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfQ1lQUkVTU19BVEFDQiBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9VQVMgaXMgbm90IHNldAojIENPTkZJR19VU0JfTElCVVNVQUwgaXMgbm90IHNldAoKIwoj IFVTQiBJbWFnaW5nIGRldmljZXMKIwojIENPTkZJR19VU0JfTURDODAwIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX01JQ1JPVEVLIGlzIG5vdCBzZXQKCiMKIyBVU0IgcG9ydCBkcml2ZXJzCiMKIyBD T05GSUdfVVNCX1NFUklBTCBpcyBub3Qgc2V0CgojCiMgVVNCIE1pc2NlbGxhbmVvdXMgZHJpdmVy cwojCiMgQ09ORklHX1VTQl9FTUk2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9FTUkyNiBpcyBu b3Qgc2V0CiMgQ09ORklHX1VTQl9BRFVUVVggaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VWU0VH IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9M RUdPVE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfTENEIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX0xFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVBSRVNTX0NZN0M2MyBpcyBub3Qgc2V0 CiMgQ09ORklHX1VTQl9DWVRIRVJNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0lETU9VU0UgaXMg bm90IHNldAojIENPTkZJR19VU0JfRlRESV9FTEFOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0FQ UExFRElTUExBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TSVNVU0JWR0EgaXMgbm90IHNldAoj IENPTkZJR19VU0JfTEQgaXMgbm90IHNldAojIENPTkZJR19VU0JfVFJBTkNFVklCUkFUT1IgaXMg bm90IHNldAojIENPTkZJR19VU0JfSU9XQVJSSU9SIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1RF U1QgaXMgbm90IHNldAojIENPTkZJR19VU0JfSVNJR0hURlcgaXMgbm90IHNldAojIENPTkZJR19V U0JfWVVSRVggaXMgbm90IHNldAojIENPTkZJR19VU0JfR0FER0VUIGlzIG5vdCBzZXQKCiMKIyBP VEcgYW5kIHJlbGF0ZWQgaW5mcmFzdHJ1Y3R1cmUKIwojIENPTkZJR19OT1BfVVNCX1hDRUlWIGlz IG5vdCBzZXQKIyBDT05GSUdfVVdCIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DIGlzIG5vdCBzZXQK IyBDT05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldAojIENPTkZJR19ORVdfTEVEUyBpcyBub3Qgc2V0 CiMgQ09ORklHX05GQ19ERVZJQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNDRVNTSUJJTElUWSBp cyBub3Qgc2V0CiMgQ09ORklHX0lORklOSUJBTkQgaXMgbm90IHNldApDT05GSUdfRURBQz15Cgoj CiMgUmVwb3J0aW5nIHN1YnN5c3RlbXMKIwojIENPTkZJR19FREFDX0RFQlVHIGlzIG5vdCBzZXQK Q09ORklHX0VEQUNfREVDT0RFX01DRT15CiMgQ09ORklHX0VEQUNfTUNFX0lOSiBpcyBub3Qgc2V0 CkNPTkZJR19FREFDX01NX0VEQUM9eQojIENPTkZJR19FREFDX0FNRDY0IGlzIG5vdCBzZXQKIyBD T05GSUdfRURBQ19FNzUyWCBpcyBub3Qgc2V0CiMgQ09ORklHX0VEQUNfSTgyOTc1WCBpcyBub3Qg c2V0CiMgQ09ORklHX0VEQUNfSTMwMDAgaXMgbm90IHNldAojIENPTkZJR19FREFDX0kzMjAwIGlz IG5vdCBzZXQKIyBDT05GSUdfRURBQ19YMzggaXMgbm90IHNldAojIENPTkZJR19FREFDX0k1NDAw IGlzIG5vdCBzZXQKIyBDT05GSUdfRURBQ19JN0NPUkUgaXMgbm90IHNldAojIENPTkZJR19FREFD X0k1MDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfRURBQ19JNTEwMCBpcyBub3Qgc2V0CiMgQ09ORklH X0VEQUNfSTczMDAgaXMgbm90IHNldApDT05GSUdfUlRDX0xJQj15CkNPTkZJR19SVENfQ0xBU1M9 eQpDT05GSUdfUlRDX0hDVE9TWVM9eQpDT05GSUdfUlRDX0hDVE9TWVNfREVWSUNFPSJydGMwIgoj IENPTkZJR19SVENfREVCVUcgaXMgbm90IHNldAoKIwojIFJUQyBpbnRlcmZhY2VzCiMKQ09ORklH X1JUQ19JTlRGX1NZU0ZTPXkKQ09ORklHX1JUQ19JTlRGX1BST0M9eQpDT05GSUdfUlRDX0lOVEZf REVWPXkKIyBDT05GSUdfUlRDX0lOVEZfREVWX1VJRV9FTVVMIGlzIG5vdCBzZXQKIyBDT05GSUdf UlRDX0RSVl9URVNUIGlzIG5vdCBzZXQKCiMKIyBJMkMgUlRDIGRyaXZlcnMKIwojIENPTkZJR19S VENfRFJWX0RTMTMwNyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMzc0IGlzIG5vdCBz ZXQKIyBDT05GSUdfUlRDX0RSVl9EUzE2NzIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RT MzIzMiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTUFYNjkwMCBpcyBub3Qgc2V0CiMgQ09O RklHX1JUQ19EUlZfUlM1QzM3MiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfSVNMMTIwOCBp cyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfSVNMMTIwMjIgaXMgbm90IHNldAojIENPTkZJR19S VENfRFJWX1gxMjA1IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9QQ0Y4NTYzIGlzIG5vdCBz ZXQKIyBDT05GSUdfUlRDX0RSVl9QQ0Y4NTgzIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9N NDFUODAgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0JRMzJLIGlzIG5vdCBzZXQKIyBDT05G SUdfUlRDX0RSVl9TMzUzOTBBIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9GTTMxMzAgaXMg bm90IHNldAojIENPTkZJR19SVENfRFJWX1JYODU4MSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19E UlZfUlg4MDI1IGlzIG5vdCBzZXQKCiMKIyBTUEkgUlRDIGRyaXZlcnMKIwoKIwojIFBsYXRmb3Jt IFJUQyBkcml2ZXJzCiMKQ09ORklHX1JUQ19EUlZfQ01PUz15CiMgQ09ORklHX1JUQ19EUlZfRFMx Mjg2IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzE1MTEgaXMgbm90IHNldAojIENPTkZJ R19SVENfRFJWX0RTMTU1MyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxNzQyIGlzIG5v dCBzZXQKIyBDT05GSUdfUlRDX0RSVl9TVEsxN1RBOCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19E UlZfTTQ4VDg2IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NNDhUMzUgaXMgbm90IHNldAoj IENPTkZJR19SVENfRFJWX000OFQ1OSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTVNNNjI0 MiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfQlE0ODAyIGlzIG5vdCBzZXQKIyBDT05GSUdf UlRDX0RSVl9SUDVDMDEgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1YzMDIwIGlzIG5vdCBz ZXQKCiMKIyBvbi1DUFUgUlRDIGRyaXZlcnMKIwpDT05GSUdfRE1BREVWSUNFUz15CiMgQ09ORklH X0RNQURFVklDRVNfREVCVUcgaXMgbm90IHNldAoKIwojIERNQSBEZXZpY2VzCiMKIyBDT05GSUdf SU5URUxfTUlEX0RNQUMgaXMgbm90IHNldApDT05GSUdfSU5URUxfSU9BVERNQT15CiMgQ09ORklH X1RJTUJfRE1BIGlzIG5vdCBzZXQKIyBDT05GSUdfUENIX0RNQSBpcyBub3Qgc2V0CkNPTkZJR19E TUFfRU5HSU5FPXkKCiMKIyBETUEgQ2xpZW50cwojCkNPTkZJR19ORVRfRE1BPXkKQ09ORklHX0FT WU5DX1RYX0RNQT15CiMgQ09ORklHX0RNQVRFU1QgaXMgbm90IHNldApDT05GSUdfRENBPXkKIyBD T05GSUdfQVVYRElTUExBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1VJTyBpcyBub3Qgc2V0CiMgQ09O RklHX1NUQUdJTkcgaXMgbm90IHNldAojIENPTkZJR19YODZfUExBVEZPUk1fREVWSUNFUyBpcyBu b3Qgc2V0CgojCiMgRmlybXdhcmUgRHJpdmVycwojCiMgQ09ORklHX0VERCBpcyBub3Qgc2V0CkNP TkZJR19GSVJNV0FSRV9NRU1NQVA9eQpDT05GSUdfRUZJX1ZBUlM9eQojIENPTkZJR19ERUxMX1JC VSBpcyBub3Qgc2V0CiMgQ09ORklHX0RDREJBUyBpcyBub3Qgc2V0CkNPTkZJR19ETUlJRD15CiMg Q09ORklHX0lTQ1NJX0lCRlRfRklORCBpcyBub3Qgc2V0CgojCiMgRmlsZSBzeXN0ZW1zCiMKQ09O RklHX0VYVDJfRlM9eQojIENPTkZJR19FWFQyX0ZTX1hBVFRSIGlzIG5vdCBzZXQKIyBDT05GSUdf RVhUMl9GU19YSVAgaXMgbm90IHNldApDT05GSUdfRVhUM19GUz15CiMgQ09ORklHX0VYVDNfREVG QVVMVFNfVE9fT1JERVJFRCBpcyBub3Qgc2V0CkNPTkZJR19FWFQzX0ZTX1hBVFRSPXkKIyBDT05G SUdfRVhUM19GU19QT1NJWF9BQ0wgaXMgbm90IHNldAojIENPTkZJR19FWFQzX0ZTX1NFQ1VSSVRZ IGlzIG5vdCBzZXQKQ09ORklHX0VYVDRfRlM9eQpDT05GSUdfRVhUNF9GU19YQVRUUj15CiMgQ09O RklHX0VYVDRfRlNfUE9TSVhfQUNMIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhUNF9GU19TRUNVUklU WSBpcyBub3Qgc2V0CiMgQ09ORklHX0VYVDRfREVCVUcgaXMgbm90IHNldApDT05GSUdfSkJEPXkK IyBDT05GSUdfSkJEX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0pCRDI9eQojIENPTkZJR19KQkQy X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0ZTX01CQ0FDSEU9eQpDT05GSUdfUkVJU0VSRlNfRlM9 bQojIENPTkZJR19SRUlTRVJGU19DSEVDSyBpcyBub3Qgc2V0CkNPTkZJR19SRUlTRVJGU19QUk9D X0lORk89eQpDT05GSUdfUkVJU0VSRlNfRlNfWEFUVFI9eQojIENPTkZJR19SRUlTRVJGU19GU19Q T1NJWF9BQ0wgaXMgbm90IHNldAojIENPTkZJR19SRUlTRVJGU19GU19TRUNVUklUWSBpcyBub3Qg c2V0CiMgQ09ORklHX0pGU19GUyBpcyBub3Qgc2V0CkNPTkZJR19YRlNfRlM9eQojIENPTkZJR19Y RlNfUVVPVEEgaXMgbm90IHNldAojIENPTkZJR19YRlNfUE9TSVhfQUNMIGlzIG5vdCBzZXQKQ09O RklHX1hGU19SVD15CiMgQ09ORklHX1hGU19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0dGUzJf RlMgaXMgbm90IHNldAojIENPTkZJR19PQ0ZTMl9GUyBpcyBub3Qgc2V0CkNPTkZJR19CVFJGU19G Uz1tCkNPTkZJR19CVFJGU19GU19QT1NJWF9BQ0w9eQojIENPTkZJR19OSUxGUzJfRlMgaXMgbm90 IHNldApDT05GSUdfRlNfUE9TSVhfQUNMPXkKQ09ORklHX0VYUE9SVEZTPXkKQ09ORklHX0ZJTEVf TE9DS0lORz15CkNPTkZJR19GU05PVElGWT15CiMgQ09ORklHX0ROT1RJRlkgaXMgbm90IHNldApD T05GSUdfSU5PVElGWV9VU0VSPXkKIyBDT05GSUdfRkFOT1RJRlkgaXMgbm90IHNldApDT05GSUdf UVVPVEE9eQojIENPTkZJR19RVU9UQV9ORVRMSU5LX0lOVEVSRkFDRSBpcyBub3Qgc2V0CkNPTkZJ R19QUklOVF9RVU9UQV9XQVJOSU5HPXkKIyBDT05GSUdfUVVPVEFfREVCVUcgaXMgbm90IHNldAoj IENPTkZJR19RRk1UX1YxIGlzIG5vdCBzZXQKIyBDT05GSUdfUUZNVF9WMiBpcyBub3Qgc2V0CkNP TkZJR19RVU9UQUNUTD15CkNPTkZJR19RVU9UQUNUTF9DT01QQVQ9eQojIENPTkZJR19BVVRPRlM0 X0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfRlVTRV9GUyBpcyBub3Qgc2V0CkNPTkZJR19HRU5FUklD X0FDTD15CgojCiMgQ2FjaGVzCiMKQ09ORklHX0ZTQ0FDSEU9eQojIENPTkZJR19GU0NBQ0hFX1NU QVRTIGlzIG5vdCBzZXQKIyBDT05GSUdfRlNDQUNIRV9ISVNUT0dSQU0gaXMgbm90IHNldAojIENP TkZJR19GU0NBQ0hFX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfRlNDQUNIRV9PQkpFQ1RfTElT VCBpcyBub3Qgc2V0CkNPTkZJR19DQUNIRUZJTEVTPXkKIyBDT05GSUdfQ0FDSEVGSUxFU19ERUJV RyBpcyBub3Qgc2V0CiMgQ09ORklHX0NBQ0hFRklMRVNfSElTVE9HUkFNIGlzIG5vdCBzZXQKCiMK IyBDRC1ST00vRFZEIEZpbGVzeXN0ZW1zCiMKQ09ORklHX0lTTzk2NjBfRlM9eQpDT05GSUdfSk9M SUVUPXkKQ09ORklHX1pJU09GUz15CkNPTkZJR19VREZfRlM9eQpDT05GSUdfVURGX05MUz15Cgoj CiMgRE9TL0ZBVC9OVCBGaWxlc3lzdGVtcwojCkNPTkZJR19GQVRfRlM9eQojIENPTkZJR19NU0RP U19GUyBpcyBub3Qgc2V0CkNPTkZJR19WRkFUX0ZTPXkKQ09ORklHX0ZBVF9ERUZBVUxUX0NPREVQ QUdFPTQzNwpDT05GSUdfRkFUX0RFRkFVTFRfSU9DSEFSU0VUPSJ1dGY4IgojIENPTkZJR19OVEZT X0ZTIGlzIG5vdCBzZXQKCiMKIyBQc2V1ZG8gZmlsZXN5c3RlbXMKIwpDT05GSUdfUFJPQ19GUz15 CkNPTkZJR19QUk9DX0tDT1JFPXkKQ09ORklHX1BST0NfU1lTQ1RMPXkKQ09ORklHX1BST0NfUEFH RV9NT05JVE9SPXkKQ09ORklHX1NZU0ZTPXkKQ09ORklHX1RNUEZTPXkKQ09ORklHX1RNUEZTX1BP U0lYX0FDTD15CkNPTkZJR19IVUdFVExCRlM9eQpDT05GSUdfSFVHRVRMQl9QQUdFPXkKQ09ORklH X0NPTkZJR0ZTX0ZTPXkKQ09ORklHX01JU0NfRklMRVNZU1RFTVM9eQojIENPTkZJR19BRkZTX0ZT IGlzIG5vdCBzZXQKIyBDT05GSUdfRUNSWVBUX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSEZTX0ZT IGlzIG5vdCBzZXQKIyBDT05GSUdfSEZTUExVU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0JFRlNf RlMgaXMgbm90IHNldAojIENPTkZJR19CRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19FRlNfRlMg aXMgbm90IHNldAojIENPTkZJR19MT0dGUyBpcyBub3Qgc2V0CiMgQ09ORklHX0NSQU1GUyBpcyBu b3Qgc2V0CiMgQ09ORklHX1NRVUFTSEZTIGlzIG5vdCBzZXQKIyBDT05GSUdfVlhGU19GUyBpcyBu b3Qgc2V0CiMgQ09ORklHX01JTklYX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfT01GU19GUyBpcyBu b3Qgc2V0CiMgQ09ORklHX1FOWDRGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1JPTUZTX0ZTIGlz IG5vdCBzZXQKIyBDT05GSUdfU1lTVl9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVFdPUktfRklM RVNZU1RFTVMgaXMgbm90IHNldAoKIwojIFBhcnRpdGlvbiBUeXBlcwojCkNPTkZJR19QQVJUSVRJ T05fQURWQU5DRUQ9eQpDT05GSUdfQUNPUk5fUEFSVElUSU9OPXkKQ09ORklHX0FDT1JOX1BBUlRJ VElPTl9DVU1BTkE9eQpDT05GSUdfQUNPUk5fUEFSVElUSU9OX0VFU09YPXkKQ09ORklHX0FDT1JO X1BBUlRJVElPTl9JQ1M9eQpDT05GSUdfQUNPUk5fUEFSVElUSU9OX0FERlM9eQpDT05GSUdfQUNP Uk5fUEFSVElUSU9OX1BPV0VSVEVDPXkKQ09ORklHX0FDT1JOX1BBUlRJVElPTl9SSVNDSVg9eQpD T05GSUdfT1NGX1BBUlRJVElPTj15CkNPTkZJR19BTUlHQV9QQVJUSVRJT049eQpDT05GSUdfQVRB UklfUEFSVElUSU9OPXkKQ09ORklHX01BQ19QQVJUSVRJT049eQpDT05GSUdfTVNET1NfUEFSVElU SU9OPXkKQ09ORklHX0JTRF9ESVNLTEFCRUw9eQpDT05GSUdfTUlOSVhfU1VCUEFSVElUSU9OPXkK Q09ORklHX1NPTEFSSVNfWDg2X1BBUlRJVElPTj15CkNPTkZJR19VTklYV0FSRV9ESVNLTEFCRUw9 eQojIENPTkZJR19MRE1fUEFSVElUSU9OIGlzIG5vdCBzZXQKQ09ORklHX1NHSV9QQVJUSVRJT049 eQpDT05GSUdfVUxUUklYX1BBUlRJVElPTj15CkNPTkZJR19TVU5fUEFSVElUSU9OPXkKQ09ORklH X0tBUk1BX1BBUlRJVElPTj15CkNPTkZJR19FRklfUEFSVElUSU9OPXkKQ09ORklHX1NZU1Y2OF9Q QVJUSVRJT049eQpDT05GSUdfTkxTPXkKQ09ORklHX05MU19ERUZBVUxUPSJ1dGY4IgpDT05GSUdf TkxTX0NPREVQQUdFXzQzNz15CkNPTkZJR19OTFNfQ09ERVBBR0VfNzM3PXkKQ09ORklHX05MU19D T0RFUEFHRV83NzU9eQpDT05GSUdfTkxTX0NPREVQQUdFXzg1MD15CkNPTkZJR19OTFNfQ09ERVBB R0VfODUyPXkKQ09ORklHX05MU19DT0RFUEFHRV84NTU9eQpDT05GSUdfTkxTX0NPREVQQUdFXzg1 Nz15CkNPTkZJR19OTFNfQ09ERVBBR0VfODYwPXkKQ09ORklHX05MU19DT0RFUEFHRV84NjE9eQpD T05GSUdfTkxTX0NPREVQQUdFXzg2Mj15CkNPTkZJR19OTFNfQ09ERVBBR0VfODYzPXkKQ09ORklH X05MU19DT0RFUEFHRV84NjQ9eQpDT05GSUdfTkxTX0NPREVQQUdFXzg2NT15CkNPTkZJR19OTFNf Q09ERVBBR0VfODY2PXkKQ09ORklHX05MU19DT0RFUEFHRV84Njk9eQpDT05GSUdfTkxTX0NPREVQ QUdFXzkzNj15CkNPTkZJR19OTFNfQ09ERVBBR0VfOTUwPXkKQ09ORklHX05MU19DT0RFUEFHRV85 MzI9eQpDT05GSUdfTkxTX0NPREVQQUdFXzk0OT15CkNPTkZJR19OTFNfQ09ERVBBR0VfODc0PXkK Q09ORklHX05MU19JU084ODU5Xzg9eQpDT05GSUdfTkxTX0NPREVQQUdFXzEyNTA9eQpDT05GSUdf TkxTX0NPREVQQUdFXzEyNTE9eQpDT05GSUdfTkxTX0FTQ0lJPXkKQ09ORklHX05MU19JU084ODU5 XzE9eQpDT05GSUdfTkxTX0lTTzg4NTlfMj15CkNPTkZJR19OTFNfSVNPODg1OV8zPXkKQ09ORklH X05MU19JU084ODU5XzQ9eQpDT05GSUdfTkxTX0lTTzg4NTlfNT15CkNPTkZJR19OTFNfSVNPODg1 OV82PXkKQ09ORklHX05MU19JU084ODU5Xzc9eQpDT05GSUdfTkxTX0lTTzg4NTlfOT15CkNPTkZJ R19OTFNfSVNPODg1OV8xMz15CkNPTkZJR19OTFNfSVNPODg1OV8xND15CkNPTkZJR19OTFNfSVNP ODg1OV8xNT15CkNPTkZJR19OTFNfS09JOF9SPXkKQ09ORklHX05MU19LT0k4X1U9eQpDT05GSUdf TkxTX1VURjg9eQojIENPTkZJR19ETE0gaXMgbm90IHNldAoKIwojIEtlcm5lbCBoYWNraW5nCiMK Q09ORklHX1RSQUNFX0lSUUZMQUdTX1NVUFBPUlQ9eQpDT05GSUdfUFJJTlRLX1RJTUU9eQojIENP TkZJR19FTkFCTEVfV0FSTl9ERVBSRUNBVEVEIGlzIG5vdCBzZXQKQ09ORklHX0VOQUJMRV9NVVNU X0NIRUNLPXkKQ09ORklHX0ZSQU1FX1dBUk49MjA0OApDT05GSUdfTUFHSUNfU1lTUlE9eQojIENP TkZJR19TVFJJUF9BU01fU1lNUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VOVVNFRF9TWU1CT0xTIGlz IG5vdCBzZXQKQ09ORklHX0RFQlVHX0ZTPXkKQ09ORklHX0hFQURFUlNfQ0hFQ0s9eQojIENPTkZJ R19ERUJVR19LRVJORUwgaXMgbm90IHNldAojIENPTkZJR19IQVJETE9DS1VQX0RFVEVDVE9SIGlz IG5vdCBzZXQKIyBDT05GSUdfU0xVQl9ERUJVR19PTiBpcyBub3Qgc2V0CkNPTkZJR19TTFVCX1NU QVRTPXkKIyBDT05GSUdfQktMIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BBUlNFX1JDVV9QT0lOVEVS IGlzIG5vdCBzZXQKQ09ORklHX1NUQUNLVFJBQ0U9eQpDT05GSUdfREVCVUdfQlVHVkVSQk9TRT15 CkNPTkZJR19ERUJVR19NRU1PUllfSU5JVD15CkNPTkZJR19BUkNIX1dBTlRfRlJBTUVfUE9JTlRF UlM9eQpDT05GSUdfRlJBTUVfUE9JTlRFUj15CkNPTkZJR19SQ1VfQ1BVX1NUQUxMX0RFVEVDVE9S PXkKQ09ORklHX1JDVV9DUFVfU1RBTExfVElNRU9VVD02MApDT05GSUdfUkNVX0NQVV9TVEFMTF9E RVRFQ1RPUl9SVU5OQUJMRT15CiMgQ09ORklHX1JDVV9DUFVfU1RBTExfVkVSQk9TRSBpcyBub3Qg c2V0CiMgQ09ORklHX0xLRFRNIGlzIG5vdCBzZXQKQ09ORklHX1NZU0NUTF9TWVNDQUxMX0NIRUNL PXkKQ09ORklHX1VTRVJfU1RBQ0tUUkFDRV9TVVBQT1JUPXkKQ09ORklHX05PUF9UUkFDRVI9eQpD T05GSUdfSEFWRV9GVU5DVElPTl9UUkFDRVI9eQpDT05GSUdfSEFWRV9GVU5DVElPTl9HUkFQSF9U UkFDRVI9eQpDT05GSUdfSEFWRV9GVU5DVElPTl9HUkFQSF9GUF9URVNUPXkKQ09ORklHX0hBVkVf RlVOQ1RJT05fVFJBQ0VfTUNPVU5UX1RFU1Q9eQpDT05GSUdfSEFWRV9EWU5BTUlDX0ZUUkFDRT15 CkNPTkZJR19IQVZFX0ZUUkFDRV9NQ09VTlRfUkVDT1JEPXkKQ09ORklHX0hBVkVfU1lTQ0FMTF9U UkFDRVBPSU5UUz15CkNPTkZJR19IQVZFX0NfUkVDT1JETUNPVU5UPXkKQ09ORklHX1JJTkdfQlVG RkVSPXkKQ09ORklHX0VWRU5UX1RSQUNJTkc9eQojIENPTkZJR19FVkVOVF9QT1dFUl9UUkFDSU5H X0RFUFJFQ0FURUQgaXMgbm90IHNldApDT05GSUdfQ09OVEVYVF9TV0lUQ0hfVFJBQ0VSPXkKQ09O RklHX1JJTkdfQlVGRkVSX0FMTE9XX1NXQVA9eQpDT05GSUdfVFJBQ0lORz15CkNPTkZJR19HRU5F UklDX1RSQUNFUj15CkNPTkZJR19UUkFDSU5HX1NVUFBPUlQ9eQpDT05GSUdfRlRSQUNFPXkKIyBD T05GSUdfRlVOQ1RJT05fVFJBQ0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfSVJRU09GRl9UUkFDRVIg aXMgbm90IHNldAojIENPTkZJR19QUkVFTVBUX1RSQUNFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1ND SEVEX1RSQUNFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZUUkFDRV9TWVNDQUxMUyBpcyBub3Qgc2V0 CkNPTkZJR19CUkFOQ0hfUFJPRklMRV9OT05FPXkKIyBDT05GSUdfUFJPRklMRV9BTk5PVEFURURf QlJBTkNIRVMgaXMgbm90IHNldAojIENPTkZJR19QUk9GSUxFX0FMTF9CUkFOQ0hFUyBpcyBub3Qg c2V0CiMgQ09ORklHX1NUQUNLX1RSQUNFUiBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0lPX1RS QUNFPXkKQ09ORklHX0tQUk9CRV9FVkVOVD15CiMgQ09ORklHX0ZUUkFDRV9TVEFSVFVQX1RFU1Qg aXMgbm90IHNldApDT05GSUdfTU1JT1RSQUNFPXkKIyBDT05GSUdfTU1JT1RSQUNFX1RFU1QgaXMg bm90IHNldAojIENPTkZJR19SSU5HX0JVRkZFUl9CRU5DSE1BUksgaXMgbm90IHNldAojIENPTkZJ R19QUk9WSURFX09IQ0kxMzk0X0RNQV9JTklUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlVJTERfRE9D U1JDIGlzIG5vdCBzZXQKIyBDT05GSUdfRFlOQU1JQ19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklH X0RNQV9BUElfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19BVE9NSUM2NF9TRUxGVEVTVCBpcyBu b3Qgc2V0CiMgQ09ORklHX0FTWU5DX1JBSUQ2X1RFU1QgaXMgbm90IHNldAojIENPTkZJR19TQU1Q TEVTIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfQVJDSF9LR0RCPXkKQ09ORklHX0hBVkVfQVJDSF9L TUVNQ0hFQ0s9eQojIENPTkZJR19URVNUX0tTVFJUT1ggaXMgbm90IHNldApDT05GSUdfU1RSSUNU X0RFVk1FTT15CiMgQ09ORklHX1g4Nl9WRVJCT1NFX0JPT1RVUCBpcyBub3Qgc2V0CkNPTkZJR19F QVJMWV9QUklOVEs9eQojIENPTkZJR19FQVJMWV9QUklOVEtfREJHUCBpcyBub3Qgc2V0CiMgQ09O RklHX0RFQlVHX1NFVF9NT0RVTEVfUk9OWCBpcyBub3Qgc2V0CiMgQ09ORklHX0lPTU1VX1NUUkVT UyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX01NSU9UUkFDRV9TVVBQT1JUPXkKQ09ORklHX0lPX0RF TEFZX1RZUEVfMFg4MD0wCkNPTkZJR19JT19ERUxBWV9UWVBFXzBYRUQ9MQpDT05GSUdfSU9fREVM QVlfVFlQRV9VREVMQVk9MgpDT05GSUdfSU9fREVMQVlfVFlQRV9OT05FPTMKQ09ORklHX0lPX0RF TEFZXzBYODA9eQojIENPTkZJR19JT19ERUxBWV8wWEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9f REVMQVlfVURFTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfTk9ORSBpcyBub3Qgc2V0 CkNPTkZJR19ERUZBVUxUX0lPX0RFTEFZX1RZUEU9MAojIENPTkZJR19PUFRJTUlaRV9JTkxJTklO RyBpcyBub3Qgc2V0CgojCiMgU2VjdXJpdHkgb3B0aW9ucwojCkNPTkZJR19LRVlTPXkKQ09ORklH X0tFWVNfREVCVUdfUFJPQ19LRVlTPXkKIyBDT05GSUdfU0VDVVJJVFlfRE1FU0dfUkVTVFJJQ1Qg aXMgbm90IHNldApDT05GSUdfU0VDVVJJVFk9eQojIENPTkZJR19TRUNVUklUWUZTIGlzIG5vdCBz ZXQKQ09ORklHX1NFQ1VSSVRZX05FVFdPUks9eQpDT05GSUdfU0VDVVJJVFlfTkVUV09SS19YRlJN PXkKIyBDT05GSUdfU0VDVVJJVFlfUEFUSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOVEVMX1RYVCBp cyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZX1NFTElOVVggaXMgbm90IHNldAojIENPTkZJR19T RUNVUklUWV9UT01PWU8gaXMgbm90IHNldAojIENPTkZJR19TRUNVUklUWV9BUFBBUk1PUiBpcyBu b3Qgc2V0CiMgQ09ORklHX0lNQSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX1NFQ1VSSVRZX0RB Qz15CkNPTkZJR19ERUZBVUxUX1NFQ1VSSVRZPSIiCkNPTkZJR19YT1JfQkxPQ0tTPXkKQ09ORklH X0FTWU5DX0NPUkU9eQpDT05GSUdfQVNZTkNfTUVNQ1BZPXkKQ09ORklHX0FTWU5DX1hPUj15CkNP TkZJR19BU1lOQ19QUT15CkNPTkZJR19BU1lOQ19SQUlENl9SRUNPVj15CkNPTkZJR19BU1lOQ19U WF9ESVNBQkxFX1BRX1ZBTF9ETUE9eQpDT05GSUdfQVNZTkNfVFhfRElTQUJMRV9YT1JfVkFMX0RN QT15CkNPTkZJR19DUllQVE89eQoKIwojIENyeXB0byBjb3JlIG9yIGhlbHBlcgojCkNPTkZJR19D UllQVE9fQUxHQVBJPXkKQ09ORklHX0NSWVBUT19BTEdBUEkyPXkKQ09ORklHX0NSWVBUT19BRUFE PXkKQ09ORklHX0NSWVBUT19BRUFEMj15CkNPTkZJR19DUllQVE9fQkxLQ0lQSEVSPXkKQ09ORklH X0NSWVBUT19CTEtDSVBIRVIyPXkKQ09ORklHX0NSWVBUT19IQVNIPXkKQ09ORklHX0NSWVBUT19I QVNIMj15CkNPTkZJR19DUllQVE9fUk5HPXkKQ09ORklHX0NSWVBUT19STkcyPXkKQ09ORklHX0NS WVBUT19QQ09NUD15CkNPTkZJR19DUllQVE9fUENPTVAyPXkKQ09ORklHX0NSWVBUT19NQU5BR0VS PXkKQ09ORklHX0NSWVBUT19NQU5BR0VSMj15CkNPTkZJR19DUllQVE9fTUFOQUdFUl9ESVNBQkxF X1RFU1RTPXkKQ09ORklHX0NSWVBUT19HRjEyOE1VTD15CkNPTkZJR19DUllQVE9fTlVMTD15CiMg Q09ORklHX0NSWVBUT19QQ1JZUFQgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1dPUktRVUVVRT15 CkNPTkZJR19DUllQVE9fQ1JZUFREPXkKQ09ORklHX0NSWVBUT19BVVRIRU5DPXkKIyBDT05GSUdf Q1JZUFRPX1RFU1QgaXMgbm90IHNldAoKIwojIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbiB3aXRo IEFzc29jaWF0ZWQgRGF0YQojCiMgQ09ORklHX0NSWVBUT19DQ00gaXMgbm90IHNldAojIENPTkZJ R19DUllQVE9fR0NNIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NFUUlWIGlzIG5vdCBzZXQK CiMKIyBCbG9jayBtb2RlcwojCkNPTkZJR19DUllQVE9fQ0JDPXkKIyBDT05GSUdfQ1JZUFRPX0NU UiBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19DVFMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRP X0VDQj15CiMgQ09ORklHX0NSWVBUT19MUlcgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fUENC QyBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19YVFMgaXMgbm90IHNldAoKIwojIEhhc2ggbW9k ZXMKIwpDT05GSUdfQ1JZUFRPX0hNQUM9eQojIENPTkZJR19DUllQVE9fWENCQyBpcyBub3Qgc2V0 CiMgQ09ORklHX0NSWVBUT19WTUFDIGlzIG5vdCBzZXQKCiMKIyBEaWdlc3QKIwpDT05GSUdfQ1JZ UFRPX0NSQzMyQz15CiMgQ09ORklHX0NSWVBUT19DUkMzMkNfSU5URUwgaXMgbm90IHNldAojIENP TkZJR19DUllQVE9fR0hBU0ggaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX01END15CkNPTkZJR19D UllQVE9fTUQ1PXkKQ09ORklHX0NSWVBUT19NSUNIQUVMX01JQz15CiMgQ09ORklHX0NSWVBUT19S TUQxMjggaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fUk1EMTYwIGlzIG5vdCBzZXQKIyBDT05G SUdfQ1JZUFRPX1JNRDI1NiBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19STUQzMjAgaXMgbm90 IHNldApDT05GSUdfQ1JZUFRPX1NIQTE9eQpDT05GSUdfQ1JZUFRPX1NIQTI1Nj15CkNPTkZJR19D UllQVE9fU0hBNTEyPXkKQ09ORklHX0NSWVBUT19UR1IxOTI9eQpDT05GSUdfQ1JZUFRPX1dQNTEy PXkKIyBDT05GSUdfQ1JZUFRPX0dIQVNIX0NMTVVMX05JX0lOVEVMIGlzIG5vdCBzZXQKCiMKIyBD aXBoZXJzCiMKQ09ORklHX0NSWVBUT19BRVM9eQpDT05GSUdfQ1JZUFRPX0FFU19YODZfNjQ9eQoj IENPTkZJR19DUllQVE9fQUVTX05JX0lOVEVMIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0FO VUJJUyBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19BUkM0IGlzIG5vdCBzZXQKIyBDT05GSUdf Q1JZUFRPX0JMT1dGSVNIIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NBTUVMTElBIGlzIG5v dCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NBU1Q1IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0NB U1Q2IGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19ERVM9eQojIENPTkZJR19DUllQVE9fRkNSWVBU IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX0tIQVpBRCBpcyBub3Qgc2V0CiMgQ09ORklHX0NS WVBUT19TQUxTQTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NBTFNBMjBfWDg2XzY0IGlz IG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NFRUQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9f U0VSUEVOVCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19URUEgaXMgbm90IHNldApDT05GSUdf Q1JZUFRPX1RXT0ZJU0g9eQpDT05GSUdfQ1JZUFRPX1RXT0ZJU0hfQ09NTU9OPXkKQ09ORklHX0NS WVBUT19UV09GSVNIX1g4Nl82ND15CgojCiMgQ29tcHJlc3Npb24KIwpDT05GSUdfQ1JZUFRPX0RF RkxBVEU9eQpDT05GSUdfQ1JZUFRPX1pMSUI9eQpDT05GSUdfQ1JZUFRPX0xaTz15CgojCiMgUmFu ZG9tIE51bWJlciBHZW5lcmF0aW9uCiMKQ09ORklHX0NSWVBUT19BTlNJX0NQUk5HPXkKIyBDT05G SUdfQ1JZUFRPX1VTRVJfQVBJX0hBU0ggaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fVVNFUl9B UElfU0tDSVBIRVIgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fSFcgaXMgbm90IHNldApDT05G SUdfSEFWRV9LVk09eQojIENPTkZJR19WSVJUVUFMSVpBVElPTiBpcyBub3Qgc2V0CkNPTkZJR19C SU5BUllfUFJJTlRGPXkKCiMKIyBMaWJyYXJ5IHJvdXRpbmVzCiMKQ09ORklHX1JBSUQ2X1BRPXkK Q09ORklHX0JJVFJFVkVSU0U9eQpDT05GSUdfR0VORVJJQ19GSU5EX0ZJUlNUX0JJVD15CkNPTkZJ R19HRU5FUklDX0ZJTkRfTkVYVF9CSVQ9eQpDT05GSUdfR0VORVJJQ19GSU5EX0xBU1RfQklUPXkK IyBDT05GSUdfQ1JDX0NDSVRUIGlzIG5vdCBzZXQKQ09ORklHX0NSQzE2PXkKQ09ORklHX0NSQ19U MTBESUY9eQpDT05GSUdfQ1JDX0lUVV9UPXkKQ09ORklHX0NSQzMyPXkKIyBDT05GSUdfQ1JDNyBp cyBub3Qgc2V0CkNPTkZJR19MSUJDUkMzMkM9eQpDT05GSUdfWkxJQl9JTkZMQVRFPXkKQ09ORklH X1pMSUJfREVGTEFURT15CkNPTkZJR19MWk9fQ09NUFJFU1M9eQpDT05GSUdfTFpPX0RFQ09NUFJF U1M9eQpDT05GSUdfWFpfREVDPXkKQ09ORklHX1haX0RFQ19YODY9eQpDT05GSUdfWFpfREVDX1BP V0VSUEM9eQpDT05GSUdfWFpfREVDX0lBNjQ9eQpDT05GSUdfWFpfREVDX0FSTT15CkNPTkZJR19Y Wl9ERUNfQVJNVEhVTUI9eQpDT05GSUdfWFpfREVDX1NQQVJDPXkKQ09ORklHX1haX0RFQ19CQ0o9 eQojIENPTkZJR19YWl9ERUNfVEVTVCBpcyBub3Qgc2V0CkNPTkZJR19URVhUU0VBUkNIPXkKQ09O RklHX1RFWFRTRUFSQ0hfS01QPXkKQ09ORklHX1RFWFRTRUFSQ0hfQk09eQpDT05GSUdfVEVYVFNF QVJDSF9GU009eQpDT05GSUdfSEFTX0lPTUVNPXkKQ09ORklHX0hBU19JT1BPUlQ9eQpDT05GSUdf SEFTX0RNQT15CkNPTkZJR19OTEFUVFI9eQo= --0016e64698baaac01704a518615e-- From stewart@flamingspork.com Tue Jun 7 00:48:09 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p575m8TA006241 for ; Tue, 7 Jun 2011 00:48:08 -0500 X-ASG-Debug-ID: 1307425686-467302230000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kaylee.flamingspork.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 935AFD0F36E for ; Mon, 6 Jun 2011 22:48:06 -0700 (PDT) Received: from kaylee.flamingspork.com (kaylee.flamingspork.com [74.207.245.61]) by cuda.sgi.com with ESMTP id xa52eXSIa6VABzrY for ; Mon, 06 Jun 2011 22:48:06 -0700 (PDT) Received: from willster (localhost [127.0.0.1]) by kaylee.flamingspork.com (Postfix) with ESMTPS id 620F1609E; Tue, 7 Jun 2011 05:47:33 +0000 (UTC) Received: by willster (Postfix, from userid 1000) id 10D6430BBA9C; Tue, 7 Jun 2011 15:48:05 +1000 (EST) From: Stewart Smith To: Kenneth Emerson , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Defragging XFS File Systems Subject: Re: Defragging XFS File Systems In-Reply-To: References: User-Agent: Notmuch/0.5-215-g5143e5e (http://notmuchmail.org) Emacs/23.2.1 (x86_64-pc-linux-gnu) Date: Tue, 07 Jun 2011 15:48:05 +1000 Message-ID: <8739jmjip6.fsf@flamingspork.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Barracuda-Connect: kaylee.flamingspork.com[74.207.245.61] X-Barracuda-Start-Time: 1307425687 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65712 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, 6 Jun 2011 22:52:48 -0500, Kenneth Emerson wrote: > I hadn't given much thought to fragmentation of my TV recordings volume > (XFS) until reading through some MythTV-users threads recently that > mentioned how fragmented an XFS file system could become. After running > xfs_db, I found out that my fs appeared to be quite bad: MythTV can end up with fragmentation on XFS due to an fsync() call that attempts to work raound limitations in ext3. Workarounds include: - allocsize mount parameter - patch mythtv source not to fsync (you could easily write a patch that only did fsync if not xfs... I've been meaning to do this for years... not enough hours in day). - run mythbackend with libeatmydata, thus disabling the fsync -- Stewart Smith From s.priebe@profihost.ag Tue Jun 7 01:00:53 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p5760qq2006493 for ; Tue, 7 Jun 2011 01:00:53 -0500 X-ASG-Debug-ID: 1307426450-2c7e01bc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server655-han.de-nserver.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 750E14A49CE for ; Mon, 6 Jun 2011 23:00:50 -0700 (PDT) Received: from server655-han.de-nserver.de (server655-han.de-nserver.de [85.158.177.45]) by cuda.sgi.com with ESMTP id JAQBTPvlCfpIegIE for ; Mon, 06 Jun 2011 23:00:50 -0700 (PDT) Received: (qmail 26955 invoked from network); 7 Jun 2011 08:00:49 +0200 Received: from fw-office.allied-internet.ag (HELO s.priebe-desktop) (85.158.179.66) (smtp-auth username hostmaster@profihost.com, mechanism plain) by server655-han.de-nserver.de (qpsmtpd/0.82) with ESMTPA; Tue, 07 Jun 2011 08:00:49 +0200 Message-ID: <4DEDBE91.1020000@profihost.ag> Date: Tue, 07 Jun 2011 08:00:49 +0200 From: Stefan Priebe - Profihost AG User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS crashes with shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr Subject: XFS crashes with shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-User-Auth: Auth by hostmaster@profihost.com through 85.158.179.66 X-Barracuda-Connect: server655-han.de-nserver.de[85.158.177.45] X-Barracuda-Start-Time: 1307426451 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0007 1.0000 -2.0164 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65713 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi, please HELP ME! We're seeing a really bad behaviour on one of our machines running vanilla 2.6.32.40 kernel. It freezes from time to time or processes starts to hang. At the same time the following message appears in the kernel log: shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-274207938304 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549059303168 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549500554116 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549360922112 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549407219078 shrink_slab: xfs_reclaim_inode_shrink+0x0/0x10d negative objects to delete nr=-549480231300 Any ideas? An xfs_repair says everything is fine. -- Regards, Stefan Priebe From gongfan193@gmail.com Tue Jun 7 01:36:37 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p576abmZ008292 for ; Tue, 7 Jun 2011 01:36:37 -0500 X-ASG-Debug-ID: 1307428595-27ed03e00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-gy0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 636881D711BC; Mon, 6 Jun 2011 23:36:35 -0700 (PDT) Received: from mail-gy0-f181.google.com (mail-gy0-f181.google.com [209.85.160.181]) by cuda.sgi.com with ESMTP id dxEf2Sljkx9WOaUC; Mon, 06 Jun 2011 23:36:35 -0700 (PDT) Received: by gyh4 with SMTP id 4so2188982gyh.26 for ; Mon, 06 Jun 2011 23:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ua66Uon978URchXvQEHCrtjHaWFsdLsr/5kPBOW20qA=; b=u347sVPq+ZFfq3SOAVpamYLyDZ+LAifiYxfsgA92WMa/5JJxCDdRRP0rzMGVOykhVY 7wgzX1VhQmIln7A3jPZ2g19gPAICZ20e/uGR7228AXGnaUX3GiQp5WU/dnYRgHWnJK8L x0o8GWMK+/V9Xo3GJhij1Azkfk3u+eshz633s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=D7IassbHyx30qsRcv8/Q87P3wknXP5oWAhCy1PJDgzIGkDtMN3APys9x75O4QeTGGw 66Aj1aB9uik+PTXUpDdgFdhJ7FI7QqMuJC/G86wxRIdN3tPms6e3vm+VSJp/dvdFjqKk R1cg2w/0+fES6K66JNfArXDo+j+Go9CCBoabE= Received: by 10.101.9.3 with SMTP id m3mr4636804ani.17.1307428595157; Mon, 06 Jun 2011 23:36:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.198.3 with HTTP; Mon, 6 Jun 2011 23:36:15 -0700 (PDT) In-Reply-To: References: From: Drunkard Zhang Date: Tue, 7 Jun 2011 14:36:15 +0800 Message-ID: X-ASG-Orig-Subj: Re: bug in xfs: can't recovery metadata log Subject: Re: bug in xfs: can't recovery metadata log To: Alex Elder , xfs-masters@oss.sgi.com, xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail-gy0-f181.google.com[209.85.160.181] X-Barracuda-Start-Time: 1307428596 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.02 X-Barracuda-Spam-Status: No, SCORE=-1.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, BSF_RULE_7582B, DKIM_SIGNED, DKIM_VERIFIED, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65715 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 0.50 BSF_RULE7568M Custom Rule 7568M 0.50 BSF_RULE_7582B Custom Rule 7582B X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean 2011/6/7 Drunkard Zhang : > The log recovery failure happened after a hard reboot, I did "mount > /dev/lg/log /mnt/temp/" twice, but the similar dmesg error. > > The xfs lives on LVM, with 4x2TB SATA II disk. > > The first time: > [ 1479.130446] XFS mounting filesystem dm-0 > [ 1479.226525] Starting XFS recovery on filesystem: dm-0 (logdev: interna= l) > [ 1506.217842] BUG: unable to handle kernel NULL pointer dereference > at 00000000000000f8 > [ 1506.218468] IP: [] xfs_cmn_err+0x6b/0x92 > [ 1506.218680] PGD 2175c4067 PUD 22f4ff067 PMD 0 > [ 1506.218887] Oops: 0000 [#1] PREEMPT SMP > [ 1506.219138] last sysfs file: /sys/devices/virtual/block/dm-0/dev > [ 1506.219345] CPU 1 > [ 1506.219353] Modules linked in: > [ 1506.219732] > [ 1506.219923] Pid: 21233, comm: mount Not tainted 2.6.38.5 #2 System > manufacturer S=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF/Z8NA-D6(C) > [ 1506.220989] RIP: 0010:[] =C2=A0[] > xfs_cmn_err+0x6b/0x92 > [ 1506.221424] RSP: 0018:ffff88021752da08 =C2=A0EFLAGS: 00010246 > [ 1506.221627] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8= 16be16c > [ 1506.221837] RDX: ffff88021752da28 RSI: ffffffff816bdced RDI: 000000000= 0000008 > [ 1506.222079] RBP: ffff88021752da88 R08: ffffffff816bdb79 R09: 000000000= 00005f6 > [ 1506.222289] R10: ffff8802177c32c0 R11: 00000530e8002000 R12: 000000000= 0000000 > [ 1506.222572] R13: ffffffff816be16c R14: ffff88021752db04 R15: 000000000= 00008e2 > [ 1506.222830] FS: =C2=A000007fa0c93d2740(0000) GS:ffff8800bf440000(0000) > knlGS:0000000000000000 > [ 1506.223265] CS: =C2=A00010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 1506.223471] CR2: 00000000000000f8 CR3: 000000021754e000 CR4: 000000000= 00006e0 > [ 1506.223728] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000= 0000000 > [ 1506.223938] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 000000000= 0000400 > [ 1506.224190] Process mount (pid: 21233, threadinfo ffff88021752c000, > task ffff88022e239440) > [ 1506.224585] Stack: > [ 1506.224776] =C2=A00000000000000020 ffff88021752da98 ffff88021752da38 > ffff88021752da48 > [ 1506.225216] =C2=A0ffffffff816be16c ffff88021752da08 2d0100008de51400 > ffffffff8122922b > [ 1506.225616] =C2=A0ffff880202000000 ffff8802176e8af0 ffffffff816bdb79 > 00000000000005f6 > [ 1506.226058] Call Trace: > [ 1506.226301] =C2=A0[] ? kmem_zone_zalloc+0x1f/0x30 > [ 1506.226549] =C2=A0[] xfs_error_report+0x39/0x40 > [ 1506.226805] =C2=A0[] ? xfs_free_extent+0x8e/0xae > [ 1506.227056] =C2=A0[] xfs_free_ag_extent+0x3e7/0x70b > [ 1506.227306] =C2=A0[] xfs_free_extent+0x8e/0xae > [ 1506.227514] =C2=A0[] xlog_recover_process_efi+0x113/= 0x16c > [ 1506.227724] =C2=A0[] ? xfs_trans_ail_cursor_set+0x15= /0x1c > [ 1506.227934] =C2=A0[] xlog_recover_process_efis+0x64/= 0xad > [ 1506.228182] =C2=A0[] xlog_recover_finish+0x15/0xb6 > [ 1506.228390] =C2=A0[] xfs_log_mount_finish+0x1b/0x1d > [ 1506.228597] =C2=A0[] xfs_mountfs+0x4ec/0x615 > [ 1506.228803] =C2=A0[] xfs_fs_fill_super+0x1e5/0x2e8 > [ 1506.229055] =C2=A0[] mount_bdev+0x13b/0x19e > [ 1506.229259] =C2=A0[] ? xfs_fs_fill_super+0x0/0x2e8 > [ 1506.229467] =C2=A0[] xfs_fs_mount+0x10/0x12 > [ 1506.229672] =C2=A0[] vfs_kern_mount+0xb8/0x1f3 > [ 1506.229877] =C2=A0[] do_kern_mount+0x48/0xd8 > [ 1506.230127] =C2=A0[] do_mount+0x729/0x791 > [ 1506.230375] =C2=A0[] ? memdup_user+0x43/0x63 > [ 1506.230629] =C2=A0[] ? strndup_user+0x39/0x4f > [ 1506.230834] =C2=A0[] sys_mount+0x83/0xbe > [ 1506.231080] =C2=A0[] system_call_fastpath+0x16/0x1b > [ 1506.231285] Code: 31 e4 48 8d 45 80 48 8d 55 10 48 89 45 a8 48 89 > 55 88 31 c0 48 8d 55 b0 c7 45 80 20 00 00 00 48 89 55 90 4c 89 6d a0 > 48 8d 55 a0 <48> 8b b3 f8 00 00 00 48 c7 c7 78 14 6c 81 e8 1f ff 2b 00 > 45 85 > [ 1506.232093] RIP =C2=A0[] xfs_cmn_err+0x6b/0x92 > [ 1506.232300] =C2=A0RSP > [ 1506.232498] CR2: 00000000000000f8 > [ 1506.233086] ---[ end trace 6ff9d0214348600a ]--- > > The second time: > [ =C2=A0725.637712] BUG: unable to handle kernel NULL pointer dereference > at 00000000000000f8 > [ =C2=A0725.638302] IP: [] xfs_cmn_err+0x6b/0x92 > [ =C2=A0725.638579] PGD 22b1d3067 PUD 22b21f067 PMD 0 > [ =C2=A0725.638787] Oops: 0000 [#1] PREEMPT SMP > [ =C2=A0725.638993] last sysfs file: /sys/devices/virtual/block/dm-0/dev > [ =C2=A0725.639202] CPU 0 > [ =C2=A0725.639210] Modules linked in: > [ =C2=A0725.639664] > [ =C2=A0725.639857] Pid: 2537, comm: mount Not tainted 2.6.38.5 #2 System > manufacturer S=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF= =C3=BF/Z8NA-D6(C) > [ =C2=A0725.640841] RIP: 0010:[] =C2=A0[] > xfs_cmn_err+0x6b/0x92 > [ =C2=A0725.641241] RSP: 0018:ffff88022b28ba08 =C2=A0EFLAGS: 00010246 > [ =C2=A0725.641512] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff= ffff816be16c > [ =C2=A0725.641723] RDX: ffff88022b28ba28 RSI: ffffffff816bdced RDI: 0000= 000000000008 > [ =C2=A0725.641936] RBP: ffff88022b28ba88 R08: ffffffff816bdb79 R09: 0000= 0000000005f6 > [ =C2=A0725.642148] R10: ffff8802217c9680 R11: 00000530e8002000 R12: 0000= 000000000000 > [ =C2=A0725.642428] R13: ffffffff816be16c R14: ffff88022b28bb04 R15: 0000= 0000000008e2 > [ =C2=A0725.642641] FS: =C2=A000007f857cd34740(0000) GS:ffff8800bf400000(= 0000) > knlGS:0000000000000000 > [ =C2=A0725.643041] CS: =C2=A00010 DS: 0000 ES: 0000 CR0: 000000008005003= b > [ =C2=A0725.643248] CR2: 00000000000000f8 CR3: 000000022b24a000 CR4: 0000= 0000000006f0 > [ =C2=A0725.643565] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000= 000000000000 > [ =C2=A0725.643778] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000= 000000000400 > [ =C2=A0725.643990] Process mount (pid: 2537, threadinfo ffff88022b28a000= , > task ffff88022e4f2f40) > [ =C2=A0725.644478] Stack: > [ =C2=A0725.644671] =C2=A00000000000000020 ffff88022b28ba98 ffff88022b28b= a38 > ffff88022b28ba48 > [ =C2=A0725.645072] =C2=A0ffffffff816be16c ffff88022b28ba08 2d0100008de51= 400 > ffffffff8122922b > [ =C2=A0725.645607] =C2=A0ffff880202000000 ffff88022b2d28c0 ffffffff816bd= b79 > 00000000000005f6 > [ =C2=A0725.646010] Call Trace: > [ =C2=A0725.646211] =C2=A0[] ? kmem_zone_zalloc+0x1f/0x= 30 > [ =C2=A0725.646491] =C2=A0[] xfs_error_report+0x39/0x40 > [ =C2=A0725.646700] =C2=A0[] ? xfs_free_extent+0x8e/0xa= e > [ =C2=A0725.646909] =C2=A0[] xfs_free_ag_extent+0x3e7/0= x70b > [ =C2=A0725.647119] =C2=A0[] xfs_free_extent+0x8e/0xae > [ =C2=A0725.647329] =C2=A0[] xlog_recover_process_efi+0= x113/0x16c > [ =C2=A0725.647632] =C2=A0[] ? xfs_trans_ail_cursor_set= +0x15/0x1c > [ =C2=A0725.647844] =C2=A0[] xlog_recover_process_efis+= 0x64/0xad > [ =C2=A0725.648056] =C2=A0[] xlog_recover_finish+0x15/0= xb6 > [ =C2=A0725.648266] =C2=A0[] xfs_log_mount_finish+0x1b/= 0x1d > [ =C2=A0725.648539] =C2=A0[] xfs_mountfs+0x4ec/0x615 > [ =C2=A0725.648747] =C2=A0[] xfs_fs_fill_super+0x1e5/0x= 2e8 > [ =C2=A0725.648958] =C2=A0[] mount_bdev+0x13b/0x19e > [ =C2=A0725.649164] =C2=A0[] ? xfs_fs_fill_super+0x0/0x= 2e8 > [ =C2=A0725.649438] =C2=A0[] xfs_fs_mount+0x10/0x12 > [ =C2=A0725.649646] =C2=A0[] vfs_kern_mount+0xb8/0x1f3 > [ =C2=A0725.649854] =C2=A0[] do_kern_mount+0x48/0xd8 > [ =C2=A0725.650063] =C2=A0[] do_mount+0x729/0x791 > [ =C2=A0725.650271] =C2=A0[] ? memdup_user+0x43/0x63 > [ =C2=A0725.650545] =C2=A0[] ? strndup_user+0x39/0x4f > [ =C2=A0725.650753] =C2=A0[] sys_mount+0x83/0xbe > [ =C2=A0725.650961] =C2=A0[] system_call_fastpath+0x16/= 0x1b > [ =C2=A0725.651169] Code: 31 e4 48 8d 45 80 48 8d 55 10 48 89 45 a8 48 89 > 55 88 31 c0 48 8d 55 b0 c7 45 80 20 00 00 00 48 89 55 90 4c 89 6d a0 > 48 8d 55 a0 <48> 8b b3 f8 00 00 00 48 c7 c7 78 14 6c 81 e8 1f ff 2b 00 > 45 85 > [ =C2=A0725.652012] RIP =C2=A0[] xfs_cmn_err+0x6b/0x92 > [ =C2=A0725.652221] =C2=A0RSP > [ =C2=A0725.652484] CR2: 00000000000000f8 > [ =C2=A0725.653295] ---[ end trace 1dadc2ff14d7c60f ]--- > With 2.6.39.1 too, output not the same thing. Here's console output: log1 ~ # mount /dev/lg/log /mnt/temp/ & [1] 3911 log1 ~ # mount: Structure needs cleaning [1]+ Exit 32 mount /dev/lg/log /mnt/temp/ Here's related dmesg: [ 123.634533] XFS (dm-0): Mounting Filesystem [ 123.640180] XFS (dm-0): Starting recovery (logdev: internal) [ 138.583463] XFS: Internal error XFS_WANT_CORRUPTED_GOTO at line 1540 of file fs/xfs/xfs_alloc.c. Caller 0xffffffff811eca7b [ 138.583465] [ 138.583470] Pid: 3911, comm: mount Not tainted 2.6.39.1 #1 [ 138.583472] Call Trace: [ 138.583484] [] xfs_error_report+0x38/0x3a [ 138.583489] [] ? xfs_free_extent+0xb8/0xdd [ 138.583493] [] ? xfs_alloc_lookup_eq+0x14/0x16 [ 138.583497] [] xfs_free_ag_extent+0x3dc/0x6b3 [ 138.583501] [] xfs_free_extent+0xb8/0xdd [ 138.583506] [] xlog_recover_process_efi+0x113/0x16c [ 138.583511] [] xlog_recover_process_efis+0x64/0xad [ 138.583516] [] xlog_recover_finish+0x15/0x8c [ 138.583520] [] xfs_log_mount_finish+0x1b/0x1d [ 138.583525] [] xfs_mountfs+0x487/0x5ab [ 138.583531] [] xfs_fs_fill_super+0x1b3/0x2b6 [ 138.583536] [] mount_bdev+0x138/0x19b [ 138.583540] [] ? xfs_mountfs_check_barriers+0x63/0x63 [ 138.583546] [] ? alloc_vfsmnt+0xa6/0x18c [ 138.583550] [] xfs_fs_mount+0x10/0x12 [ 138.583553] [] mount_fs+0x6b/0x14f [ 138.583558] [] ? __alloc_percpu+0xb/0xd [ 138.583563] [] vfs_kern_mount+0x60/0x98 [ 138.583567] [] do_kern_mount+0x48/0xd8 [ 138.583571] [] do_mount+0x6e1/0x744 [ 138.583575] [] ? memdup_user+0x43/0x63 [ 138.583578] [] ? strndup_user+0x39/0x4f [ 138.583582] [] sys_mount+0x83/0xbd [ 138.583589] [] system_call_fastpath+0x16/0x1b [ 138.583669] XFS (dm-0): Failed to recover EFIs [ 138.583672] XFS (dm-0): log mount finish failed From michael.monnerie@is.it-management.at Tue Jun 7 02:43:30 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p577hUim012518 for ; Tue, 7 Jun 2011 02:43:30 -0500 X-ASG-Debug-ID: 1307432603-5a4803140000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv14.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 15A9F14E4970; Tue, 7 Jun 2011 00:43:23 -0700 (PDT) Received: from mailsrv14.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id ymMmECNDjYnFPMZy; Tue, 07 Jun 2011 00:43:23 -0700 (PDT) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv14.zmi.at (Postfix) with ESMTPSA id 2E84617B; Tue, 7 Jun 2011 09:43:22 +0200 (CEST) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id 94CCF401C35; Tue, 7 Jun 2011 09:43:21 +0200 (CEST) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: bug in xfs: can't recovery metadata log Subject: Re: bug in xfs: can't recovery metadata log Date: Tue, 7 Jun 2011 09:43:18 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38.6-zmi; KDE/4.6.0; x86_64; ; ) Cc: Drunkard Zhang , Alex Elder , xfs-masters@oss.sgi.com, linux-kernel@vger.kernel.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1653724.kM9ukQj4WN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201106070943.21004@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1307432606 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65720 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --nextPart1653724.kM9ukQj4WN Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Dienstag, 7. Juni 2011 Drunkard Zhang wrote: > With 2.6.39.1 too, output not the same thing. I'm not a developer, but have you tries xfs_repair -n ? As you crashed,=20 probably the xfs log is damaged, needing a "xfs_repair -L", but wait for=20 a more competent answer before you do this. =2D-=20 mit freundlichen Gr=C3=BCssen, Michael Monnerie, Ing. BSc it-management Internet Services: Prot=C3=A9ger http://proteger.at [gesprochen: Prot-e-schee] Tel: +43 660 / 415 6531 // Haus zu verkaufen: http://zmi.at/langegg/ --nextPart1653724.kM9ukQj4WN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEABECAAYFAk3t1pgACgkQzhSR9xwSCbR3LQCggGekCvYKvSgMEnA7QXCP5bm7 q1QAoOOrZUa70PS2oeE7ZRTxGG9z4LIu =Tkyj -----END PGP SIGNATURE----- --nextPart1653724.kM9ukQj4WN-- From gongfan193@gmail.com Tue Jun 7 02:56:52 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p577uqv6012832 for ; Tue, 7 Jun 2011 02:56:52 -0500 X-ASG-Debug-ID: 1307433410-642b03070000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-gx0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D229A1E40A85; Tue, 7 Jun 2011 00:56:50 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by cuda.sgi.com with ESMTP id rZyNA6dH4OPc6qb1; Tue, 07 Jun 2011 00:56:50 -0700 (PDT) Received: by gxk9 with SMTP id 9so2390300gxk.26 for ; Tue, 07 Jun 2011 00:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sef3jJBL6oWeat6gtOCDRDZNBgQysNSCd25zK53KJZo=; b=kunnLWUuFqOtWkPlefc6NojOUwnOl1UkZPH8+jKNX00pk3GqXDe6dsGOVXeBh00wXz qlb/tXovdiVyWw7/KdY9e/xnd/LlX+imcYOeyAgawEQn/GEpR5EaKpp+ZzJYKySWwbtE Vt1B6zdGoKnpqnGbnw9bec8p+OLdIJj6OuA5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=pqMcDYdTe1TVZZ+OwTeb4rVsYhuozMRaYiZsApgexFwkIcT5nrcDs+h7jD3l2QG2D9 5XB4jp/Qf4ked4cFNAwiuvUtSyDicG/0XB/Q2RMIKohSAZGH+/6CZELkac8Mb4TbdfQf vGmSwXisA2kmnM1DSjcMRFgiv+VSOTi6bcyuY= Received: by 10.101.185.34 with SMTP id m34mr4524511anp.83.1307433410331; Tue, 07 Jun 2011 00:56:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.198.3 with HTTP; Tue, 7 Jun 2011 00:56:30 -0700 (PDT) In-Reply-To: <201106070943.21004@zmi.at> References: <201106070943.21004@zmi.at> From: Drunkard Zhang Date: Tue, 7 Jun 2011 15:56:30 +0800 Message-ID: X-ASG-Orig-Subj: Re: bug in xfs: can't recovery metadata log Subject: Re: bug in xfs: can't recovery metadata log To: Michael Monnerie Cc: xfs@oss.sgi.com, Alex Elder , xfs-masters@oss.sgi.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 X-Barracuda-Connect: mail-gx0-f181.google.com[209.85.161.181] X-Barracuda-Start-Time: 1307433411 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0002 1.0000 -2.0195 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65721 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean 2011/6/7 Michael Monnerie : > On Dienstag, 7. Juni 2011 Drunkard Zhang wrote: >> With 2.6.39.1 too, output not the same thing. > > I'm not a developer, but have you tries xfs_repair -n ? As you crashed, > probably the xfs log is damaged, needing a "xfs_repair -L", but wait for > a more competent answer before you do this. > Oops, I already did "xfs_repair -L", successed. It's in production environment, didn't have too much time to figure out why :-( From michael.monnerie@is.it-management.at Tue Jun 7 03:31:08 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p578V8xK013565 for ; Tue, 7 Jun 2011 03:31:08 -0500 X-ASG-Debug-ID: 1307435465-6d2803bd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv14.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5A1D94A4DDA; Tue, 7 Jun 2011 01:31:06 -0700 (PDT) Received: from mailsrv14.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id ThDeeU9msjiWZ36z; Tue, 07 Jun 2011 01:31:06 -0700 (PDT) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv14.zmi.at (Postfix) with ESMTPSA id 60CEA17B; Tue, 7 Jun 2011 10:31:05 +0200 (CEST) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id CA954401C35; Tue, 7 Jun 2011 10:31:03 +0200 (CEST) From: Michael Monnerie Organization: it-management http://it-management.at To: Drunkard Zhang X-ASG-Orig-Subj: Re: bug in xfs: can't recovery metadata log Subject: Re: bug in xfs: can't recovery metadata log Date: Tue, 7 Jun 2011 10:30:59 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38.6-zmi; KDE/4.6.0; x86_64; ; ) Cc: xfs@oss.sgi.com, Alex Elder , xfs-masters@oss.sgi.com, linux-kernel@vger.kernel.org References: <201106070943.21004@zmi.at> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9287929.ziTybSKarZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201106071031.02928@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1307435467 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65723 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --nextPart9287929.ziTybSKarZ Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Dienstag, 7. Juni 2011 Drunkard Zhang wrote: > Oops, I already did "xfs_repair -L", successed. It's in production > environment, didn't have too much time to figure out why :-( That was probably the only chance anyway. I'm wondering about the crash. Even if the log is full of shit because=20 of a crash, xfs should not drive to hell but better report the fact and=20 exit. But maybe such strict checking is not worth the effort, as every=20 competent admin does xfs_repair then anyway? =2D-=20 mit freundlichen Gr=C3=BCssen, Michael Monnerie, Ing. BSc it-management Internet Services: Prot=C3=A9ger http://proteger.at [gesprochen: Prot-e-schee] Tel: +43 660 / 415 6531 // Haus zu verkaufen: http://zmi.at/langegg/ --nextPart9287929.ziTybSKarZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEABECAAYFAk3t4cYACgkQzhSR9xwSCbSIygCffq+fnymmTsywcGoOx4vrrsdb E/0AoN/q5gfyXV5IhdJjdFGhMQRkVhdy =pbSI -----END PGP SIGNATURE----- --nextPart9287929.ziTybSKarZ-- From BATV+8efe31b41d7835736391+2844+infradead.org+hch@bombadil.srs.infradead.org Tue Jun 7 05:32:59 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57AWwM6017622 for ; Tue, 7 Jun 2011 05:32:59 -0500 X-ASG-Debug-ID: 1307442775-2132009b0000-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 84B801E40FA6; Tue, 7 Jun 2011 03:32:55 -0700 (PDT) Received: from bombadil.infradead.org (173-166-109-252-newengland.hfc.comcastbusiness.net [173.166.109.252]) by cuda.sgi.com with ESMTP id KDTYEFk46wCicg9F; Tue, 07 Jun 2011 03:32:55 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1QTtae-0005gb-Ro; Tue, 07 Jun 2011 10:32:52 +0000 Date: Tue, 7 Jun 2011 06:32:52 -0400 From: Christoph Hellwig To: Drunkard Zhang Cc: Alex Elder , xfs-masters@oss.sgi.com, xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: bug in xfs: can't recovery metadata log Subject: Re: bug in xfs: can't recovery metadata log Message-ID: <20110607103252.GA15140@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.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: 173-166-109-252-newengland.hfc.comcastbusiness.net[173.166.109.252] X-Barracuda-Start-Time: 1307442776 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65731 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Jun 07, 2011 at 01:20:23PM +0800, Drunkard Zhang wrote: > The log recovery failure happened after a hard reboot, I did "mount > /dev/lg/log /mnt/temp/" twice, but the similar dmesg error. > > The xfs lives on LVM, with 4x2TB SATA II disk. > > The first time: > [ 1479.130446] XFS mounting filesystem dm-0 > [ 1479.226525] Starting XFS recovery on filesystem: dm-0 (logdev: internal) > [ 1506.217842] BUG: unable to handle kernel NULL pointer dereference > at 00000000000000f8 [...] > [ 1506.220989] RIP: 0010:[] [] > xfs_cmn_err+0x6b/0x92 [...] > [ 1506.226301] [] ? kmem_zone_zalloc+0x1f/0x30 > [ 1506.226549] [] xfs_error_report+0x39/0x40 > [ 1506.226805] [] ? xfs_free_extent+0x8e/0xae > [ 1506.227056] [] xfs_free_ag_extent+0x3e7/0x70b > [ 1506.227306] [] xfs_free_extent+0x8e/0xae It looks like you hit one of the XFS_WANT_CORRUPTED_GOTO checks in xfs_error_report, and we hit something in there that isn't initialized that early during the mount process. My guess it's actually the mp->m_fsname dereference in xfs_fs_vcmn_err. It's fixed by the message rework in 2.6.39+, but that will only prevent the crash, you'll still get an error and the log recovery will be aborted. If you can get a more recent kernel on the box I'd be curious what the output form it is. Did you run older kernels on this machine before? Before 2.6.33 device mapper support for barriers (aka cache flushes) was incomplete and frequently led to free space corruption if people left the volatile write caches on. For MD underneath it event took a bit longer. If you just want to continue using the filesystem you can nuke the log using xfs_repair -L. From s.priebe@profihost.ag Tue Jun 7 06:42:35 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57BgYrO023032 for ; Tue, 7 Jun 2011 06:42:35 -0500 X-ASG-Debug-ID: 1307446951-23bc03490000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server655-han.de-nserver.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EBAAE1ED510B for ; Tue, 7 Jun 2011 04:42:31 -0700 (PDT) Received: from server655-han.de-nserver.de (server655-han.de-nserver.de [85.158.177.45]) by cuda.sgi.com with ESMTP id tkxQFvhLS4AARHbC for ; Tue, 07 Jun 2011 04:42:31 -0700 (PDT) Received: (qmail 13738 invoked from network); 7 Jun 2011 13:42:29 +0200 Received: from fw-office.allied-internet.ag (HELO s.priebe-desktop) (85.158.179.66) (smtp-auth username hostmaster@profihost.com, mechanism plain) by server655-han.de-nserver.de (qpsmtpd/0.82) with ESMTPA; Tue, 07 Jun 2011 13:42:29 +0200 Message-ID: <4DEE0EA4.9090002@profihost.ag> Date: Tue, 07 Jun 2011 13:42:28 +0200 From: Stefan Priebe - Profihost AG User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS: accounting of reclaimable inodes is incorrect Subject: XFS: accounting of reclaimable inodes is incorrect Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-User-Auth: Auth by hostmaster@profihost.com through 85.158.179.66 X-Barracuda-Connect: server655-han.de-nserver.de[85.158.177.45] X-Barracuda-Start-Time: 1307446952 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0763 1.0000 -1.5363 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.54 X-Barracuda-Spam-Status: No, SCORE=-1.54 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65735 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi, it seems that a bug was backported into the latest 2.6.32 longterm stable kernel. Now the patch "XFS: accounting of reclaimable inodes is incorrect" needs to get backported to 2.6.32. Who can help? Who is responsible? Please CC me i'm not on list. -- Greets, Stefan From BATV+8efe31b41d7835736391+2844+infradead.org+hch@bombadil.srs.infradead.org Tue Jun 7 06:54:45 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57Bsiac023393 for ; Tue, 7 Jun 2011 06:54:45 -0500 X-ASG-Debug-ID: 1307447683-5fc402c60000-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 0C93615DF3F1 for ; Tue, 7 Jun 2011 04:54:43 -0700 (PDT) Received: from bombadil.infradead.org (173-166-109-252-newengland.hfc.comcastbusiness.net [173.166.109.252]) by cuda.sgi.com with ESMTP id shxGZTmTHKusOXyE for ; Tue, 07 Jun 2011 04:54:43 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1QTurq-0001DH-0p; Tue, 07 Jun 2011 11:54:42 +0000 Date: Tue, 7 Jun 2011 07:54:42 -0400 From: Christoph Hellwig To: Stefan Priebe - Profihost AG Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: accounting of reclaimable inodes is incorrect Subject: Re: XFS: accounting of reclaimable inodes is incorrect Message-ID: <20110607115441.GA4653@infradead.org> References: <4DEE0EA4.9090002@profihost.ag> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DEE0EA4.9090002@profihost.ag> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: 173-166-109-252-newengland.hfc.comcastbusiness.net[173.166.109.252] X-Barracuda-Start-Time: 1307447684 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65736 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Jun 07, 2011 at 01:42:28PM +0200, Stefan Priebe - Profihost AG wrote: > Hi, > > it seems that a bug was backported into the latest 2.6.32 longterm > stable kernel. Now the patch "XFS: accounting of reclaimable inodes > is incorrect" needs to get backported to 2.6.32. > > Who can help? Who is responsible? For -stable releases no one really is. If you want to help you can backport it and send it to the stable mailinglist. From stan@hardwarefreak.com Tue Jun 7 07:05:55 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57C5t7l023690 for ; Tue, 7 Jun 2011 07:05:55 -0500 X-ASG-Debug-ID: 1307448353-09af002f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9AF2B1ED523F for ; Tue, 7 Jun 2011 05:05:54 -0700 (PDT) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id KEMlQswfAnXA91uj for ; Tue, 07 Jun 2011 05:05:54 -0700 (PDT) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id 4A5076C0A2; Tue, 7 Jun 2011 07:05:53 -0500 (CDT) Message-ID: <4DEE1422.7060902@hardwarefreak.com> Date: Tue, 07 Jun 2011 07:05:54 -0500 From: Stan Hoeppner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kenneth Emerson CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Defragging XFS File Systems Subject: Re: Defragging XFS File Systems References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-65-41-216-221.sta.embarqhsd.net[65.41.216.221] X-Barracuda-Start-Time: 1307448354 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65737 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/6/2011 10:52 PM, Kenneth Emerson wrote: > I hadn't given much thought to fragmentation of my TV recordings volume > (XFS) until reading through some MythTV-users threads recently that > mentioned how fragmented an XFS file system could become. After running > xfs_db, I found out that my fs appeared to be quite bad: > > $ sudo xfs_db -c frag -r /dev/mapper/appl_vg-appl_lv > actual 1138668, ideal 11023, fragmentation factor 99.03% > > I then ran xfs_fsr with all defaults (ran for two hours) and then re-ran >From man xfs_fsr: It runs for up to two hours after which it records the filesystem where it left off, so it can start there the next time. This information is stored in the file /var/tmp/.fsrlast_xfs. If the information found here is somehow inconsistent or out of date it is ignored and reorganization starts at the beginning of the first filesystem found in /etc/mtab. If xfs_fsr stopped at 2 hours, multiple additional runs will likely be required to get good defragmentation. > xfs_db and got the following results: > > $ sudo xfs_db -c frag -r /dev/mapper/appl_vg-appl_lv The -r above suggests you created a large realtime section for your MythTV storage. It may be helpful for you to provide xfs_info output for the heavily fragmented filesystem. > invalid numrecs (27111) in bmapbtd block > invalid numrecs (4716) in bmapbtd block > invalid numrecs (58978) in bmapbtd block I'll leave these errors for one of the devs to tackle. > actual 1034793, ideal 11024, fragmentation factor 98.93% > > The fragmentation level was reduced, It was likely reduced much more than this. Dropping caches or unmounting and remounting the filesystem is often necessary after running xfs_fsr in order to show the actual fragmentation level. Try: # echo 3 > /proc/sys/vm/drop_caches and then run xfs_db again. > but I was concerned about the error > messages. Before I go any further, am I corrupting my file system with the > defragging or are these "invalid numrecs" messages unimportant? Run 'xfs_check' or 'xfs_repair -n' and post the results. -- Stan From BATV+8efe31b41d7835736391+2844+infradead.org+hch@bombadil.srs.infradead.org Tue Jun 7 07:06:29 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57C6SL2023728 for ; Tue, 7 Jun 2011 07:06:29 -0500 X-ASG-Debug-ID: 1307448387-5a0f039b0000-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 B471CD785F9 for ; Tue, 7 Jun 2011 05:06:27 -0700 (PDT) Received: from bombadil.infradead.org (173-166-109-252-newengland.hfc.comcastbusiness.net [173.166.109.252]) by cuda.sgi.com with ESMTP id Myo347V2BveFy9sc for ; Tue, 07 Jun 2011 05:06:27 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1QTv38-0003UK-T2; Tue, 07 Jun 2011 12:06:22 +0000 Date: Tue, 7 Jun 2011 08:06:22 -0400 From: Christoph Hellwig To: Allison Henderson Cc: Christoph Hellwig , Allison Henderson , linux-fsdevel , Ext4 Developers List , xfs-oss X-ASG-Orig-Subj: Re: Fwd: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX Subject: Re: Fwd: [XFSTEST Add Fallocate Punch Hole Tests 1/3 v4] Add Punch Hole to FSX Message-ID: <20110607120622.GA13357@infradead.org> References: <4DE93268.90007@linux.vnet.ibm.com> <20110606150323.GB22236@infradead.org> <4DED1155.4060503@vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DED1155.4060503@vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: 173-166-109-252-newengland.hfc.comcastbusiness.net[173.166.109.252] X-Barracuda-Start-Time: 1307448387 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65738 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This and the new patchset look quite a bit better. I'll try to get some time to review the patches soon, thanks! From s.priebe@profihost.ag Tue Jun 7 07:58:38 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57CwbFs025077 for ; Tue, 7 Jun 2011 07:58:38 -0500 X-ASG-Debug-ID: 1307451514-5a5000600000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server655-han.de-nserver.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AA2551664109 for ; Tue, 7 Jun 2011 05:58:35 -0700 (PDT) Received: from server655-han.de-nserver.de (server655-han.de-nserver.de [85.158.177.45]) by cuda.sgi.com with ESMTP id U9jxHLv7WHOs9KBG for ; Tue, 07 Jun 2011 05:58:35 -0700 (PDT) Received: (qmail 9955 invoked from network); 7 Jun 2011 14:58:33 +0200 Received: from fw-office.allied-internet.ag (HELO s.priebe-desktop) (85.158.179.66) (smtp-auth username hostmaster@profihost.com, mechanism plain) by server655-han.de-nserver.de (qpsmtpd/0.82) with ESMTPA; Tue, 07 Jun 2011 14:58:33 +0200 Message-ID: <4DEE2078.3010102@profihost.ag> Date: Tue, 07 Jun 2011 14:58:32 +0200 From: Stefan Priebe - Profihost AG User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: accounting of reclaimable inodes is incorrect Subject: Re: XFS: accounting of reclaimable inodes is incorrect References: <4DEE0EA4.9090002@profihost.ag> <20110607115441.GA4653@infradead.org> In-Reply-To: <20110607115441.GA4653@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-User-Auth: Auth by hostmaster@profihost.com through 85.158.179.66 X-Barracuda-Connect: server655-han.de-nserver.de[85.158.177.45] X-Barracuda-Start-Time: 1307451516 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0152 1.0000 -1.9222 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65740 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean >> it seems that a bug was backported into the latest 2.6.32 longterm >> stable kernel. Now the patch "XFS: accounting of reclaimable inodes >> is incorrect" needs to get backported to 2.6.32. >> >> Who can help? Who is responsible? > > For -stable releases no one really is. If you want to help you can > backport it and send it to the stable mailinglist. Sorry i can't. I'm not a kernel hacker. But i think a real bug / showstopper should be fixed in a longterm stable kernel. Redhat seems to have fixed it on it's own: https://bugzilla.redhat.com/show_bug.cgi?id=642680 Sadly they haven't provided a patch. Greets Stefan From BATV+8efe31b41d7835736391+2844+infradead.org+hch@bombadil.srs.infradead.org Tue Jun 7 08:34:31 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57DYUTx026024 for ; Tue, 7 Jun 2011 08:34:31 -0500 X-ASG-Debug-ID: 1307453669-152f01be0000-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 411184A5B99 for ; Tue, 7 Jun 2011 06:34:29 -0700 (PDT) Received: from bombadil.infradead.org (173-166-109-252-newengland.hfc.comcastbusiness.net [173.166.109.252]) by cuda.sgi.com with ESMTP id NbueBSv4btKZy0Ns for ; Tue, 07 Jun 2011 06:34:29 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1QTwQP-0002NF-7W; Tue, 07 Jun 2011 13:34:29 +0000 Date: Tue, 7 Jun 2011 09:34:29 -0400 From: Christoph Hellwig To: Stefan Priebe - Profihost AG Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: accounting of reclaimable inodes is incorrect Subject: Re: XFS: accounting of reclaimable inodes is incorrect Message-ID: <20110607133429.GA9049@infradead.org> References: <4DEE0EA4.9090002@profihost.ag> <20110607115441.GA4653@infradead.org> <4DEE2078.3010102@profihost.ag> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DEE2078.3010102@profihost.ag> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: 173-166-109-252-newengland.hfc.comcastbusiness.net[173.166.109.252] X-Barracuda-Start-Time: 1307453670 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65743 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Jun 07, 2011 at 02:58:32PM +0200, Stefan Priebe - Profihost AG wrote: > Sorry i can't. I'm not a kernel hacker. But i think a real bug / > showstopper should be fixed in a longterm stable kernel. Linux 2.6.32 isn't really something supported by us. It's not just a very old codebase, but also one where a lot of the XFS code was pretty much in flux. If you want supported old releases work use one of the commercially supported one like RedHat or SuSE. > Redhat seems to have fixed it on it's own: > https://bugzilla.redhat.com/show_bug.cgi?id=642680 I suspect the upstream commit you want is 081003fff467ea0e727f66d5d435b4f473a789b3, but I can't gurantee this actually applies to the 2.6.32 codebase. From s.priebe@profihost.ag Tue Jun 7 08:48:42 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57DmgZY026373 for ; Tue, 7 Jun 2011 08:48:42 -0500 X-ASG-Debug-ID: 1307454520-3a3e029f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server655-han.de-nserver.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A8B0E1ED5D66 for ; Tue, 7 Jun 2011 06:48:40 -0700 (PDT) Received: from server655-han.de-nserver.de (server655-han.de-nserver.de [85.158.177.45]) by cuda.sgi.com with ESMTP id 0LKuljsfZ8gWXh1F for ; Tue, 07 Jun 2011 06:48:40 -0700 (PDT) Received: (qmail 31223 invoked from network); 7 Jun 2011 15:48:39 +0200 Received: from fw-office.allied-internet.ag (HELO s.priebe-desktop) (85.158.179.66) (smtp-auth username hostmaster@profihost.com, mechanism plain) by server655-han.de-nserver.de (qpsmtpd/0.82) with ESMTPA; Tue, 07 Jun 2011 15:48:39 +0200 Message-ID: <4DEE2C36.8030008@profihost.ag> Date: Tue, 07 Jun 2011 15:48:38 +0200 From: Stefan Priebe - Profihost AG User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: accounting of reclaimable inodes is incorrect Subject: Re: XFS: accounting of reclaimable inodes is incorrect References: <4DEE0EA4.9090002@profihost.ag> <20110607115441.GA4653@infradead.org> <4DEE2078.3010102@profihost.ag> <20110607133429.GA9049@infradead.org> In-Reply-To: <20110607133429.GA9049@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-User-Auth: Auth by hostmaster@profihost.com through 85.158.179.66 X-Barracuda-Connect: server655-han.de-nserver.de[85.158.177.45] X-Barracuda-Start-Time: 1307454521 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0058 1.0000 -1.9834 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.98 X-Barracuda-Spam-Status: No, SCORE=-1.98 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65743 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Am 07.06.2011 15:34, schrieb Christoph Hellwig: > On Tue, Jun 07, 2011 at 02:58:32PM +0200, Stefan Priebe - Profihost AG wrote: > Linux 2.6.32 isn't really something supported by us. It's not just a > very old codebase, but also one where a lot of the XFS code was pretty > much in flux. If you want supported old releases work use one of > the commercially supported one like RedHat or SuSE. OK so my thought was totally wrong. I thought the longterm stable releases will still get bugfixed by SGI or whoever wrote the stuff. Sorry for that then. But what is then the idea of a longterm stable? >> Redhat seems to have fixed it on it's own: >> https://bugzilla.redhat.com/show_bug.cgi?id=642680 > > I suspect the upstream commit you want is > 081003fff467ea0e727f66d5d435b4f473a789b3, but I can't gurantee this > actually applies to the 2.6.32 codebase. No it doesn't. I already tried to implement it into current 2.6.32.41 code. Greets Stefan From dhoworth@mrc-lmb.cam.ac.uk Tue Jun 7 09:00:15 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57E0DPc026784 for ; Tue, 7 Jun 2011 09:00:14 -0500 X-ASG-Debug-ID: 1307455211-5a4d02920000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ppsw-51.csi.cam.ac.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4BB6412D1187 for ; Tue, 7 Jun 2011 07:00:11 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by cuda.sgi.com with ESMTP id hmAvPILU7T00cpM5 for ; Tue, 07 Jun 2011 07:00:11 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mail.mrc-lmb.cam.ac.uk ([131.111.85.9]:38173 helo=mail.lmb.internal) by ppsw-51.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp id 1QTwpG-0007yN-Z4 (Exim 4.72) for xfs@oss.sgi.com (return-path ); Tue, 07 Jun 2011 15:00:10 +0100 Received: from cpepc210-3.lmb.internal ([10.14.0.2]) by mail.lmb.internal with esmtp (Exim 4.63) (envelope-from ) id 1QTwpG-00054D-PE for xfs@oss.sgi.com; Tue, 07 Jun 2011 15:00:10 +0100 Message-ID: <4DEE2EEA.3080705@mrc-lmb.cam.ac.uk> Date: Tue, 07 Jun 2011 15:00:10 +0100 From: Dave Howorth Organization: MRC Centre for Protein Engineering User-Agent: Thunderbird 1.5.0.10 (X11/20060911) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: accounting of reclaimable inodes is incorrect Subject: Re: XFS: accounting of reclaimable inodes is incorrect References: <4DEE0EA4.9090002@profihost.ag> <20110607115441.GA4653@infradead.org> <4DEE2078.3010102@profihost.ag> <20110607133429.GA9049@infradead.org> In-Reply-To: <20110607133429.GA9049@infradead.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ppsw-51.csi.cam.ac.uk[131.111.8.151] X-Barracuda-Start-Time: 1307455212 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0002 1.0000 -2.0198 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65744 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > Linux 2.6.32 isn't really something supported by us. It's not just a > very old codebase, but also one where a lot of the XFS code was pretty > much in flux. If you want supported old releases work use one of > the commercially supported one like RedHat or SuSE. 2.6.32 is also the kernel in Ubuntu 10.04 LTS From BATV+8efe31b41d7835736391+2844+infradead.org+hch@bombadil.srs.infradead.org Tue Jun 7 09:09:52 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57E9q3G027057 for ; Tue, 7 Jun 2011 09:09:52 -0500 X-ASG-Debug-ID: 1307455791-23f902320000-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 0F3C94A6352 for ; Tue, 7 Jun 2011 07:09:51 -0700 (PDT) Received: from bombadil.infradead.org (173-166-109-252-newengland.hfc.comcastbusiness.net [173.166.109.252]) by cuda.sgi.com with ESMTP id hL6NvN4IKV8A3SIy for ; Tue, 07 Jun 2011 07:09:51 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1QTwyb-0008Gl-Mq; Tue, 07 Jun 2011 14:09:49 +0000 Date: Tue, 7 Jun 2011 10:09:49 -0400 From: Christoph Hellwig To: Stefan Priebe - Profihost AG Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: accounting of reclaimable inodes is incorrect Subject: Re: XFS: accounting of reclaimable inodes is incorrect Message-ID: <20110607140949.GA31769@infradead.org> References: <4DEE0EA4.9090002@profihost.ag> <20110607115441.GA4653@infradead.org> <4DEE2078.3010102@profihost.ag> <20110607133429.GA9049@infradead.org> <4DEE2C36.8030008@profihost.ag> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DEE2C36.8030008@profihost.ag> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: 173-166-109-252-newengland.hfc.comcastbusiness.net[173.166.109.252] X-Barracuda-Start-Time: 1307455792 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65745 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Jun 07, 2011 at 03:48:38PM +0200, Stefan Priebe - Profihost AG wrote: > Am 07.06.2011 15:34, schrieb Christoph Hellwig: > >On Tue, Jun 07, 2011 at 02:58:32PM +0200, Stefan Priebe - Profihost AG wrote: > >Linux 2.6.32 isn't really something supported by us. It's not just a > >very old codebase, but also one where a lot of the XFS code was pretty > >much in flux. If you want supported old releases work use one of > >the commercially supported one like RedHat or SuSE. > OK so my thought was totally wrong. I thought the longterm stable > releases will still get bugfixed by SGI or whoever wrote the stuff. > Sorry for that then. But what is then the idea of a longterm stable? I have no idea what the idea is, but it's clearly not viable for normal kernel developers. Backporting code to age old releases and QAing it is a major effort, and people generally don't do it unless they are paid for it. From pg_mh@sabi.co.UK Tue Jun 7 09:11:12 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57EBCmJ027107 for ; Tue, 7 Jun 2011 09:11:12 -0500 X-ASG-Debug-ID: 1307455869-3a1501160000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hermes1.dur.ac.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D73B94A636B for ; Tue, 7 Jun 2011 07:11:09 -0700 (PDT) Received: from hermes1.dur.ac.uk (hermes1.dur.ac.uk [129.234.248.1]) by cuda.sgi.com with ESMTP id YBKDZE0cqBMMZ4js for ; Tue, 07 Jun 2011 07:11:09 -0700 (PDT) Received: from smtphost3.dur.ac.uk (smtphost3.dur.ac.uk [129.234.252.3]) by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id p57E9aF8019756; Tue, 7 Jun 2011 15:09:40 +0100 Received: from ty.sabi.co.UK (o1.phyip3.dur.ac.uk [129.234.186.1]) by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id p57E9Hng022076 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 7 Jun 2011 15:09:17 +0100 Received: from from [127.0.0.1] (helo=tree.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.71 #1) id 1QTwy0-0006Sf-0v; Tue, 07 Jun 2011 15:09:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19950.12549.541440.285348@tree.ty.sabi.co.UK> Date: Tue, 7 Jun 2011 15:09:09 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general In-Reply-To: <201106060929.06814@zmi.at> References: <19945.24042.711472.158523@tree.ty.sabi.co.UK> <201106060929.06814@zmi.at> X-Mailer: VM 8.0.13 under 23.1.1 (x86_64-pc-linux-gnu) From: pg_mh@sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean X-DurhamAcUk-MailScanner-ID: p57E9aF8019756 X-Barracuda-Connect: hermes1.dur.ac.uk[129.234.248.1] X-Barracuda-Start-Time: 1307455870 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65745 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean [ ... ] >> vm/dirty_ratio=2 >> vm/dirty_bytes=400000000 >> >> vm/dirty_background_ratio=60 >> vm/dirty_background_bytes=0 > Why dirty_background_ratio=60? This would mean you start to > write dirty pages only after it reaches 60% of total system > memory... Oops, invert 'dirty_background_*' and 'dirty_*', I was writing from memory and got it the wrong way round. These are BTW my notes in my 'sysctl.conf', with pointer to a nice discussion: # http://www.westnet.com/~gsmith/content/linux-pdflush.htm # dirty_ratio # If more than this percentage of active memory is unflushed then # *all* processes that are writing start writing synchronously. # dirty_background_ratio # If more than this percentage of active memory is unflushed the # system starts flushing. # dirty_expire_centisecs # How long a page can be dirty before it gets flushed. # dirty_writeback_centisecs # How often the flusher runs. # In 'mm/pagewriteback.c' there is code that makes sure that in effect # the 'dirty_background_ratio' must be smaller (half if larger or equal) # than the 'dirty_ratio', and other code to put lower limits on # 'dirty_writeback_centisecs' and whatever. > [ ... '*_bytes' and '*_ratio' Maybe you specified both to fit > older and newer kernels in one example? Yes. I had written what I thought was a much simpler/neater change here: http://www.sabi.co.uk/blog/0707jul.html#070701 but I currently put in both versions and let the better one win :-). >> vm/dirty_expire_centisecs=200 >> vm/dirty_writeback_centisecs=400 > dirty_expire_centisecs to 200 means a sync every 2s, which > might be good in this specific setup mentioned here, Not quite, see above. There are times where I think the values should be the other way round (run the flusher every 2s and flush pages dirty for more than 4s). > but not for a generic server. Uhmmm, I am not so sure. Because I think that flushes should be related to IO speed, and even on a smaller system 2 seconds of IO are a lot of data. Quite a few traditional Linux (and Unix) tunables are set to defaults from a time where hardware was much slower. I started using UNIX when there was no 'update' daemon, and I got into the habit which I still have of typing 'sync' explicitly every now and then, and then when 'update' was introduced to do 'sync' every 30s there was not a lot of data one could lose in those 30s. > That would defeat XFS's in-memory grouping of blocks before > writeout, and in case of many parallel (slow|ftp) uploads > could lead to much more data fragmentation, or no? Well, it depends on what "fragmentation" means here. It is a long standing item of discussion. It is nice to see a 10GB file all in one extent, but is it *necessary*? As long as a file is composed of fairly large contiguous extents and they are not themselves widely scattered, things are going to be fine. What matter is the ratio of long seeks to data reads, and minimizing that is not the same as reducing seeks to zero. Now consider two common cases: * A file that is written out at speed, say 100-500MB/s. 2-4s means that there is an opportunity to allocate 200MB-2GB contiguous extents, and with any luck much larger ones. Conversely any larger intervals means potentially losing 200MB-2GB of data. Sure, if they did not want to lose the data the user process should be doing 'fdatasync()', but XFS in particular is sort of pretty good at doing a mild version of 'O_PONIES' where there is a balance between going as fast as possible (buffer a lot in memory) and offering *some* level of safety (as shown in the tests I did for a fair comparison with 'ext3'). * A file that is written slowly in small chunks. Well, *nothing* will help that except preallocate or space reservations. Personally I'd rather have a file system design with space reservations (on detecting an append-like access pattern) and truncate-on-close than delayed allocation like XFS; while delayed allocation seems to work well enough in many cases, it is not quit "the more the merrier". From nveber@pyre.virge.net Tue Jun 7 11:37:45 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_45 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57Gbj0p037071 for ; Tue, 7 Jun 2011 11:37:45 -0500 X-ASG-Debug-ID: 1307464663-549603080000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pyre.virge.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 27EA31E412E6 for ; Tue, 7 Jun 2011 09:37:43 -0700 (PDT) Received: from pyre.virge.net (24-246-28-70.cable.teksavvy.com [24.246.28.70]) by cuda.sgi.com with ESMTP id myEIUngmZmRv0Bmy for ; Tue, 07 Jun 2011 09:37:43 -0700 (PDT) Received: by pyre.virge.net (Postfix, from userid 1000) id 8A4FE10C135D; Tue, 7 Jun 2011 12:37:42 -0400 (EDT) Date: Tue, 7 Jun 2011 12:37:42 -0400 From: Norbert Veber To: xfs@oss.sgi.com X-ASG-Orig-Subj: Small files perform much faster on newly formatted fs? Subject: Small files perform much faster on newly formatted fs? Message-ID: <20110607163742.GH28625@pyre.virge.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: 24-246-28-70.cable.teksavvy.com[24.246.28.70] X-Barracuda-Start-Time: 1307464664 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_MJ1963, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65755 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi, I have some xfs filesystems on my computer running linux. These were created (formatted) about 2 years ago on debian 5.0 on software raid 5+lvm. I am getting pretty terible performance with small files, and decided to try to optimize that a bit with some mount options etc. I also created a new filesystem to try different mkfs options. This was done on the same computer which has since been upgraded to debian 6.0. I found a very suprising thing. The new filesystem performed an order of magnitude faster than the 2 year old filessytem which has made with an older kernel and older mkfs.xfs (from debian 5.0). For a simple test I tried to time the untar and rm -rf on the linux 2.6.32 source tree. Its not very scientific but I get pretty consistent results. Old 20gb filessystem: pyre:/shared# xfs_info /shared meta-data=/dev/mapper/vg0-shared isize=256 agcount=9, agsize=610304 blks = sectsz=512 attr=2 data = bsize=4096 blocks=5062656, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 Since sunit and swidth wasnt automatically set by the old debian 5 mkfs time, I use the mount options isntead: nveber@pyre[6788:~/files/doc]$ mount | grep shared /dev/mapper/vg0-newshared on /mnt/tmp type xfs (rw) /dev/mapper/vg0-shared on /shared type xfs (rw,sunit=128,swidth=256) Now for the "benchmark": pyre:/shared# sync;sleep 15s;time ionice -c1 tar -zxf linux-2.6_2.6.32.orig.tar.gz real 3m6.842s user 0m3.800s sys 0m2.692s New 30gb filesystem: pyre:/shared# xfs_info /mnt/tmp meta-data=/dev/mapper/vg0-newshared isize=256 agcount=16, agsize=491504 blks = sectsz=512 attr=2 data = bsize=4096 blocks=7864064, imaxpct=25 = sunit=16 swidth=32 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=3840, version=2 = sectsz=512 sunit=16 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 pyre:/mnt/tmp# sync;sleep 15s;time ionice -c1 tar -zxf linux-2.6_2.6.32.orig.tar.gz real 0m19.851s user 0m3.828s sys 0m2.184s 20 seconds vs 3+ minutes?! The only difference I can see is lazy-count=1 and a larger agcount. Sunit and swidth were also set automatically by mkfs this time. I tried the lazy-count option for the old fs: pyre:~# umount /shared pyre:~# xfs_admin -c1 /dev/vg0/shared Enabling lazy-counters pyre:~# mount /shared pyre:/shared# mv linux-2.6-2.6.32/ deleteme pyre:/shared# sync;sleep 15s;time ionice -c1 tar -zxf linux-2.6_2.6.32.orig.tar.gz real 2m37.634s user 0m3.800s sys 0m2.612s Its a little faster now, but still way slower than the new fs. Whats the difference, and how can I make the old one perform at this level short of reformatting? :) Thanks, Norbert From aelder@oss.sgi.com Tue Jun 7 14:38:14 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p57JcE5i045748 for ; Tue, 7 Jun 2011 14:38:14 -0500 Received: (from aelder@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id p57JcCdI045670; Tue, 7 Jun 2011 14:38:12 -0500 Date: Tue, 7 Jun 2011 14:38:12 -0500 Message-Id: <201106071938.p57JcCdI045670@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, master, updated. v2.6.38-18957-g59c5f46 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 233eebb9a96f956c541c0c9094fd321894bd93a7 X-Git-Newrev: 59c5f46fbe01a00eedf54a23789634438bb80603 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, master has been updated aa38572 fs: pass exact type of data dirties to ->dirty_inode 8a0599d Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs 1495f23 vmscan: change shrinker API by passing shrink_control struct a77febb Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs 57d19e8 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial 70f23fd treewide: fix a few typos in comments 7ac9565 xfs: fix race condition in AIL push trigger fe0da76 xfs: make AIL target updates and compares 32bit safe. 50e8668 xfs: always push the AIL to the target 9e7004e xfs: exit AIL push work correctly when AIL is empty 228d62d xfs: ensure reclaim cursor is reset correctly at end of AG from 233eebb9a96f956c541c0c9094fd321894bd93a7 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit aa38572954ade525817fe88c54faebf85e5a61c0 Author: Christoph Hellwig Date: Fri May 27 06:53:02 2011 -0400 fs: pass exact type of data dirties to ->dirty_inode Tell the filesystem if we just updated timestamp (I_DIRTY_SYNC) or anything else, so that the filesystem can track internally if it needs to push out a transaction for fdatasync or not. This is just the prototype change with no user for it yet. I plan to push large XFS changes for the next merge window, and getting this trivial infrastructure in this window would help a lot to avoid tree interdependencies. Also remove incorrect comments that ->dirty_inode can't block. That has been changed a long time ago, and many implementations rely on it. Signed-off-by: Christoph Hellwig Signed-off-by: Al Viro commit 8a0599dd2471f2a2e409498c08a0ab339057ad06 Merge: 35806b4f7c5620b547f183e9d53f7cfaeabb582b 233eebb9a96f956c541c0c9094fd321894bd93a7 Author: Linus Torvalds Date: Thu May 26 10:49:11 2011 -0700 Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs * 'for-linus' of git://oss.sgi.com/xfs/xfs: xfs: correctly decrement the extent buffer index in xfs_bmap_del_extent xfs: check for valid indices in xfs_iext_get_ext and xfs_iext_idx_to_irec xfs: fix up asserts in xfs_iflush_fork xfs: do not do pointer arithmetic on extent records xfs: do not use unchecked extent indices in xfs_bunmapi xfs: do not use unchecked extent indices in xfs_bmapi xfs: do not use unchecked extent indices in xfs_bmap_add_extent_* xfs: remove if_lastex xfs: remove the unused XFS_BMAPI_RSVBLOCKS flag xfs: do not discard alloc btree blocks xfs: add online discard support commit 1495f230fa7750479c79e3656286b9183d662077 Author: Ying Han Date: Tue May 24 17:12:27 2011 -0700 vmscan: change shrinker API by passing shrink_control struct Change each shrinker's API by consolidating the existing parameters into shrink_control struct. This will simplify any further features added w/o touching each file of shrinker. [akpm@linux-foundation.org: fix build] [akpm@linux-foundation.org: fix warning] [kosaki.motohiro@jp.fujitsu.com: fix up new shrinker API] [akpm@linux-foundation.org: fix xfs warning] [akpm@linux-foundation.org: update gfs2] Signed-off-by: Ying Han Cc: KOSAKI Motohiro Cc: Minchan Kim Acked-by: Pavel Emelyanov Cc: KAMEZAWA Hiroyuki Cc: Mel Gorman Acked-by: Rik van Riel Cc: Johannes Weiner Cc: Hugh Dickins Cc: Dave Hansen Cc: Steven Whitehouse Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds commit a77febbef105554c5a37241cf903f48ab7bc03c7 Merge: 42cd71bf1e3a081b3150018bbf448cb6c8a844a5 bf59170a66bc3eaf3ee513aa6ce9774aa2ab5188 Author: Linus Torvalds Date: Mon May 23 15:19:16 2011 -0700 Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs * 'for-linus' of git://oss.sgi.com/xfs/xfs: xfs: obey minleft values during extent allocation correctly xfs: reset buffer pointers before freeing them xfs: avoid getting stuck during async inode flushes xfs: fix xfs_itruncate_start tracing xfs: fix duplicate workqueue initialisation xfs: kill off xfs_printk() xfs: fix race condition in AIL push trigger xfs: make AIL target updates and compares 32bit safe. xfs: always push the AIL to the target xfs: exit AIL push work correctly when AIL is empty xfs: ensure reclaim cursor is reset correctly at end of AG xfs: add an x86 compat handler for XFS_IOC_ZERO_RANGE xfs: fix compiler warning in xfs_trace.h xfs: cleanup duplicate initializations xfs: reduce the number of pagb_lock roundtrips in xfs_alloc_clear_busy xfs: exact busy extent tracking xfs: do not immediately reuse busy extent ranges xfs: optimize AGFL refills commit 57d19e80f459dd845fb3cfeba8e6df8471bac142 Merge: ee9ec4f82049c678373a611ce20ac67fe9ad836e e64851f5a0ad6ec991f74ebb3108c35aa0323d5f Author: Linus Torvalds Date: Mon May 23 09:12:26 2011 -0700 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits) b43: fix comment typo reqest -> request Haavard Skinnemoen has left Atmel cris: typo in mach-fs Makefile Kconfig: fix copy/paste-ism for dell-wmi-aio driver doc: timers-howto: fix a typo ("unsgined") perf: Only include annotate.h once in tools/perf/util/ui/browsers/annotate.c md, raid5: Fix spelling error in comment ('Ofcourse' --> 'Of course'). treewide: fix a few typos in comments regulator: change debug statement be consistent with the style of the rest Revert "arm: mach-u300/gpio: Fix mem_region resource size miscalculations" audit: acquire creds selectively to reduce atomic op overhead rtlwifi: don't touch with treewide double semicolon removal treewide: cleanup continuations and remove logging message whitespace ath9k_hw: don't touch with treewide double semicolon removal include/linux/leds-regulator.h: fix syntax in example code tty: fix typo in descripton of tty_termios_encode_baud_rate xtensa: remove obsolete BKL kernel option from defconfig m68k: fix comment typo 'occcured' arch:Kconfig.locks Remove unused config option. treewide: remove extra semicolons ... commit 70f23fd66bc821a0e99647f70a809e277cc93c4c Author: Justin P. Mattock Date: Tue May 10 10:16:21 2011 +0200 treewide: fix a few typos in comments - kenrel -> kernel - whetehr -> whether - ttt -> tt - sss -> ss Signed-off-by: Justin P. Mattock Signed-off-by: Jiri Kosina commit 7ac956576d0ce8f97450a39c2f304db8eea01647 Author: Dave Chinner Date: Fri May 6 02:54:08 2011 +0000 xfs: fix race condition in AIL push trigger The recent conversion of the xfsaild functionality to a work queue introduced a hard-to-hit log space grant hang. One is caused by a race condition in determining whether there is a psh in progress or not. The XFS_AIL_PUSHING_BIT is used to determine whether a push is currently in progress. When the AIL push work completes, it checked whether the target changed and cleared the PUSHING bit to allow a new push to be requeued. The race condition is as follows: Thread 1 push work smp_wmb() smp_rmb() check ailp->xa_target unchanged update ailp->xa_target test/set PUSHING bit does not queue clear PUSHING bit does not requeue Now that the push target is updated, new attempts to push the AIL will not trigger as the push target will be the same, and hence despite trying to push the AIL we won't ever wake it again. The fix is to ensure that the AIL push work clears the PUSHING bit before it checks if the target is unchanged. As a result, both push triggers operate on the same test/set bit criteria, so even if we race in the push work and miss the target update, the thread requesting the push will still set the PUSHING bit and queue the push work to occur. For safety sake, the same queue check is done if the push work detects the target change, though only one of the two will will queue new work due to the use of test_and_set_bit() checks. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Alex Elder (cherry picked from commit e4d3c4a43b595d5124ae824d300626e6489ae857) commit fe0da767311933d1c1907cb8d326beea7a3cbd9c Author: Dave Chinner Date: Fri May 6 02:54:07 2011 +0000 xfs: make AIL target updates and compares 32bit safe. The recent conversion of the xfsaild functionality to a work queue introduced a hard-to-hit log space grant hang. One of the problems noticed was that updates of the push target are not 32 bit safe as the target is a 64 bit value. We cannot copy a 64 bit LSN without the possibility of corrupting the result when racing with another updating thread. We have function to do this update safely without needing to care about 32/64 bit issues - xfs_trans_ail_copy_lsn() - so use that when updating the AIL push target. Also move the reading of the target in the push work inside the AIL lock, and use XFS_LSN_CMP() for the unlocked comparison during work termination to close read holes as well. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Alex Elder (cherry picked from commit fd5670f22fce247754243cf2ed41941e5762d990) commit 50e86686dfb287d720af8b0f977202d205c04215 Author: Dave Chinner Date: Fri May 6 02:54:06 2011 +0000 xfs: always push the AIL to the target The recent conversion of the xfsaild functionality to a work queue introduced a hard-to-hit log space grant hang. One of the problems discovered is a target mismatch between the item pushing loop and the target itself. The push trigger checks for the target increasing (i.e. new target > current) while the push loop only pushes items that have a LSN < current. As a result, we can get the situation where the push target is X, the items at the tail of the AIL have LSN X and they don't get pushed. The push work then completes thinking it is done, and cannot be restarted until the push target increases to >= X + 1. If the push target then never increases (because the tail is not moving), then we never run the push work again and we stall. Fix it by making sure log items with a LSN that matches the target exactly are pushed during the loop. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Alex Elder (cherry picked from commit cb64026b6e8af50db598ec7c3f59d504259b00bb) commit 9e7004e741de0b2daabbbadafbaf11ff1a94e00c Author: Dave Chinner Date: Fri May 6 02:54:05 2011 +0000 xfs: exit AIL push work correctly when AIL is empty The recent conversion of the xfsaild functionality to a work queue introduced a hard-to-hit log space grant hang. The main cause is a regression where a work exit path fails to clear the PUSHING state and recheck the target correctly. Make both exit paths do the same PUSHING bit clearing and target checking when the "no more work to be done" condition is hit. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Alex Elder (cherry picked from commit ea35a20021f8497390d05b93271b4d675516c654) commit 228d62dd3f74734b9801c789b5addc57fdfc208f Author: Dave Chinner Date: Fri May 6 02:54:04 2011 +0000 xfs: ensure reclaim cursor is reset correctly at end of AG On a 32 bit highmem PowerPC machine, the XFS inode cache was growing without bound and exhausting low memory causing the OOM killer to be triggered. After some effort, the problem was reproduced on a 32 bit x86 highmem machine. The problem is that the per-ag inode reclaim index cursor was not getting reset to the start of the AG if the radix tree tag lookup found no more reclaimable inodes. Hence every further reclaim attempt started at the same index beyond where any reclaimable inodes lay, and no further background reclaim ever occurred from the AG. Without background inode reclaim the VM driven cache shrinker simply cannot keep up with cache growth, and OOM is the result. While the change that exposed the problem was the conversion of the inode reclaim to use work queues for background reclaim, it was not the cause of the bug. The bug was introduced when the cursor code was added, just waiting for some weird configuration to strike.... Signed-off-by: Dave Chinner Tested-By: Christian Kujau Reviewed-by: Christoph Hellwig Reviewed-by: Alex Elder (cherry picked from commit b223221956675ce8a7b436d198ced974bb388571) ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_buf.c | 4 ++-- fs/xfs/linux-2.6/xfs_super.c | 3 ++- fs/xfs/linux-2.6/xfs_sync.c | 5 +++-- fs/xfs/quota/xfs_qm.c | 6 +++--- fs/xfs/xfs_inode.c | 2 +- 5 files changed, 11 insertions(+), 9 deletions(-) hooks/post-receive -- XFS development tree From david@fromorbit.com Wed Jun 8 00:18:48 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p585IlCh073924 for ; Wed, 8 Jun 2011 00:18:48 -0500 X-ASG-Debug-ID: 1307510325-0b3b03400000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AB44616C54CF for ; Tue, 7 Jun 2011 22:18:45 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id qf794Kjpw1KD4e74 for ; Tue, 07 Jun 2011 22:18:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkEAG4F7015LCoegWdsb2JhbABTpikVAQEWJiXHIw6GFQSgeA Received: from ppp121-44-42-30.lns20.syd6.internode.on.net (HELO dastard) ([121.44.42.30]) by ipmail04.adl6.internode.on.net with ESMTP; 08 Jun 2011 14:48:44 +0930 Received: from dave by dastard with local (Exim 4.72) (envelope-from ) id 1QUBAA-0004Bf-6V; Wed, 08 Jun 2011 15:18:42 +1000 Date: Wed, 8 Jun 2011 15:18:42 +1000 From: Dave Chinner To: Peter Grandi Cc: Michael Monnerie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general Message-ID: <20110608051842.GO32466@dastard> References: <19945.24042.711472.158523@tree.ty.sabi.co.UK> <201106060929.06814@zmi.at> <19950.12549.541440.285348@tree.ty.sabi.co.UK> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19950.12549.541440.285348@tree.ty.sabi.co.UK> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1307510326 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0205 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65805 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Jun 07, 2011 at 03:09:09PM +0100, Peter Grandi wrote: > Personally I'd rather have a file system design with space > reservations (on detecting an append-like access pattern) and > truncate-on-close than delayed allocation like XFS; Welcome to the 1990s, Peter. XFS has been doing this for 15 years. It is an optimisation used by the delayed allocation mechanism, not a replacement for it. You might have heard the term "speculative preallocation" before - this is what it does. FYI, ext3 has a space reservation infrastructure to try to ensure contiguous allocation occurs without using delayed allocation. It doesn't work nearly as well as delayed allocation in ext4, btrfs or XFS... Cheers, Dave. -- Dave Chinner david@fromorbit.com From michael.monnerie@is.it-management.at Wed Jun 8 02:11:16 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p587BFI3078847 for ; Wed, 8 Jun 2011 02:11:16 -0500 X-ASG-Debug-ID: 1307517073-18cf007c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv14.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 054094A9AB4 for ; Wed, 8 Jun 2011 00:11:13 -0700 (PDT) Received: from mailsrv14.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id 94EQsaWIPVnMoXR5 for ; Wed, 08 Jun 2011 00:11:13 -0700 (PDT) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv14.zmi.at (Postfix) with ESMTPSA id 77E3217C; Wed, 8 Jun 2011 09:11:12 +0200 (CEST) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id 87302401C35; Wed, 8 Jun 2011 09:11:11 +0200 (CEST) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Small files perform much faster on newly formatted fs? Subject: Re: Small files perform much faster on newly formatted fs? Date: Wed, 8 Jun 2011 09:11:10 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38.6-zmi; KDE/4.6.0; x86_64; ; ) Cc: Norbert Veber References: <20110607163742.GH28625@pyre.virge.net> In-Reply-To: <20110607163742.GH28625@pyre.virge.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart14545136.KOncusAfmJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201106080911.11286@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1307517074 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0206 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65813 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --nextPart14545136.KOncusAfmJ Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Dienstag, 7. Juni 2011 Norbert Veber wrote: > 20 seconds vs 3+ minutes?! The only difference I can see is > lazy-count=3D1 and a larger agcount. Sunit and swidth were also set > automatically by mkfs this time. Then retry mounting the old fs with sunit=3D and swidth=3D parameters. Are= =20 they on the same disks? What are your disks (number, kind)? =2D-=20 mit freundlichen Gr=FCssen, Michael Monnerie, Ing. BSc it-management Internet Services: Prot=E9ger http://proteger.at [gesprochen: Prot-e-schee] Tel: +43 660 / 415 6531 // Haus zu verkaufen: http://zmi.at/langegg/ --nextPart14545136.KOncusAfmJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEABECAAYFAk3vII8ACgkQzhSR9xwSCbSAxACgwUzQMUNSceJD5bCTNbaXUcUG DpkAoOMw2cH0QNVN8Wekd83Mb0c2/8gY =i5k5 -----END PGP SIGNATURE----- --nextPart14545136.KOncusAfmJ-- From michael.monnerie@is.it-management.at Wed Jun 8 03:33:07 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p588X7sq081287 for ; Wed, 8 Jun 2011 03:33:07 -0500 X-ASG-Debug-ID: 1307521985-455f026b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv14.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BDA261D7183F for ; Wed, 8 Jun 2011 01:33:05 -0700 (PDT) Received: from mailsrv14.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id e3rA9S4dkwh6aW57 for ; Wed, 08 Jun 2011 01:33:05 -0700 (PDT) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv14.zmi.at (Postfix) with ESMTPSA id D5AD117B; Wed, 8 Jun 2011 10:33:03 +0200 (CEST) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id 07562401C35; Wed, 8 Jun 2011 10:33:03 +0200 (CEST) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: I/O hang, possibly XFS, possibly general Subject: Re: I/O hang, possibly XFS, possibly general Date: Wed, 8 Jun 2011 10:32:58 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38.6-zmi; KDE/4.6.0; x86_64; ; ) Cc: Peter Grandi References: <201106060929.06814@zmi.at> <19950.12549.541440.285348@tree.ty.sabi.co.UK> In-Reply-To: <19950.12549.541440.285348@tree.ty.sabi.co.UK> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1948516.1BBM6IlfF9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201106081033.02900@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1307521985 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65819 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --nextPart1948516.1BBM6IlfF9 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Dienstag, 7. Juni 2011 Peter Grandi wrote: > * A file that is written out at speed, say 100-500MB/s. 2-4s > means that there is an opportunity to allocate 200MB-2GB > contiguous extents, and with any luck much larger ones. > Conversely any larger intervals means potentially losing > 200MB-2GB of data. Sure, if they did not want to lose the > data the user process should be doing 'fdatasync()', but XFS > in particular is sort of pretty good at doing a mild version > of 'O_PONIES' where there is a balance between going as fast > as possible (buffer a lot in memory) and offering some > level of safety (as shown in the tests I did for a fair > comparison with 'ext3'). On a PC, that "loosing 2GB of data" is loosing a single file under=20 normal use. It's quite seldom that people are copying data around. And=20 even if, when the crash happens they usually know what they just did,=20 and restart the copy after a crash. If we speak about a server normally there should be a HW RAID card in it=20 with good cache, and then it's true you should limit Linux write cache=20 and flush early and often, as the card has BBWC and therefore data is=20 protected once in the RAID card. People tend to forget to set writeback=20 lower when using RAID controllers + BBWC, and it's almost nowhere=20 documented. Maybe good for a FAQ entry on XFS, even if it's not XFS=20 specific? I wonder if there is a good document for "best practise" on VMs? I've=20 never seen someone testing a VMware/XEN host with 20 Linux VMs, and what=20 the settings should be for vm.dirty* and net.ipv4.* values. I've seen=20 crashes on VM servers, where afterwards databases in VMs were broken=20 despite using a RAID card +BBWC... =20 > * A file that is written slowly in small chunks. Well, > nothing will help that except preallocate or space > reservations. Now for a common webserver we use, as a guideline there are about 8=20 uploads parallel all the time. Most of them are slow, as people are on=20 ADSL. If you sync quite often, you're lucky when using XFS to get=20 preallocation and all that. Otherwise, you'd have chunks of all files=20 scattered on disk. =2D-=20 mit freundlichen Gr=FCssen, Michael Monnerie, Ing. BSc it-management Internet Services: Prot=E9ger http://proteger.at [gesprochen: Prot-e-schee] Tel: +43 660 / 415 6531 // Haus zu verkaufen: http://zmi.at/langegg/ --nextPart1948516.1BBM6IlfF9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEABECAAYFAk3vM74ACgkQzhSR9xwSCbTeDQCfUehyWAWBegb+FsTXHAozMu2/ uwcAnjLetDaQzKxYK9UCFk3RUDzGZeng =xQSp -----END PGP SIGNATURE----- --nextPart1948516.1BBM6IlfF9-- From nveber@pyre.virge.net Wed Jun 8 07:26:41 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p58CQf4Z092997 for ; Wed, 8 Jun 2011 07:26:41 -0500 X-ASG-Debug-ID: 1307535999-5dee03800000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pyre.virge.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DBD8716C599F for ; Wed, 8 Jun 2011 05:26:39 -0700 (PDT) Received: from pyre.virge.net (24-246-28-70.cable.teksavvy.com [24.246.28.70]) by cuda.sgi.com with ESMTP id kT7mPHzNIMca4csM for ; Wed, 08 Jun 2011 05:26:39 -0700 (PDT) Received: by pyre.virge.net (Postfix, from userid 1000) id E9565109C827; Wed, 8 Jun 2011 08:26:38 -0400 (EDT) Date: Wed, 8 Jun 2011 08:26:38 -0400 From: Norbert Veber To: Michael Monnerie Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Small files perform much faster on newly formatted fs? Subject: Re: Small files perform much faster on newly formatted fs? Message-ID: <20110608122638.GQ28625@pyre.virge.net> References: <20110607163742.GH28625@pyre.virge.net> <201106080911.11286@zmi.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106080911.11286@zmi.at> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: 24-246-28-70.cable.teksavvy.com[24.246.28.70] X-Barracuda-Start-Time: 1307535999 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0009 1.0000 -2.0149 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=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65835 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Jun 08, 2011 at 09:11:10AM +0200, Michael Monnerie wrote: > On Dienstag, 7. Juni 2011 Norbert Veber wrote: > > 20 seconds vs 3+ minutes?! The only difference I can see is > > lazy-count=1 and a larger agcount. Sunit and swidth were also set > > automatically by mkfs this time. > > Then retry mounting the old fs with sunit= and swidth= parameters. Are > they on the same disks? What are your disks (number, kind)? Yes its already mounted this way as I mentioned in my original message: /dev/mapper/vg0-shared on /shared type xfs (rw,noatime,sunit=128,swidth=256) Both filesystems are on the same MD raid 5 which consists of 3 1 tb WD Black hard drive. Thanks, Norbert From michael.monnerie@is.it-management.at Wed Jun 8 08:47:44 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p58DlhKV095337 for ; Wed, 8 Jun 2011 08:47:44 -0500 X-ASG-Debug-ID: 1307540860-59c000790000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv14.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 77ADED8073A for ; Wed, 8 Jun 2011 06:47:40 -0700 (PDT) Received: from mailsrv14.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id RN4ikaqqLPqdKmG9 for ; Wed, 08 Jun 2011 06:47:40 -0700 (PDT) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv14.zmi.at (Postfix) with ESMTPSA id 623EF17C; Wed, 8 Jun 2011 15:47:39 +0200 (CEST) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id DF27F401C35; Wed, 8 Jun 2011 15:47:38 +0200 (CEST) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Small files perform much faster on newly formatted fs? Subject: Re: Small files perform much faster on newly formatted fs? Date: Wed, 8 Jun 2011 15:47:33 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38.6-zmi; KDE/4.6.0; x86_64; ; ) Cc: Norbert Veber References: <20110607163742.GH28625@pyre.virge.net> <201106080911.11286@zmi.at> <20110608122638.GQ28625@pyre.virge.net> In-Reply-To: <20110608122638.GQ28625@pyre.virge.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3036893.VkC3Ibz6SB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201106081547.38266@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1307540861 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65840 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --nextPart3036893.VkC3Ibz6SB Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mittwoch, 8. Juni 2011 Norbert Veber wrote: > Yes its already mounted this way as I mentioned in my original > message: /dev/mapper/vg0-shared on /shared type xfs > (rw,noatime,sunit=3D128,swidth=3D256) Oh, I did only look at the xfs_info output. =20 > Both filesystems are on the same MD raid 5 which consists of 3 1 tb > WD Black hard drive. The difference could be that your filesystem is very much aged, and the=20 free space clustered around to new files get heavily fragmented. Did you=20 run xfs_defrag often? How full is your filesystem? Also the log has sunit=3D0 against 16, maybe there's the diff. Are you on a newer kernel that supports delaylog? Then try that. =2D-=20 mit freundlichen Gr=FCssen, Michael Monnerie, Ing. BSc it-management Internet Services: Prot=E9ger http://proteger.at [gesprochen: Prot-e-schee] Tel: +43 660 / 415 6531 // Haus zu verkaufen: http://zmi.at/langegg/ --nextPart3036893.VkC3Ibz6SB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEABECAAYFAk3vfXoACgkQzhSR9xwSCbSSrgCgmVn84Lt14jJNjD9e+iRjVDZp d5sAoIhizYgCximf7thAHUsQ4JWp6oI7 =P0O9 -----END PGP SIGNATURE----- --nextPart3036893.VkC3Ibz6SB-- From eflorac@intellique.com Wed Jun 8 10:47:23 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p58FlNJ6103077 for ; Wed, 8 Jun 2011 10:47:23 -0500 X-ASG-Debug-ID: 1307548039-75b803ae0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 57B2A16B127C for ; Wed, 8 Jun 2011 08:47:20 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by cuda.sgi.com with ESMTP id UNHjPTHp6odPFEoE for ; Wed, 08 Jun 2011 08:47:20 -0700 (PDT) Received: from harpe.intellique.com (unknown [82.225.196.72]) by smtp4-g21.free.fr (Postfix) with ESMTP id 7F18F4C8188 for ; Wed, 8 Jun 2011 17:47:16 +0200 (CEST) Date: Wed, 8 Jun 2011 17:47:24 +0200 From: Emmanuel Florac To: xfs@oss.sgi.com X-ASG-Orig-Subj: Status of XFS ACL limitations Subject: Status of XFS ACL limitations Message-ID: <20110608174724.23ea57f7@harpe.intellique.com> Organization: Intellique X-Mailer: Claws Mail 3.7.9 (GTK+ 2.16.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp4-g21.free.fr[212.27.42.4] X-Barracuda-Start-Time: 1307548042 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65847 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hello everyone, I was looking through list archive and found that: http://oss.sgi.com/archives/xfs/2009-03/msg00329.html 2 years later is there any progress? 25 ACLs entries still are not enough for many uses :) regards, -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From achender@linux.vnet.ibm.com Wed Jun 8 13:49:24 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p58InOxd111534 for ; Wed, 8 Jun 2011 13:49:24 -0500 X-ASG-Debug-ID: 1307558963-7805028c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from e37.co.us.ibm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D0EA949FDC9 for ; Wed, 8 Jun 2011 11:49:23 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by cuda.sgi.com with ESMTP id 2FkAUih8mgXp3eJj for ; Wed, 08 Jun 2011 11:49:23 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p58IkNR7001888 for ; Wed, 8 Jun 2011 12:46:23 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p58In9wY348520 for ; Wed, 8 Jun 2011 12:49:16 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p58CmxXs000764 for ; Wed, 8 Jun 2011 06:48:59 -0600 Received: from lc4eb0185863151.ibm.com (sig-9-65-162-142.mts.ibm.com [9.65.162.142]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p58Cmw2n000659; Wed, 8 Jun 2011 06:48:58 -0600 Message-ID: <4DEFC41A.9070701@linux.vnet.ibm.com> Date: Wed, 08 Jun 2011 11:48:58 -0700 From: Allison Henderson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ext4 Developers List , linux-fsdevel , xfs-oss X-ASG-Orig-Subj: Port xfstests 145, 161, 175, 176, 185? Subject: Port xfstests 145, 161, 175, 176, 185? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: e37.co.us.ibm.com[32.97.110.158] X-Barracuda-Start-Time: 1307558963 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi all! During one of my reviews for the punch hole tests patch set it was mentioned that it would be helpful to take the xfstests 145, 161, 175, 176, 185 and modify them such that they can run with out requiring the dmapi. These tests contain some more interesting punch hole tests, but they dont normally run unless there is support for dmapi. I did take a peek at them and I was thinking that if we decide to do this, we would probably need to do something like introduce a new set of source code that is similar to what is seen under the dmapi folder, but modified to use a generic interface instead of the dmapi libraries. We could try to merge them into a single code path, but I think that may introduce more complexities than would be desirable. I just wanted to get a general consensus of how many people would be interested in this idea. Thx all! Allison Henderson From nveber@pyre.virge.net Wed Jun 8 13:58:50 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_45 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p58IwnvR113363 for ; Wed, 8 Jun 2011 13:58:49 -0500 X-ASG-Debug-ID: 1307559525-0534003d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pyre.virge.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AF14812D5364 for ; Wed, 8 Jun 2011 11:58:46 -0700 (PDT) Received: from pyre.virge.net (24-246-28-70.cable.teksavvy.com [24.246.28.70]) by cuda.sgi.com with ESMTP id 0KHFbEnA3dtIlwck for ; Wed, 08 Jun 2011 11:58:46 -0700 (PDT) Received: by pyre.virge.net (Postfix, from userid 1000) id 17AFF109C827; Wed, 8 Jun 2011 14:58:45 -0400 (EDT) Date: Wed, 8 Jun 2011 14:58:44 -0400 From: Norbert Veber To: Michael Monnerie Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Small files perform much faster on newly formatted fs? Subject: Re: Small files perform much faster on newly formatted fs? Message-ID: <20110608185844.GB28625@pyre.virge.net> References: <20110607163742.GH28625@pyre.virge.net> <201106080911.11286@zmi.at> <20110608122638.GQ28625@pyre.virge.net> <201106081547.38266@zmi.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106081547.38266@zmi.at> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: 24-246-28-70.cable.teksavvy.com[24.246.28.70] X-Barracuda-Start-Time: 1307559527 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65860 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Jun 08, 2011 at 03:47:33PM +0200, Michael Monnerie wrote: > The difference could be that your filesystem is very much aged, and the > free space clustered around to new files get heavily fragmented. Did you > run xfs_defrag often? How full is your filesystem? Doesn't seem to be the case: pyre:~# xfs_db -c frag -r /dev/vg0/shared actual 61132, ideal 60937, fragmentation factor 0.32% (thats the old/slow filesystem) I re-created the test filesystem to be the same size (20gb) as the original, and copied all the same files to it, so both are now 80% full. pyre:~# lvremove /dev/vg0/newshared Do you really want to remove active logical volume newshared? [y/n]: y Logical volume "newshared" successfully removed pyre:~# lvcreate -L 20G -n newshared vg0 Logical volume "newshared" created I also tried to replicate the same sunit/swidth options, but mkfs.xfs is too smart for its own good and ignored my settings: pyre:~# mkfs.xfs -f -d sunit=0,swidth=0 -l sunit=0 /dev/vg0/newshared meta-data=/dev/vg0/newshared isize=256 agcount=16, agsize=327664 blks = sectsz=512 attr=2, projid32bit=0 data = bsize=4096 blocks=5242624, imaxpct=25 = sunit=16 swidth=32 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=16 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 pyre:~# mount /dev/vg0/newshared /mnt/tmp pyre:~# cp -a /shared/* /mnt/tmp/ pyre:/# cd /mnt/tmp pyre:/mnt/tmp# sync;sleep 15s;time ionice -c1 tar -zxf linux-2.6_2.6.32.orig.tar.gz real 0m21.248s user 0m3.772s sys 0m2.204s > Also the log has sunit=0 against 16, maybe there's the diff. > Are you on a newer kernel that supports delaylog? Then try that. Yes, it could be that the mount options only set sunit/swidth for the data section and not the journal, so metadata operations are much slower. I am not able to test as mkfs.xfs ignores my command line options and sets the values even if I tell it they should be 0.. Thanks, Norbert From Jeannie_Burger@URMC.Rochester.edu Wed Jun 8 14:41:59 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p58Jfwqf114813 for ; Wed, 8 Jun 2011 14:41:59 -0500 X-ASG-Debug-ID: 1307562116-080c01e80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from voltage1.urmc.rochester.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8E1F812D558B for ; Wed, 8 Jun 2011 12:41:56 -0700 (PDT) Received: from voltage1.urmc.rochester.edu (voltage1.urmc.rochester.edu [128.151.10.32]) by cuda.sgi.com with ESMTP id YUwQ3XlCUF1teHO4 for ; Wed, 08 Jun 2011 12:41:56 -0700 (PDT) Received: from urmcht1.urmc.rochester.edu (urmcht2.urmc.rochester.edu [128.151.10.29]) by voltage1.urmc.rochester.edu (8.13.8/8.13.8) with ESMTP id p58JTUMV007873 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 8 Jun 2011 15:29:30 -0400 Received: from URMCMS5.urmc-sh.rochester.edu ([0000:0000:0000:0000:0000:0000:0.0.0.1]) by urmcht2.urmc-sh.rochester.edu ([128.151.10.29]) with mapi; Wed, 8 Jun 2011 15:29:30 -0400 From: "Burger, Jeannie" To: "admin@helpdesk.org" Date: Wed, 8 Jun 2011 15:29:30 -0400 X-ASG-Orig-Subj: Take Note Subject: Take Note Thread-Topic: Take Note Thread-Index: AQHMJhJja3d3SyIIwE2zQqYpKX5KRQ== Message-ID: <0FF1B8B136BC7043A8CC79279432A26004C5E3C3E1@URMCMS5.urmc-sh.rochester.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0FF1B8B136BC7043A8CC79279432A26004C5E3C3E1URMCMS5urmcsh_" MIME-Version: 1.0 X-Barracuda-Connect: voltage1.urmc.rochester.edu[128.151.10.32] X-Barracuda-Start-Time: 1307562117 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5095 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.48 X-Barracuda-Spam-Status: No, SCORE=1.48 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, HTML_MESSAGE, RCVD_ILLEGAL_IP X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65864 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.23 RCVD_ILLEGAL_IP Received: contains illegal IP address 0.00 HTML_MESSAGE BODY: HTML included in message 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --_000_0FF1B8B136BC7043A8CC79279432A26004C5E3C3E1URMCMS5urmcsh_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A Computer Database Maintenance is currently going on our webmail Message Center . Our Message Center needs to be re-set because of the attempt of a Trojan horse virus attack in our web mail data base. To protect your mailbox please Click on the link below: Click Here Failure to secure your mailbox will render your mailbox unsafe our database. System Administrator --_000_0FF1B8B136BC7043A8CC79279432A26004C5E3C3E1URMCMS5urmcsh_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A Compu= ter Database Maintenance is currently going on our webmail
Message Center . Our Message Center needs to be re-set because of
the attempt of a Trojan horse virus attack in our web mail data base.

To protect your mailbox please Click on the link below:

Click= Here

Failure to secure your mailbox will render your mailbox un= safe


our database.
System Administrator
--_000_0FF1B8B136BC7043A8CC79279432A26004C5E3C3E1URMCMS5urmcsh_-- From sandeen@sandeen.net Wed Jun 8 15:52:32 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p58KqVSe117323 for ; Wed, 8 Jun 2011 15:52:32 -0500 X-ASG-Debug-ID: 1307566350-462802010000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 154514AC833 for ; Wed, 8 Jun 2011 13:52:30 -0700 (PDT) Received: from mail.sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id B0px8F7EHAVDdcRP for ; Wed, 08 Jun 2011 13:52:30 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id DFE8A4964600; Wed, 8 Jun 2011 15:52:29 -0500 (CDT) Message-ID: <4DEFE10E.1070509@sandeen.net> Date: Wed, 08 Jun 2011 15:52:30 -0500 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Norbert Veber CC: Michael Monnerie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Small files perform much faster on newly formatted fs? Subject: Re: Small files perform much faster on newly formatted fs? References: <20110607163742.GH28625@pyre.virge.net> <201106080911.11286@zmi.at> <20110608122638.GQ28625@pyre.virge.net> In-Reply-To: <20110608122638.GQ28625@pyre.virge.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1307566351 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65869 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/8/11 7:26 AM, Norbert Veber wrote: > On Wed, Jun 08, 2011 at 09:11:10AM +0200, Michael Monnerie wrote: >> On Dienstag, 7. Juni 2011 Norbert Veber wrote: >>> 20 seconds vs 3+ minutes?! The only difference I can see is >>> lazy-count=1 and a larger agcount. Sunit and swidth were also set >>> automatically by mkfs this time. >> >> Then retry mounting the old fs with sunit= and swidth= parameters. Are >> they on the same disks? What are your disks (number, kind)? > > Yes its already mounted this way as I mentioned in my original message: > /dev/mapper/vg0-shared on /shared type xfs (rw,noatime,sunit=128,swidth=256) > > Both filesystems are on the same MD raid 5 which consists of 3 1 tb WD > Black hard drive. The 2 filesystems are at different locations on the disks, so that will make some difference. It's probably also possible that your old log is not stripe-aligned. Not sure what else it might be ... You did get the units right on your stripe specification at mount-time, good job! ;) -Eric > Thanks, > > Norbert > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From stan@hardwarefreak.com Wed Jun 8 16:00:24 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p58L0OgJ117622 for ; Wed, 8 Jun 2011 16:00:24 -0500 X-ASG-Debug-ID: 1307566822-2d0403d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3CEE51E41F68 for ; Wed, 8 Jun 2011 14:00:22 -0700 (PDT) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id qVexKAechbdECvg4 for ; Wed, 08 Jun 2011 14:00:22 -0700 (PDT) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id 066456C129; Wed, 8 Jun 2011 16:00:21 -0500 (CDT) Message-ID: <4DEFE2E6.9010206@hardwarefreak.com> Date: Wed, 08 Jun 2011 16:00:22 -0500 From: Stan Hoeppner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kenneth Emerson , xfs-oss X-ASG-Orig-Subj: Re: Defragging XFS File Systems Subject: Re: Defragging XFS File Systems References: <4DEE1422.7060902@hardwarefreak.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-65-41-216-221.sta.embarqhsd.net[65.41.216.221] X-Barracuda-Start-Time: 1307566823 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.65869 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 6/8/2011 2:55 PM, Kenneth Emerson wrote: > On Tue, Jun 7, 2011 at 7:05 AM, Stan Hoeppner wrote: > >> On 6/6/2011 10:52 PM, Kenneth Emerson wrote: >>> I hadn't given much thought to fragmentation of my TV recordings volume >>> (XFS) until reading through some MythTV-users threads recently that >>> mentioned how fragmented an XFS file system could become. After running >>> xfs_db, I found out that my fs appeared to be quite bad: >>> >>> $ sudo xfs_db -c frag -r /dev/mapper/appl_vg-appl_lv >>> actual 1138668, ideal 11023, fragmentation factor 99.03% >>> >>> I then ran xfs_fsr with all defaults (ran for two hours) and then re-ran >> >> From man xfs_fsr: >> >> It runs for up to two hours after which it records the >> filesystem where it left off, so it can start there the next >> time. This information is stored in the file >> /var/tmp/.fsrlast_xfs. If the information found here is somehow >> inconsistent or out of date it is ignored and reorganization >> starts at the beginning of the first filesystem found in >> /etc/mtab. >> >> If xfs_fsr stopped at 2 hours, multiple additional runs will likely be >> required to get good defragmentation. >> > > After some more research, I don't think I would ever be able to defrag this > volume. It is too badly fragmented and too full. Then you have a couple of options: 1. Delete files to free up space for xfs_fsr to work properly 2. Dump, delete, re-create, and restore the filesystem The first will likely leave you with fragmentation. The second will eliminate all fragmentation. >>> xfs_db and got the following results: >>> >>> $ sudo xfs_db -c frag -r /dev/mapper/appl_vg-appl_lv >> >> The -r above suggests you created a large realtime section for your >> MythTV storage. It may be helpful for you to provide xfs_info output >> for the heavily fragmented filesystem. > I thought the -r was just for read only so that I didn't have to un-mount > it before running the report. According to man xfs_db, '-r' immediately following the frag command: ... -r enables processing of realtime file data >>> invalid numrecs (27111) in bmapbtd block >>> invalid numrecs (4716) in bmapbtd block >>> invalid numrecs (58978) in bmapbtd block >>> >>> I'll leave these errors for one of the devs to tackle. > > These errors 'disappeared' when I ran xfs_db again later. Maybe a cache consistency issue. >>> actual 1034793, ideal 11024, fragmentation factor 98.93% >>> >>> The fragmentation level was reduced, >> >> It was likely reduced much more than this. Dropping caches or >> unmounting and remounting the filesystem is often necessary after >> running xfs_fsr in order to show the actual fragmentation level. Try: >> >> # echo 3 > /proc/sys/vm/drop_caches >> >> and then run xfs_db again. > I did this, but the numbers did not change much. Many of the files are > > 4GiB and have over a hundred extents. When I tried to defrag a single file, > it reported that it wan't possible. Looks like a dump/remake/restore is in your future. >>> but I was concerned about the error >>> messages. Before I go any further, am I corrupting my file system with >> the >>> defragging or are these "invalid numrecs" messages unimportant? >> >> Run 'xfs_check' or 'xfs_repair -n' and post the results. > Not necessary since the errors are now gone. I have ordered a 3TB disk > that I can connect via e-sata and copy the entire volume off of the RAID > set. I will then reformat and put the files back. After that, I will make > a cron job to run on a regular basis to keep the volume from getting so > fragmented again. Bang on that eSATA drive/interface/driver thoroughly before relying on it for your intended purpose. Look in dmesg regularly for errors while burning it in. Be mindful of partition alignment if he 3TB drive is an "Advanced Format" hybrid 512/4096 byte drive. > Thanks for your input. You're welcome. -- Stan From sandeen@sandeen.net Wed Jun 8 16:16:33 2011 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Sp