From BATV+5a39f5d6752f52bcf57a+4391+infradead.org+hch@bombadil.srs.infradead.org Tue Sep 1 02:41:07 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 6A6107F47 for ; Tue, 1 Sep 2015 02:41:07 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id EA9B5AC004 for ; Tue, 1 Sep 2015 00:41:06 -0700 (PDT) X-ASG-Debug-ID: 1441093264-04cbb06acc13520001-NocioJ Received: from bombadil.infradead.org ([198.137.202.9]) by cuda.sgi.com with ESMTP id Hu4H50NbfzKQXpaI (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 01 Sep 2015 00:41:05 -0700 (PDT) X-Barracuda-Envelope-From: BATV+5a39f5d6752f52bcf57a+4391+infradead.org+hch@bombadil.srs.infradead.org X-Barracuda-Apparent-Source-IP: 198.137.202.9 Received: from hch by bombadil.infradead.org with local (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZWgBj-0002SL-GZ; Tue, 01 Sep 2015 07:41:03 +0000 Date: Tue, 1 Sep 2015 00:41:03 -0700 From: Christoph Hellwig To: Dave Chinner Cc: Christoph Hellwig , Brian Foster , xfs@oss.sgi.com Subject: Re: [PATCH 2/4] xfs: Introduce writeback context for writepages Message-ID: <20150901074103.GA27231@infradead.org> X-ASG-Orig-Subj: Re: [PATCH 2/4] xfs: Introduce writeback context for writepages References: <1440479153-1584-1-git-send-email-david@fromorbit.com> <1440479153-1584-3-git-send-email-david@fromorbit.com> <20150831180221.GA16371@bfoster.bfoster> <20150831185612.GB349@infradead.org> <20150831221743.GI26895@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150831221743.GI26895@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: UNKNOWN[198.137.202.9] X-Barracuda-Start-Time: 1441093264 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.10 X-Barracuda-Spam-Status: No, SCORE=0.10 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22113 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS On Tue, Sep 01, 2015 at 08:17:43AM +1000, Dave Chinner wrote: > The patch changes the bio allocation patterns - it allocates them on > the fly and holds them, so we could potentially exhaust the bio > mempool with this submission technique. I've spend time to look over the patch again, and still don't see a change. Both in the old and new code we walk over the ioends and build bios on the fly in xfs_submit_ioend(), which is always called near then end of the writeback code; at the end of xfs_vm_writepage in the old version, and from the end of xfs_vm_writepage/xfs_vm_writepages through xfs_writepage_submit in the new code (not taking the error case into account, which probably should moe there, too). The only big difference is.. > The ioend allocation pattern > is different, too, because we only used to have 1 per buffer on a > writepage call and the last one was used for the write clustering. .. that we now build up way bigger ioend chains. So back to Brians concern: we can now have fairly large piles of ioends built up while potentially getting scheduled out, and this does look like a potential real issue to me. I wonder if we should (ab-)use the blk_plug_cb infrastructure so that we can flush the pending ioends out on a context switch? From jtulak@redhat.com Tue Sep 1 02:49:32 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A88D47F47 for ; Tue, 1 Sep 2015 02:49:32 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 314F0AC003 for ; Tue, 1 Sep 2015 00:49:32 -0700 (PDT) X-ASG-Debug-ID: 1441093770-04cb6c0e0f0fdc0001-NocioJ Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) by cuda.sgi.com with ESMTP id E1UHsAHD0CCFK0g7 (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 01 Sep 2015 00:49:30 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com Received: by igbuu8 with SMTP id uu8so42575563igb.1 for ; Tue, 01 Sep 2015 00:49:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9vZl4adKQ/oLpL6LZaeiwNrXV8SL1nD6o0aFNCfruVc=; b=GhhO2eTlRZE31k6LoVKfhflgAnjgQAFPQwriJkxtlxBI2cCUqPje20xQXxT5soO8hp D4vchVT5ooZvH1RsXWkQYfMybDcuT3QZk6QuEBz2ijnVcVoOa4Kk5d1miKE03TjWvbLt +jlwE42e9/TCCfEzen6IEL6ElUhQPCSRXqhC66X/6pXrYMhM2LCa9+XB2VgG33HWXim8 yQAT13WsM06PNsv1sypR52iGOE2bE1y/NUMqd7SK2wGRW6PlpyVDQWFV+/QRVgtMDGN3 sAzSIc58CJkTgcwvPMZ7fh9PNuu/l26jH4WRplceb7zM8h3gSE/fM60lEbEFXvGimFT+ eWng== X-Gm-Message-State: ALoCoQnLRVITdhR0j5xX/tNuX4blAE08H4/CsMVzljR3jvoL8C2XTfUhMRuf+FDQKRkJIVWy5Fo0 X-Received: by 10.50.67.179 with SMTP id o19mr1090232igt.63.1441093769718; Tue, 01 Sep 2015 00:49:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Tue, 1 Sep 2015 00:49:10 -0700 (PDT) In-Reply-To: <20150831185944.GI349@infradead.org> References: <1440590449-20372-1-git-send-email-jtulak@redhat.com> <1440590555-20463-1-git-send-email-jtulak@redhat.com> <1440590555-20463-7-git-send-email-jtulak@redhat.com> <20150831185944.GI349@infradead.org> From: Jan Tulak Date: Tue, 1 Sep 2015 09:49:10 +0200 Message-ID: Subject: Re: [PATCH 07/11] xfsprogs: add nftw64 translation for OS X To: Christoph Hellwig X-ASG-Orig-Subj: Re: [PATCH 07/11] xfsprogs: add nftw64 translation for OS X Cc: xfs-oss Content-Type: multipart/alternative; boundary=047d7bdca6103b95fe051eaacadd X-Barracuda-Connect: mail-ig0-f181.google.com[209.85.213.181] X-Barracuda-Start-Time: 1441093770 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22113 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --047d7bdca6103b95fe051eaacadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 31, 2015 at 8:59 PM, Christoph Hellwig wrote: > On Wed, Aug 26, 2015 at 02:02:31PM +0200, Jan Tulak wrote: > > OS X has only nftw variant - not the 64 suffix used in xfs. > > Can you just use a #define? > > =E2=80=8BYes, indeed I can. Changed... :-) Jan --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --047d7bdca6103b95fe051eaacadd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Au= g 31, 2015 at 8:59 PM, Christoph Hellwig <hch@infradead.org> wrote:
On Wed, = Aug 26, 2015 at 02:02:31PM +0200, Jan Tulak wrote:
> OS X has only nftw variant - not the 64 suffix used in xfs.

Can you just use a #define?


=E2=80=8BYes, indeed= I can. Changed... :-)

=
Jan

--
--047d7bdca6103b95fe051eaacadd-- From jtulak@redhat.com Tue Sep 1 03:04:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 81CCB7F47 for ; Tue, 1 Sep 2015 03:04:40 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 610368F8033 for ; Tue, 1 Sep 2015 01:04:37 -0700 (PDT) X-ASG-Debug-ID: 1441094676-04cb6c0e0f102f0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id LmKURv3EanN3wNEA (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 01 Sep 2015 01:04:36 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id EEF40C1CC1ED; Tue, 1 Sep 2015 08:04:35 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.1.5]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8184YUV003313; Tue, 1 Sep 2015 04:04:35 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: hch@infradead.org, Jan Tulak Subject: [PATCH v2] xfsprogs: add nftw64 translation for OS X Date: Tue, 1 Sep 2015 10:04:32 +0200 X-ASG-Orig-Subj: [PATCH v2] xfsprogs: add nftw64 translation for OS X Message-Id: <1441094672-18368-1-git-send-email-jtulak@redhat.com> In-Reply-To: <20150831185944.GI349@infradead.org> References: <20150831185944.GI349@infradead.org> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441094676 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 UPDATE: changed to #define OS X has only nftw variant - not the 64 suffix used in xfs. Signed-off-by: Jan Tulak --- include/darwin.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/darwin.h b/include/darwin.h index 72d9c1d..f0f05b3 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -157,6 +157,8 @@ typedef int64_t xfs_daddr_t; #define HAVE_FID 1 +#define nftw64 nftw + static __inline__ int platform_discard_blocks(int fd, uint64_t start, uint64_t len) { -- 2.4.3 From jtulak@redhat.com Tue Sep 1 03:13:46 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 5DA6D7F47 for ; Tue, 1 Sep 2015 03:13:46 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id CA9EDAC029 for ; Tue, 1 Sep 2015 01:13:39 -0700 (PDT) X-ASG-Debug-ID: 1441095217-04cb6c0e0f10580001-NocioJ Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) by cuda.sgi.com with ESMTP id MOemAtdj0RguMHIq (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 01 Sep 2015 01:13:37 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com Received: by igbut12 with SMTP id ut12so44295033igb.0 for ; Tue, 01 Sep 2015 01:13:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7Dhbcd1oIjCDXuTJ1Gk88CHpOAqHK5QiTXfcd8O5Huw=; b=YTVwUPv+Ejr4AL3hf0CeedkuI6RVf5vleBNjJP+yPzBKY47d058bo1iKiTDEKnsU8z cPo5odtgrL0Z9psyXCQG05MShKEHGKtF9uY4hc+n304ykv5sN8jAp/zdZrz5ujnhrdT4 YhLHMiKi8KyAtmHVTiKYlzWb28PEHd7Gum3y/D9ItaHtQu2RqRxmkWWY3tVWslFcXqnx ur9quxgJvtvEh0wrefN3yNC6s6FoRMER6rCpnlf+lQUtRmEV9/JYrOZQje78/eN5qb+u ejrrpsNCzzxDc4nBymrrWa63TFj+h3GXXS4NMnSXmbOIrK+0ZEE/MCGKRsj2yL9Y3A45 YDoA== X-Gm-Message-State: ALoCoQmDx5HmZm3jICSaxz6otMXnvRBfkV84tqk1vHgxAkpbbPzlYuGOlK7Sl4YlYGiF0wruO6jW X-Received: by 10.50.72.19 with SMTP id z19mr1182859igu.19.1441095216784; Tue, 01 Sep 2015 01:13:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Tue, 1 Sep 2015 01:13:17 -0700 (PDT) In-Reply-To: <20150831185817.GD349@infradead.org> References: <1440590449-20372-1-git-send-email-jtulak@redhat.com> <1440590555-20463-1-git-send-email-jtulak@redhat.com> <1440590555-20463-2-git-send-email-jtulak@redhat.com> <20150831185817.GD349@infradead.org> From: Jan Tulak Date: Tue, 1 Sep 2015 10:13:17 +0200 Message-ID: Subject: Re: [PATCH 02/11] xfsprogs: avoid dependency on linux XATTR_SIZE/LIST_MAX To: Christoph Hellwig X-ASG-Orig-Subj: Re: [PATCH 02/11] xfsprogs: avoid dependency on linux XATTR_SIZE/LIST_MAX Cc: xfs-oss Content-Type: multipart/alternative; boundary=047d7bdca47c7c0682051eab208d X-Barracuda-Connect: mail-ig0-f176.google.com[209.85.213.176] X-Barracuda-Start-Time: 1441095217 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22113 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --047d7bdca47c7c0682051eab208d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 31, 2015 at 8:58 PM, Christoph Hellwig wrote: > > index b1c0c10..d532f44 100644 > > --- a/libhandle/handle.c > > +++ b/libhandle/handle.c > > @@ -21,6 +21,8 @@ > > #include "xfs.h" > > #include "handle.h" > > #include "parent.h" > > +#include "xfs/xfs_arch.h" > > +#include "xfs/xfs_format.h" > > These headers should not be used in libhandle. As mentioned last time I > think libhandle should get it's own LIBHANDLE_XATTR_LIST_MAX define, > separate frome the one for the on disk format. > =E2=80=8BWell, you wrote about adding it into xfs_format.h. I don't recall = (and can't find) anything else regarding XATTR_SIZE... > Eww, looks like we depend on these Linux values in the on disk > defintion. I think we need to add new XFS_XATTR_SIZE_MAX and > XFS_XATTR_LIST_MAX defintions to xfs_format.h and use them where > we currently use these. So =E2=80=8B =E2=80=8Bthe XFS_ defines in xfs_format=E2=80=8B.h should be there, I just = need to add another LIBHANDLE_ variant so we don't include the headers, right? =E2=80=8BCheers, Jan=E2=80=8B --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --047d7bdca47c7c0682051eab208d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Au= g 31, 2015 at 8:58 PM, Christoph Hellwig <hch@infradead.org> wrote:
> index b1c0c10..d5= 32f44 100644
> --- a/libhandle/handle.c
> +++ b/libhandle/handle.c
> @@ -21,6 +21,8 @@
>=C2=A0 #include "xfs.h"
>=C2=A0 #include "handle.h"
>=C2=A0 #include "parent.h"
> +#include "xfs/xfs_arch.h"
> +#include "xfs/xfs_format.h"

These headers should not be used in libhandle.=C2=A0 As mentioned la= st time I
think libhandle should get it's own LIBHANDLE_XATTR_LIST_MAX define, separate frome the one for the on disk format.

=E2=80=8BWell, you wrote about adding it into xfs= _format.h. I don't recall (and can't find) anything else regarding = XATTR_SIZE...=C2=A0

> Eww, looks = like we depend on these Linux values in the on disk
> defintion.=C2=A0 I think we need to = add new XFS_XATTR_SIZE_MAX and
> XFS_XATTR_LIST_MAX defintions to xfs_format.h and use the= m where
> we currently use these.

So =E2=80=8B
=C2=A0
=E2=80=8Bthe XFS_ defines in xfs= _format=E2=80=8B.h should be there, I just need to add another LIBHANDLE_ v= ariant so we don't include the headers, right?

=E2=80=8BCheers,
Jan=E2=80=8B



--
--047d7bdca47c7c0682051eab208d-- From jtulak@redhat.com Tue Sep 1 03:35:59 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 7A2997F47 for ; Tue, 1 Sep 2015 03:35:59 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 05F68AC004 for ; Tue, 1 Sep 2015 01:35:58 -0700 (PDT) X-ASG-Debug-ID: 1441096557-04cbb06acd14670001-NocioJ Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by cuda.sgi.com with ESMTP id UFeCBYQRGq1yZhal (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 01 Sep 2015 01:35:57 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com Received: by iog7 with SMTP id 7so63660927iog.2 for ; Tue, 01 Sep 2015 01:35:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PfM1U5u0VJu0xOw12/4Q/SgOH7VFuAf6E0cCsTYTsak=; b=PhQohOULRI1GRvpTD8YJAOlLAsew33q8B4HjW7xyuMtw/80qNRPnAc4DBnab8gNHGU RMvjNlphZzfebMamxnXe4FbkbIdn3KqcKKFcgIHIP3pUIQUazR9uCjlEehkWnRiutTnY TUHfszfLuy3xkh33wBR/tW4leTMIxcTW8ar/1teyuk7F88dgDqKJRz0aKdqecfhmza2f ytxYvmHVzqI+mMh+Fs2dgXXnG+Gtof/sP+QAZKPyQvu2xwOabgyDi265WR3z3cQsUAIV K2w9MlP1qUw7eGAg1sSh2wC6UcGn6h8I6P0hb5demW5kJK0HtFIFjNKcW1AAN+jaHx8R GysQ== X-Gm-Message-State: ALoCoQlPRam3E6lryKXw+S8sCQnE9QjDFklkkAuwNGnJpELYojEYaHBmlmsfBHAAtBIXaEltcgN2 X-Received: by 10.107.133.213 with SMTP id p82mr35220084ioi.71.1441096556981; Tue, 01 Sep 2015 01:35:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Tue, 1 Sep 2015 01:35:37 -0700 (PDT) In-Reply-To: References: <1440590449-20372-1-git-send-email-jtulak@redhat.com> <1440590555-20463-1-git-send-email-jtulak@redhat.com> <1440590555-20463-2-git-send-email-jtulak@redhat.com> <20150831185817.GD349@infradead.org> From: Jan Tulak Date: Tue, 1 Sep 2015 10:35:37 +0200 Message-ID: Subject: Re: [PATCH 02/11] xfsprogs: avoid dependency on linux XATTR_SIZE/LIST_MAX To: Christoph Hellwig X-ASG-Orig-Subj: Re: [PATCH 02/11] xfsprogs: avoid dependency on linux XATTR_SIZE/LIST_MAX Cc: xfs-oss Content-Type: multipart/alternative; boundary=001a113ece145dce82051eab7002 X-Barracuda-Connect: mail-io0-f170.google.com[209.85.223.170] X-Barracuda-Start-Time: 1441096557 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22114 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --001a113ece145dce82051eab7002 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah, never mind, I noticed I didn't read the last part of Dave's email. It looks clear now. Jan On Tue, Sep 1, 2015 at 10:13 AM, Jan Tulak wrote: > On Mon, Aug 31, 2015 at 8:58 PM, Christoph Hellwig > wrote: > >> > index b1c0c10..d532f44 100644 >> > --- a/libhandle/handle.c >> > +++ b/libhandle/handle.c >> > @@ -21,6 +21,8 @@ >> > #include "xfs.h" >> > #include "handle.h" >> > #include "parent.h" >> > +#include "xfs/xfs_arch.h" >> > +#include "xfs/xfs_format.h" >> >> These headers should not be used in libhandle. As mentioned last time I >> think libhandle should get it's own LIBHANDLE_XATTR_LIST_MAX define, >> separate frome the one for the on disk format. >> > > =E2=80=8BWell, you wrote about adding it into xfs_format.h. I don't recal= l (and > can't find) anything else regarding XATTR_SIZE... > > > Eww, looks like we depend on these Linux values in the on disk > > defintion. I think we need to add new XFS_XATTR_SIZE_MAX and > > XFS_XATTR_LIST_MAX defintions to xfs_format.h and use them where > > we currently use these. > > So =E2=80=8B > > =E2=80=8Bthe XFS_ defines in xfs_format=E2=80=8B.h should be there, I jus= t need to add > another LIBHANDLE_ variant so we don't include the headers, right? > > =E2=80=8BCheers, > Jan=E2=80=8B > > > > > -- > Jan Tulak > jtulak@redhat.com / jan@tulak.me > --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --001a113ece145dce82051eab7002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, never mind, I noticed I didn't read the last pa= rt of Dave's email. It looks clear now.

Jan
<= /div>

On Tue, Sep = 1, 2015 at 10:13 AM, Jan Tulak <jtulak@redhat.com> wrote:
= On Mon, Aug 31, 2015 at 8:58 P= M, Christoph Hellwig <hch@in= fradead.org> wro= te:
> index b1c0c= 10..d532f44 100644
> --- a/libhandle/handle.c
> +++ b/libhandle/handle.c
> @@ -21,6 +21,8 @@
>=C2=A0 #include "xfs.h"
>=C2=A0 #include "handle.h"
>=C2=A0 #include "parent.h"
> +#include "xfs/xfs_arch.h"
> +#include "xfs/xfs_format.h"

These headers should not be used in libhandle.=C2=A0 As mentioned la= st time I
think libhandle should get it's own LIBHANDLE_XATTR_LIST_MAX define, separate frome the one for the on disk format.

=E2=80=8BWell, you wrote about adding= it into xfs_format.h. I don't recall (and can't find) anything els= e regarding XATTR_SIZE...=C2=A0

>= Eww, looks like we depend on these Linux values in the on disk
> defintion.=C2=A0 I think= we need to add new XFS_XATTR_SIZE_MAX and
> XFS_XATTR_LIST_MAX defintions to xfs_format.h= and use them where
> we currently use= these.

So =E2=80=8B
=C2=A0
=E2=80=8Bthe XFS_ de= fines in xfs_format=E2=80=8B.h should be there, I just need to add another = LIBHANDLE_ variant so we don't include the headers, right?
<= div>

=E2=80=8BCheers,
Jan= =E2=80=8B



=
--



--
Jan Tulak<= br>
jtulak@redh= at.com=C2=A0/ jan@tul= ak.me
--001a113ece145dce82051eab7002-- From sandeen@sandeen.net Tue Sep 1 07:24:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 81DC37F59 for ; Tue, 1 Sep 2015 07:24:43 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 617FD304039 for ; Tue, 1 Sep 2015 05:24:39 -0700 (PDT) X-ASG-Debug-ID: 1441110278-04cbb06acb19c70001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id AG3IJvHpIFAtK1DZ for ; Tue, 01 Sep 2015 05:24:38 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id E058963C77A5; Tue, 1 Sep 2015 07:24:37 -0500 (CDT) Subject: Re: Ask help on an issue 'XFS (sd*): discard failed for extent, error 5' To: Jevon Qiao , xfs-oss X-ASG-Orig-Subj: Re: Ask help on an issue 'XFS (sd*): discard failed for extent, error 5' References: <55E52198.7070607@unitedstack.com> <55E52975.8020005@sandeen.net> <55E53C84.1040606@unitedstack.com> From: Eric Sandeen X-Enigmail-Draft-Status: N1110 Message-ID: <55E59905.80105@sandeen.net> Date: Tue, 1 Sep 2015 07:24:37 -0500 MIME-Version: 1.0 In-Reply-To: <55E53C84.1040606@unitedstack.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441110278 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22118 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/1/15 12:49 AM, Jevon Qiao wrote: > Hi Eric > > Thank you very much for the prompt response. > On 1/9/15 12:28, Eric Sandeen wrote: >> On 8/31/15 10:55 PM, Jevon Qiao wrote: >>> Hi All, >>> >>> Currently, I notice that there are lot's of errors written in the /var/log/messages file. >>> >>> 2015-08-29T23:58:54.477236+00:00 server-68 kernel: sd 0:0:4:0: [sdc] >>> 2015-08-29T23:58:54.477255+00:00 server-68 kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE >>> 2015-08-29T23:58:54.477256+00:00 server-68 kernel: sd 0:0:4:0: [sdc] >>> 2015-08-29T23:58:54.477257+00:00 server-68 kernel: Sense Key : Illegal Request [current] >>> 2015-08-29T23:58:54.477258+00:00 server-68 kernel: sd 0:0:4:0: [sdc] >>> 2015-08-29T23:58:54.477259+00:00 server-68 kernel: Add. Sense: Invalid field in parameter list >>> 2015-08-29T23:58:54.477260+00:00 server-68 kernel: sd 0:0:4:0: [sdc] CDB: >>> 2015-08-29T23:58:54.477261+00:00 server-68 kernel: Unmap/Read sub-channel: 42 00 00 00 00 00 00 00 18 00 >>> 2015-08-29T23:58:54.477263+00:00 server-68 kernel: end_request: critical target error, dev sdc, sector 325046824 >>> 2015-08-29T23:58:54.477268+00:00 server-68 kernel: XFS (sdc2): discard failed for extent [0x64815,2021], error 5 >>> >>> Has anyone encountered the same issue before? How can you solve it? >> Looks like xfs is simply reacting to errors from the storage; I'd try to get >> to the bottom of why you're getting all those scsi errors. > I just want to understand the meaning of 'XFS (sdc2): discard failed > for extent [0x64815,2021], error 5', does it mean one of the layers > beneath xfs does not support DISCARD? Could you please show me more > clues? "error 5" is EIO. That's as much as I can tell you from the XFS perspective. I don't know what the block/scsi errors mean, exactly; it does seem as if it may not support discard, but it must have advertised that it did, or the discard would not have been issued in the first place. You haven't said what kernel or storage you're on. OTOH, even if you do, it's a scsi/storage issue that the xfs list probably can't help much with. -Eric > Thanks, > Jevon >> But probably not on the xfs list. :) >> >> -Eric >> >>> Thanks, >>> Jevon >>> >>> >>> _______________________________________________ >>> xfs mailing list >>> xfs@oss.sgi.com >>> http://oss.sgi.com/mailman/listinfo/xfs >>> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs > > > From bfoster@redhat.com Tue Sep 1 09:04:50 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 4F84D7F5E for ; Tue, 1 Sep 2015 09:04:50 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id D19EEAC00E for ; Tue, 1 Sep 2015 07:04:46 -0700 (PDT) X-ASG-Debug-ID: 1441116284-04cb6c0e0c186b0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 1dCm12GMbNN8p6GE (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 01 Sep 2015 07:04:45 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id CEC5591C17 for ; Tue, 1 Sep 2015 14:04:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-103.bos.redhat.com [10.18.41.103]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t81E4ivP025097; Tue, 1 Sep 2015 10:04:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 5F4FD123E8A; Tue, 1 Sep 2015 10:04:43 -0400 (EDT) Date: Tue, 1 Sep 2015 10:04:43 -0400 From: Brian Foster To: Eryu Guan Cc: xfs@oss.sgi.com Subject: Re: [PATCH] repair: fix wrong logic when validating node magic number Message-ID: <20150901140442.GA16640@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH] repair: fix wrong logic when validating node magic number References: <1439449276-1699-1-git-send-email-eguan@redhat.com> <20150813071524.GI17933@dhcp-13-216.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150813071524.GI17933@dhcp-13-216.nay.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1441116285 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Aug 13, 2015 at 03:15:24PM +0800, Eryu Guan wrote: > On Thu, Aug 13, 2015 at 03:01:16PM +0800, Eryu Guan wrote: > > Magic number is wrong only when != XFS_DA_NODE_MAGIC and > > != XFS_DA3_NODE_MAGIC. > > > > This is triggered by shared/002 when testing 512 block size XFS. > > > > Phase 1 - find and verify superblock... > > Phase 2 - using internal log > > - scan filesystem freespace and inode maps... > > - found root inode chunk > > Phase 3 - for each AG... > > - scan (but don't clear) agi unlinked lists... > > - process known inodes and perform inode discovery... > > - agno = 0 > > bad magic number febe in block 64 (108) for directory inode 35 > > ...... > > > > Fix it by changing "||" to "&&". > > > > Signed-off-by: Eryu Guan > > With this patch applied, shared/002 still fails on 512 block size XFS, > full xfs_repair -n output is > > *** xfs_repair -n output *** > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan (but don't clear) agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > problem with attribute contents in inode 35 > would clear attr fork > bad nblocks 67 for inode 35, would reset to 0 > bad anextents 5 for inode 35, would reset to 0 > - agno = 1 > - agno = 2 > - agno = 3 > - process newly discovered inodes... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > No modify flag set, skipping phase 5 > Phase 6 - check inode connectivity... > - traversing filesystem ... > - traversal finished ... > - moving disconnected inodes to lost+found ... > Phase 7 - verify link counts... > No modify flag set, skipping filesystem flush and exiting. > *** end xfs_repair output > > And a simplified reproducer is just adding >= 577 xattrs to file foo on > 512 block size XFS, no dmflaky is needed. > > num_xattrs=577 > for ((i = 1; i <= $num_xattrs; i++)); do > name="user.attr_$(printf "%04d" $i)" > $SETFATTR_PROG -n $name -v "val_$(printf "%04d" $i)" $SCRATCH_MNT/foo > done > > And it's easily reproduced. > Thanks for the reproducer. This looks like a bug in xfs_repair. Care to test the appended hunk? Brian ---8<--- diff --git a/repair/attr_repair.c b/repair/attr_repair.c index 83a07a8..b76618a 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -562,7 +562,7 @@ verify_da_path(xfs_mount_t *mp, } newnode = (xfs_da_intnode_t *)XFS_BUF_PTR(bp); - btree = M_DIROPS(mp)->node_tree_p(node); + btree = M_DIROPS(mp)->node_tree_p(newnode); M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, newnode); /* From darrick.wong@oracle.com Tue Sep 1 11:31:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 0D6217F5E for ; Tue, 1 Sep 2015 11:31:48 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id EE5CE304051 for ; Tue, 1 Sep 2015 09:31:47 -0700 (PDT) X-ASG-Debug-ID: 1441125105-04cbb06acb23910001-NocioJ Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by cuda.sgi.com with ESMTP id fBPE9m7JIWL0tXDH (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 01 Sep 2015 09:31:45 -0700 (PDT) X-Barracuda-Envelope-From: darrick.wong@oracle.com X-Barracuda-Apparent-Source-IP: 156.151.31.81 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t81GVMdP029800 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Sep 2015 16:31:22 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t81GVM3c029898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Sep 2015 16:31:22 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t81GVLRU019469; Tue, 1 Sep 2015 16:31:22 GMT Received: from localhost (/24.21.154.84) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Sep 2015 09:31:21 -0700 Date: Tue, 1 Sep 2015 09:31:20 -0700 From: "Darrick J. Wong" To: Jan Tulak Cc: xfs@oss.sgi.com, hch@infradead.org Subject: Re: [PATCH v2] xfsprogs: add nftw64 translation for OS X Message-ID: <20150901163120.GA10397@birch.djwong.org> X-ASG-Orig-Subj: Re: [PATCH v2] xfsprogs: add nftw64 translation for OS X References: <20150831185944.GI349@infradead.org> <1441094672-18368-1-git-send-email-jtulak@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441094672-18368-1-git-send-email-jtulak@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Barracuda-Connect: userp1040.oracle.com[156.151.31.81] X-Barracuda-Start-Time: 1441125105 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22123 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines On Tue, Sep 01, 2015 at 10:04:32AM +0200, Jan Tulak wrote: > UPDATE: changed to #define > > OS X has only nftw variant - not the 64 suffix used in xfs. > > Signed-off-by: Jan Tulak > --- > include/darwin.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/darwin.h b/include/darwin.h > index 72d9c1d..f0f05b3 100644 > --- a/include/darwin.h > +++ b/include/darwin.h > @@ -157,6 +157,8 @@ typedef int64_t xfs_daddr_t; > > #define HAVE_FID 1 > > +#define nftw64 nftw > + Sorry for chiming in late, but there's only one caller of nftw64 and several callers of nftw; why not just change it to use nftw? There could be other reasons why xfs_estimate requires the -64 variant, but I don't know. :) --D > static __inline__ int > platform_discard_blocks(int fd, uint64_t start, uint64_t len) > { > -- > 2.4.3 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From BATV+5a39f5d6752f52bcf57a+4391+infradead.org+hch@bombadil.srs.infradead.org Tue Sep 1 12:24:41 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 60A067F5E for ; Tue, 1 Sep 2015 12:24:41 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 4382D8F8035 for ; Tue, 1 Sep 2015 10:24:38 -0700 (PDT) X-ASG-Debug-ID: 1441128276-04cbb06aca25470001-NocioJ Received: from bombadil.infradead.org ([198.137.202.9]) by cuda.sgi.com with ESMTP id QBbwh3X5J0WfZfy1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 01 Sep 2015 10:24:36 -0700 (PDT) X-Barracuda-Envelope-From: BATV+5a39f5d6752f52bcf57a+4391+infradead.org+hch@bombadil.srs.infradead.org X-Barracuda-Apparent-Source-IP: 198.137.202.9 Received: from hch by bombadil.infradead.org with local (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZWpIQ-0003xS-Oy; Tue, 01 Sep 2015 17:24:34 +0000 Date: Tue, 1 Sep 2015 10:24:34 -0700 From: Christoph Hellwig To: "Darrick J. Wong" Cc: Jan Tulak , xfs@oss.sgi.com, hch@infradead.org Subject: Re: [PATCH v2] xfsprogs: add nftw64 translation for OS X Message-ID: <20150901172434.GB14759@infradead.org> X-ASG-Orig-Subj: Re: [PATCH v2] xfsprogs: add nftw64 translation for OS X References: <20150831185944.GI349@infradead.org> <1441094672-18368-1-git-send-email-jtulak@redhat.com> <20150901163120.GA10397@birch.djwong.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150901163120.GA10397@birch.djwong.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: UNKNOWN[198.137.202.9] X-Barracuda-Start-Time: 1441128276 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.10 X-Barracuda-Spam-Status: No, SCORE=0.10 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22124 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS On Tue, Sep 01, 2015 at 09:31:20AM -0700, Darrick J. Wong wrote: > Sorry for chiming in late, but there's only one caller of nftw64 and several > callers of nftw; why not just change it to use nftw? That sounds even better. From dev@lynxeye.de Tue Sep 1 13:10:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 5159B7F5E for ; Tue, 1 Sep 2015 13:10:22 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 34803304059 for ; Tue, 1 Sep 2015 11:10:18 -0700 (PDT) X-ASG-Debug-ID: 1441131016-04bdf06dd625dc0001-NocioJ Received: from lynxeye.de (ns.lynxeye.de [87.118.118.114]) by cuda.sgi.com with ESMTP id dD3hJzqQtH1enM73 for ; Tue, 01 Sep 2015 11:10:16 -0700 (PDT) X-Barracuda-Envelope-From: dev@lynxeye.de X-Barracuda-Apparent-Source-IP: 87.118.118.114 Received: by lynxeye.de (Postfix, from userid 501) id AE3D326C2002; Tue, 1 Sep 2015 20:10:15 +0200 (CEST) Received: from tellur.intern.lynxeye.de (p57B5E453.dip0.t-ipconnect.de [87.181.228.83]) by lynxeye.de (Postfix) with ESMTPA id 3BB3026C2001; Tue, 1 Sep 2015 20:10:14 +0200 (CEST) From: Lucas Stach To: Dave Chinner Cc: xfs@oss.sgi.com Subject: [PATCH] progs: use make provided CURDIR instead of rolling our own Date: Tue, 1 Sep 2015 20:10:10 +0200 X-ASG-Orig-Subj: [PATCH] progs: use make provided CURDIR instead of rolling our own Message-Id: <1441131010-5439-1-git-send-email-dev@lynxeye.de> X-Mailer: git-send-email 2.1.0 X-Barracuda-Connect: ns.lynxeye.de[87.118.118.114] X-Barracuda-Start-Time: 1441131016 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22126 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- This fixes broken header symlinks when make isn't triggered from the xfsprogs source location, but as a recursion from another make in a different directory. This is a common pattern found in cross build systems. Signed-off-by: Lucas Stach --- include/Makefile | 2 +- libxfs/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/Makefile b/include/Makefile index 51ac955..6148756 100644 --- a/include/Makefile +++ b/include/Makefile @@ -67,7 +67,7 @@ include $(BUILDRULES) install-headers: $(addsuffix -hdrs, $(PHFILES) $(DKHFILES) $(HFILES)) %-hdrs: - $(Q)$(LN_S) -f $(PWD)/include/$* xfs/$* + $(Q)$(LN_S) -f $(CURDIR)/$* xfs/$* install: default $(INSTALL) -m 755 -d $(PKG_INC_DIR) diff --git a/libxfs/Makefile b/libxfs/Makefile index 85c3ed7..ecf1921 100644 --- a/libxfs/Makefile +++ b/libxfs/Makefile @@ -134,7 +134,7 @@ install: default install-headers: $(addsuffix -hdrs, $(PKGHFILES)) %-hdrs: - $(Q)$(LN_S) -f $(PWD)/libxfs/$* $(TOPDIR)/include/xfs/$* + $(Q)$(LN_S) -f $(CURDIR)/$* $(TOPDIR)/include/xfs/$* install-dev: install $(INSTALL) -m 644 $(PKGHFILES) $(PKG_INC_DIR) -- 2.1.0 From hd-xfs=oss.sgi.com@gduser.com Tue Sep 1 13:43:58 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id EB52B7F5E for ; Tue, 1 Sep 2015 13:43:58 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id DBCF08F804C for ; Tue, 1 Sep 2015 11:43:58 -0700 (PDT) X-ASG-Debug-ID: 1441133033-04cbb06acd27be0001-NocioJ Received: from smarter.gduser.com (smarter.gduser.com [69.12.64.104]) by cuda.sgi.com with ESMTP id jwKOklOZHYGkTnrq for ; Tue, 01 Sep 2015 11:43:55 -0700 (PDT) X-Barracuda-Envelope-From: hd-xfs=oss.sgi.com@gduser.com X-Barracuda-Apparent-Source-IP: 69.12.64.104 Received: by smarter.gduser.com id hsnouq0001gn for ; Tue, 1 Sep 2015 18:35:21 +0000 (envelope-from ) MIME-Version: 1.0 From: "HealthyDigest" To: xfs@oss.sgi.com Subject: Sick of Looking and Feeling Heavy? Date: Tue, 1 Sep 2015 18:35:21 +0000 X-ASG-Orig-Subj: Sick of Looking and Feeling Heavy? Content-Type: text/plain; Message-ID: <0.0.0.48.1D0E4E4F587C4A4.D6E2A9@smarter.gduser.com> X-Barracuda-Connect: smarter.gduser.com[69.12.64.104] X-Barracuda-Start-Time: 1441133033 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.50 X-Barracuda-Spam-Status: No, SCORE=1.50 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MV0702 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22128 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.50 BSF_SC0_MV0702 Custom rule MV0702 New probiotic supplement helps to aid your digestion system, helping you lose those unwanted pounds without starving yourself or excercise. Get rid of bloating, diarrhea, and constipation once and for all! . Finally get the body you can be proud of. Don't believe us? We're letting you try a free sample on us. Go to http://gduser.com/FYnRaAkSBg1CHzNAfJ1f . . . . . . . . . . To get removed go here: http://gduser.com/DmR1On8GuvuTVsxViZPF From dennis.emaillist2@gmail.com Tue Sep 1 14:13:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,T_DKIM_INVALID autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 216A57F5F for ; Tue, 1 Sep 2015 14:13:43 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id C02F3AC00E for ; Tue, 1 Sep 2015 12:13:39 -0700 (PDT) X-ASG-Debug-ID: 1441134817-04bdf06dd7279d0001-NocioJ Received: from mail-pa0-f66.google.com (mail-pa0-f66.google.com [209.85.220.66]) by cuda.sgi.com with ESMTP id EhKDAaREwpL1UunQ (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 01 Sep 2015 12:13:38 -0700 (PDT) X-Barracuda-Envelope-From: dennis.emaillist2@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.220.66 X-Barracuda-IPDD: Level1 [gmail.com/209.85.220.66] Received: by paddd1 with SMTP id dd1so543631pad.0 for ; Tue, 01 Sep 2015 12:13:37 -0700 (PDT) X-Barracuda-IPDD: Level1 [gmail.com/209.85.220.66] X-Barracuda-IPDD: Level1 [gmail.com/209.85.220.66] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=return-receipt-to:from:to:subject:date:message-id:mime-version :content-type:thread-index:content-language :disposition-notification-to; bh=X4btj6rYjwjt6CxIMsxkKLGSSFZhwFPahgO2qrhs0XM=; b=dhpOlnJ5T7QJ3oyDXxFFNcVOvFosNVTrJwDWZeD5Jv1BhL2/pzIWnGUiRJPp1AmXMt cWbk1r8F0VI/QH56yAcobNr9d/6fsUpKe4bQVY1mWd9ffRHEqHJ+wfT+JRh9uY5Kodfx nbxSEVk8OuHeAOLbEsvuDXu5qMLyBUZpLO5Fih68t4JEKOF+9Re0625fk+A344kaU1aR iCICyGIZXQn2R1PaDoyJo3mzKVUCYsUBTV8JEg5JrwxbAbSFmMY8vJ+DpujFsoX8/saq XTqYfpbqc3RsWaLkaFW8nhqDsxQMZVaaoqocdu92XJCwxe72m/hdPJbokD3PQz83X8mK +fnQ== X-Received: by 10.68.220.226 with SMTP id pz2mr50393525pbc.115.1441134817601; Tue, 01 Sep 2015 12:13:37 -0700 (PDT) Received: from infinity01 ([43.247.158.11]) by smtp.gmail.com with ESMTPSA id y8sm19007007pbt.7.2015.09.01.12.13.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Sep 2015 12:13:36 -0700 (PDT) Return-Receipt-To: "Dennis Finch" From: "Dennis Finch" To: Subject: You name it, we fix it Date: Tue, 1 Sep 2015 15:13:21 -0700 X-ASG-Orig-Subj: You name it, we fix it Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A4F_01D0E4C8.C51E8C10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdDlA2nO4WJKA+XqTNWu9vvcK/tEVg== Content-Language: en-us Disposition-Notification-To: "Dennis Finch" X-Barracuda-Connect: mail-pa0-f66.google.com[209.85.220.66] X-Barracuda-Start-Time: 1441134818 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.51 X-Barracuda-Spam-Status: No, SCORE=1.51 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA392f, BSF_SC0_SA_TO_FROM_ADDR_MATCH, DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE, THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22129 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header -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.50 BSF_SC0_SA_TO_FROM_ADDR_MATCH Sender Address Matches Recipient Address 1.00 BSF_SC0_SA392f Custom Rule SA392f This is a multipart message in MIME format. ------=_NextPart_000_0A4F_01D0E4C8.C51E8C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I'm with the data profiling team, and our job is dealing with dirty data. Whether your list is incomplete, outdated, erroneous... you name it, we fix it. Do you require phone verification of names, emails, and other corporate contact info? Or perhaps you need help with online research, data cleansing and datamining. Let's talk about the list you have (or don't have). Hit me up with the best date and time for a phone call Looking forward to hearing from you! Regards, Dennis Finch Business Development Coordinator Note: You were specifically sent this email based upon your company profile. If for some reason this was sent in error or you wish not to receive any further messages from us please reply with subject line as "Exclude" or click here to UNSUBSCRIBE exclude from all future mailings ------=_NextPart_000_0A4F_01D0E4C8.C51E8C10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I'm with the data = profiling team, and our job = is dealing with dirty data. Whether your list is incomplete, outdated, = erroneous... you name it, we fix it.
  

Do you = require phone verification of names, emails, and other corporate contact = info? Or perhaps you need help with online = research, data cleansing and datamining= .  

    = ;

Let's talk about the = list you have (or don't have).

 

Hit me up with the = best date and time for a phone call

 

Looking forward to = hearing from you!

 

Regards,

Dennis = Finch           &n= bsp;           &nb= sp;            =

Business Development Coordinator

 

Note: You were specifically sent this email based upon your company profile. If for = some reason this was sent in error or you wish not to receive any further = messages from us please reply with subject line as "Exclude" or = click here to UNSUBSCRI= BE exclude from all future mailings

 

 

 

------=_NextPart_000_0A4F_01D0E4C8.C51E8C10-- From rjohnston@sgi.com Tue Sep 1 14:36:24 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id AD8287F5F for ; Tue, 1 Sep 2015 14:36:24 -0500 (CDT) Received: from xmail.sgi.com (pv-excas2-dc21.corp.sgi.com [137.38.106.9]) by relay2.corp.sgi.com (Postfix) with ESMTP id 8F6F930405F for ; Tue, 1 Sep 2015 12:36:21 -0700 (PDT) Received: from [134.15.0.158] (134.15.0.158) by xmail.sgi.com (137.38.106.6) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 1 Sep 2015 14:36:21 -0500 Subject: Re: [PATCH] xfsrestore: fix fs uuid order check for incremental restores To: References: <55D5DB95.1280108@sgi.com> <55D5FB95.1280108@sgi.com> From: Rich Johnston Message-ID: <55E5FE34.5050407@sgi.com> Date: Tue, 1 Sep 2015 14:36:20 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55D5FB95.1280108@sgi.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [134.15.0.158] ping, Does anyone have time to review this please? Thanks --Rich From rjohnston@sgi.com Tue Sep 1 14:37:31 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 7C3A67F5F for ; Tue, 1 Sep 2015 14:37:31 -0500 (CDT) Received: from xmail.sgi.com (pv-excas2-dc21.corp.sgi.com [137.38.106.9]) by relay3.corp.sgi.com (Postfix) with ESMTP id 0813CAC011 for ; Tue, 1 Sep 2015 12:37:30 -0700 (PDT) Received: from [134.15.0.158] (134.15.0.158) by xmail.sgi.com (137.38.106.6) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 1 Sep 2015 14:37:30 -0500 Subject: Re: xfsrestore: fix 2GB directory dump limitation for multi-stream To: References: <20150827185445.6E13960EDE2F0@gulag1.americas.sgi.com> From: Rich Johnston Message-ID: <55E5FE79.3030302@sgi.com> Date: Tue, 1 Sep 2015 14:37:29 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150827185445.6E13960EDE2F0@gulag1.americas.sgi.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [134.15.0.158] ping, Does anyone have time to review this please? Thanks --Rich From david@fromorbit.com Tue Sep 1 15:05:09 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 4C57C7F5F for ; Tue, 1 Sep 2015 15:05:09 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id CDF37AC011 for ; Tue, 1 Sep 2015 13:05:05 -0700 (PDT) X-ASG-Debug-ID: 1441137902-04cbb06acc29b10001-NocioJ Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id W47VngO8oHoAx0gP for ; Tue, 01 Sep 2015 13:05:02 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DvBgA/BOZV/wUaLHldgxuBPaoxBopbkRIEAgKBRU0BAQEBAQGBC4QkAQEEOhwjEAgDDgoJJQ8FJQMhE4gtyXcBCyAZhhSFQ4ULB4QsAQSVQYxymm8mhBEsM4JNAQEB Received: from ppp121-44-26-5.lns20.syd4.internode.on.net (HELO dastard) ([121.44.26.5]) by ipmail07.adl2.internode.on.net with ESMTP; 02 Sep 2015 05:35:01 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZWrnU-0002eY-J2; Wed, 02 Sep 2015 06:04:48 +1000 Date: Wed, 2 Sep 2015 06:04:48 +1000 From: Dave Chinner To: Lucas Stach Cc: xfs@oss.sgi.com Subject: Re: [PATCH] progs: use make provided CURDIR instead of rolling our own Message-ID: <20150901200448.GK26895@dastard> X-ASG-Orig-Subj: Re: [PATCH] progs: use make provided CURDIR instead of rolling our own References: <1441131010-5439-1-git-send-email-dev@lynxeye.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441131010-5439-1-git-send-email-dev@lynxeye.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1441137902 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22130 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 01, 2015 at 08:10:10PM +0200, Lucas Stach wrote: > This fixes broken header symlinks when make isn't triggered from the xfsprogs > source location, but as a recursion from another make in a different > directory. This is a common pattern found in cross build systems. It should actually use TOPDIR to be consistent with the result of the makefiles. i.e. all paths are relative to TOPDIR, not PWD or CURDIR. Cheers, Dave. -- Dave Chinner david@fromorbit.com From rjohnston@sgi.com Tue Sep 1 15:38:31 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 130907F5F for ; Tue, 1 Sep 2015 15:38:31 -0500 (CDT) Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay3.corp.sgi.com (Postfix) with ESMTP id 6EA20AC011; Tue, 1 Sep 2015 13:38:30 -0700 (PDT) Received: from gulag1.americas.sgi.com (gulag1.americas.sgi.com [128.162.236.41]) by estes.americas.sgi.com (Postfix) with ESMTP id 1C1A27002A3A; Tue, 1 Sep 2015 15:38:30 -0500 (CDT) Received: by gulag1.americas.sgi.com (Postfix, from userid 48222) id DC35C60EDE2F0; Tue, 1 Sep 2015 15:38:29 -0500 (CDT) Subject: [RESEND PATCH] xfsrestore: fix fs uuid order check for incremental restores From: Rich Johnston To: Message-ID: <55D5FB95.1280108@sgi.com> References: <<20150826213133.GB3902@dastard>> In-Reply-To: <<20150826213133.GB3902@dastard>> Content-Disposition: inline; filename="fix-fs-uuid-order-check.patch" Date: Tue, 1 Sep 2015 15:38:29 -0500 (CDT) Restoring an incremental level 1 dump will fail with the following error if the fs uuid of the most recent level 0 dump in the inventory does not match level 1 dump we are restoring. xfsrestore: ERROR: selected dump not based on previously applied dump This can happen when you have multiple filesystems and you are restoring a level 1 or greater dump of filesystem FS1 but the most recent level 0 dump in the inventory was filesystem FS2 The fix is to ensure the fs uuid of the inventory entry and the dump to be restored match. Signed-off-by: Rich Johnston --- dump/content.c | 8 ++- inventory/inv_api.c | 108 ++++++++++++++++++++++++++++++-------------------- inventory/inv_mgr.c | 32 ++++++++++---- inventory/inv_priv.h | 7 +-- inventory/inventory.h | 5 ++ restore/content.c | 17 +++++-- 6 files changed, 113 insertions(+), 64 deletions(-) Index: b/dump/content.c =================================================================== --- a/dump/content.c +++ b/dump/content.c @@ -872,7 +872,7 @@ content_init( intgen_t argc, sameinterruptedpr = BOOL_FALSE; interruptedpr = BOOL_FALSE; - ok = inv_get_session_byuuid( &baseuuid, &sessp ); + ok = inv_get_session_byuuid( &fsid, &baseuuid, &sessp ); if ( ! ok ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "could not find specified base dump (%s) " @@ -983,7 +983,8 @@ content_init( intgen_t argc, "online inventory not available\n") ); return BOOL_FALSE; } - ok = inv_lastsession_level_lessthan( inv_idbt, + ok = inv_lastsession_level_lessthan( &fsid, + inv_idbt, ( u_char_t )sc_level, &sessp ); if ( ! ok ) { @@ -1022,7 +1023,8 @@ content_init( intgen_t argc, if ( inv_idbt != INV_TOKEN_NULL ) { /* REFERENCED */ bool_t ok1; - ok = inv_lastsession_level_equalto( inv_idbt, + ok = inv_lastsession_level_equalto( &fsid, + inv_idbt, ( u_char_t )sc_level, &sessp ); ok1 = inv_close( inv_idbt ); Index: b/inventory/inv_api.c =================================================================== --- a/inventory/inv_api.c +++ b/inventory/inv_api.c @@ -596,69 +596,78 @@ inv_free_session( /*----------------------------------------------------------------------*/ -/* inventory_lasttime_level_lessthan */ -/* */ -/* Given a token that refers to a file system, and a level, this returns*/ -/* the last time when a session of a lesser level was done. */ -/* */ -/* returns -1 on error. */ +/* inv_lasttime_level_lessthan */ +/* */ +/* Given a file system uuid, token that refers to a file system, and a */ +/* level, tm is populated with last time when a session of a lesser */ +/* level was done. */ +/* */ +/* Returns TRUE on success. */ /*----------------------------------------------------------------------*/ bool_t inv_lasttime_level_lessthan( - inv_idbtoken_t tok, - u_char level, - time32_t **tm ) + uuid_t *fsidp, + inv_idbtoken_t tok, + u_char level, + time32_t **tm ) { int rval; if ( tok != INV_TOKEN_NULL ) { - rval = search_invt( tok->d_invindex_fd, &level, (void **) tm, - (search_callback_t) tm_level_lessthan ); + rval = search_invt(fsidp, tok->d_invindex_fd, &level, + (void **) tm, + (search_callback_t) tm_level_lessthan); return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; } - return invmgr_query_all_sessions((void *) &level, /* in */ - (void **) tm, /* out */ + return invmgr_query_all_sessions(fsidp, /* fs uuid ptr*/ + (void *) &level, /* in */ + (void **) tm, /* out */ (search_callback_t) tm_level_lessthan); } - - - - /*----------------------------------------------------------------------*/ -/* */ -/* */ -/* */ +/* inv_lastsession_level_lessthan */ +/* */ +/* Given a file system uuid, token that refers to a file system, and a */ +/* level, ses is populated with a session of lesser than the level */ +/* passed in. */ +/* */ +/* Returns FALSE on an error, TRUE if not. If (*ses) is NULL, then the */ +/* search failed. */ /*----------------------------------------------------------------------*/ bool_t inv_lastsession_level_lessthan( - inv_idbtoken_t tok, + uuid_t *fsidp, + inv_idbtoken_t tok, u_char level, - inv_session_t **ses ) + inv_session_t **ses ) { int rval; if ( tok != INV_TOKEN_NULL ) { - rval = search_invt( tok->d_invindex_fd, &level, (void **) ses, - (search_callback_t) lastsess_level_lessthan ); + rval = search_invt(fsidp, tok->d_invindex_fd, &level, + (void **) ses, + (search_callback_t) lastsess_level_lessthan); return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; } - return invmgr_query_all_sessions((void *) &level, /* in */ + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *) &level, /* in */ (void **) ses, /* out */ (search_callback_t) lastsess_level_lessthan); } - - - /*----------------------------------------------------------------------*/ -/* */ -/* */ +/* inv_lastsession_level_equalto */ +/* */ +/* Given a file system uuid, token that refers to a file system, and a */ +/* level, this populates ses with last time when a session of a lesser */ +/* level was done. */ +/* */ /* Return FALSE on an error, TRUE if not. If (*ses) is NULL, then the */ /* search failed. */ /*----------------------------------------------------------------------*/ @@ -666,19 +675,22 @@ inv_lastsession_level_lessthan( bool_t inv_lastsession_level_equalto( + uuid_t *fsidp, inv_idbtoken_t tok, u_char level, inv_session_t **ses ) { int rval; if ( tok != INV_TOKEN_NULL ) { - rval = search_invt( tok->d_invindex_fd, &level, (void **) ses, - (search_callback_t) lastsess_level_equalto ); + rval = search_invt(fsidp, tok->d_invindex_fd, &level, + (void **) ses, + (search_callback_t) lastsess_level_equalto); return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; } - return invmgr_query_all_sessions((void *) &level, /* in */ + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *) &level, /* in */ (void **) ses, /* out */ (search_callback_t) lastsess_level_equalto); @@ -688,35 +700,45 @@ inv_lastsession_level_equalto( /*----------------------------------------------------------------------*/ /* inv_getsession_byuuid */ /* */ +/* Given a file system uuid and a session uuid , ses is populated with */ +/* the session that contains the matching system uuid. */ +/* */ +/* Returns FALSE on an error, TRUE if the session was found. */ /*----------------------------------------------------------------------*/ bool_t inv_get_session_byuuid( + uuid_t *fsidp, uuid_t *sesid, inv_session_t **ses) { - return (invmgr_query_all_sessions((void *)sesid, /* in */ - (void **) ses, /* out */ - (search_callback_t) stobj_getsession_byuuid)); + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *) sesid, /* in */ + (void **) ses, /* out */ + (search_callback_t) stobj_getsession_byuuid); } - - /*----------------------------------------------------------------------*/ -/* inv_getsession_byuuid */ +/* inv_getsession_bylabel */ /* */ +/* Given a file system uuid and a session uuid, ses is populated with */ +/* the session that contains the matching system label. */ +/* */ +/* Returns FALSE on an error, TRUE if the session was found. */ /*----------------------------------------------------------------------*/ bool_t inv_get_session_bylabel( + uuid_t *fsidp, char *session_label, inv_session_t **ses) { - return (invmgr_query_all_sessions((void *)session_label, /* in */ - (void **) ses, /* out */ - (search_callback_t) stobj_getsession_bylabel)); + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *) session_label, /* in */ + (void **) ses, /* out */ + (search_callback_t) stobj_getsession_bylabel); } @@ -786,7 +808,7 @@ inv_delete_mediaobj( uuid_t *moid ) return BOOL_FALSE; } - if ( search_invt( invfd, NULL, (void **)&moid, + if ( search_invt( &arr[i].ft_uuid, invfd, NULL, (void **)&moid, (search_callback_t) stobj_delete_mobj ) < 0 ) return BOOL_FALSE; Index: b/inventory/inv_mgr.c =================================================================== --- a/inventory/inv_mgr.c +++ b/inventory/inv_mgr.c @@ -134,6 +134,7 @@ get_sesstoken( inv_idbtoken_t tok ) /*---------------------------------------------------------------------------*/ bool_t invmgr_query_all_sessions ( + uuid_t *fsidp, void *inarg, void **outarg, search_callback_t func) @@ -169,7 +170,7 @@ invmgr_query_all_sessions ( mlog( MLOG_NORMAL | MLOG_INV, _( "INV: Cant get inv-name for uuid\n") ); - return BOOL_FALSE; + continue; } strcat( fname, INV_INVINDEX_PREFIX ); invfd = open( fname, INV_OFLAG(forwhat) ); @@ -178,9 +179,9 @@ invmgr_query_all_sessions ( "INV: Open failed on %s\n"), fname ); - return BOOL_FALSE; + continue; } - result = search_invt( invfd, inarg, &objectfound, func ); + result = search_invt(fsidp, invfd, inarg, &objectfound, func); close(invfd); /* if error return BOOL_FALSE */ @@ -213,6 +214,7 @@ invmgr_query_all_sessions ( intgen_t search_invt( + uuid_t *fsidp, int invfd, void *arg, void **buf, @@ -247,7 +249,7 @@ search_invt( /* we need to get all the invindex headers and seshdrs in reverse order */ for (i = nindices - 1; i >= 0; i--) { - int nsess; + int nsess, j; invt_sescounter_t *scnt = NULL; invt_seshdr_t *harr = NULL; bool_t found; @@ -272,19 +274,31 @@ search_invt( } free ( scnt ); - while ( nsess ) { + for (j = nsess - 1; j >= 0; j--) { + invt_session_t ses; + /* fd is kept locked until we return from the callback routine */ /* Check to see if this session has been pruned * by xfsinvutil before checking it. */ - if ( harr[nsess - 1].sh_pruned ) { - --nsess; + if (harr[j].sh_pruned) { continue; } - found = (* do_chkcriteria ) ( fd, &harr[ --nsess ], - arg, buf ); + + /* if we need to check the fs uuid's and they don't + * match or we fail to get the session record, + * then keep looking + */ + if (fsidp && + (GET_REC_NOLOCK(fd, &ses, sizeof(invt_session_t), + harr[j].sh_sess_off) == + sizeof(invt_session_t)) && + uuid_compare(ses.s_fsid, *fsidp)) + continue ; + + found = (* do_chkcriteria ) (fd, &harr[j], arg, buf); if (! found ) continue; /* we found what we need; just return */ Index: b/inventory/inv_priv.h =================================================================== --- a/inventory/inv_priv.h +++ b/inventory/inv_priv.h @@ -548,11 +548,12 @@ get_headerinfo( int fd, void **hdrs, voi size_t hdrsz, size_t cntsz, bool_t doblock ); bool_t -invmgr_query_all_sessions (void *inarg, void **outarg, search_callback_t func); +invmgr_query_all_sessions(uuid_t *fsidp, void *inarg, void **outarg, + search_callback_t func); intgen_t -search_invt( int invfd, void *arg, void **buf, - search_callback_t do_chkcriteria ); +search_invt(uuid_t *fsidp, int invfd, void *arg, void **buf, + search_callback_t do_chkcriteria); intgen_t invmgr_inv_print( int invfd, invt_pr_ctx_t *prctx); Index: b/inventory/inventory.h =================================================================== --- a/inventory/inventory.h +++ b/inventory/inventory.h @@ -247,18 +247,21 @@ inv_put_mediafile( */ extern bool_t inv_lasttime_level_lessthan( + uuid_t *fsidp, inv_idbtoken_t tok, u_char level, time32_t **time );/* out */ extern bool_t inv_lastsession_level_lessthan( + uuid_t *fsidp, inv_idbtoken_t tok, u_char level, inv_session_t **ses );/* out */ extern bool_t inv_lastsession_level_equalto( + uuid_t *fsidp, inv_idbtoken_t tok, u_char level, inv_session_t **ses );/* out */ @@ -266,11 +269,13 @@ inv_lastsession_level_equalto( /* Given a uuid of a session, return the session structure.*/ extern bool_t inv_get_session_byuuid( + uuid_t *fsidp, uuid_t *sesid, inv_session_t **ses); extern bool_t inv_get_session_bylabel( + uuid_t *fsidp, char *session_label, inv_session_t **ses); Index: b/restore/content.c =================================================================== --- a/restore/content.c +++ b/restore/content.c @@ -2179,8 +2179,9 @@ content_stream_restore( ix_t thrdix ) if ( ! drivep->d_isnamedpipepr && ! drivep->d_isunnamedpipepr ) { - ok = inv_get_session_byuuid( &grhdrp->gh_dumpid, - &sessp ); + ok = inv_get_session_byuuid((uuid_t *)0, + &grhdrp->gh_dumpid, + &sessp); if ( ok && sessp ) { mlog( MLOG_VERBOSE, _( "using online session inventory\n") ); @@ -3736,9 +3737,11 @@ Inv_validate_cmdline( void ) ok = BOOL_FALSE; sessp = 0; if ( tranp->t_reqdumpidvalpr ) { - ok = inv_get_session_byuuid( &tranp->t_reqdumpid, &sessp ); + ok = inv_get_session_byuuid((uuid_t *)0, &tranp->t_reqdumpid, + &sessp ); } else if ( tranp->t_reqdumplabvalpr ) { - ok = inv_get_session_bylabel( tranp->t_reqdumplab, &sessp ); + ok = inv_get_session_bylabel((uuid_t *)0, tranp->t_reqdumplab, + &sessp ); } rok = BOOL_FALSE; if ( ok && sessp ) { @@ -6812,11 +6815,13 @@ askinvforbaseof( uuid_t baseid, inv_sess /* get the base session */ if ( resumedpr ) { - ok = inv_lastsession_level_equalto( invtok, + ok = inv_lastsession_level_equalto( &sessp->s_fsid, + invtok, ( u_char_t )level, &basesessp ); } else { - ok = inv_lastsession_level_lessthan( invtok, + ok = inv_lastsession_level_lessthan( &sessp->s_fsid, + invtok, ( u_char_t )level, &basesessp ); } From dave@fromorbit.com Tue Sep 1 20:25:25 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 5926C7F5F for ; Tue, 1 Sep 2015 20:25:25 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id D6566AC012 for ; Tue, 1 Sep 2015 18:25:21 -0700 (PDT) X-ASG-Debug-ID: 1441157118-04cbb06acc30a50001-NocioJ Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id 4z5EIYdJZDHnoz3u for ; Tue, 01 Sep 2015 18:25:19 -0700 (PDT) X-Barracuda-Envelope-From: dave@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DmBgBLT+ZV/wUaLHldgxuBPaotAQEBAQEBBpt0gUVNAQEBAQEBgQuEUS8jGBhqAzSILcoZhiyKQimEFQWVQ5sjQ4t7JoFKAQuCOywzgk0BAQE Received: from ppp121-44-26-5.lns20.syd4.internode.on.net (HELO dastard) ([121.44.26.5]) by ipmail07.adl2.internode.on.net with ESMTP; 02 Sep 2015 10:55:13 +0930 Received: from disappointment.disaster.area ([192.168.1.110] helo=disappointment) by dastard with esmtp (Exim 4.80) (envelope-from ) id 1ZWwnM-0003Io-Kf; Wed, 02 Sep 2015 11:25:00 +1000 Received: from dave by disappointment with local (Exim 4.86) (envelope-from ) id 1ZWwnM-0000RP-Jg; Wed, 02 Sep 2015 11:25:00 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: kirill.shutemov@linux.intel.com, boaz@plexistor.com Subject: [PATCH] xfs: add ->pfn_mkwrite support for DAX Date: Wed, 2 Sep 2015 11:25:00 +1000 X-ASG-Orig-Subj: [PATCH] xfs: add ->pfn_mkwrite support for DAX Message-Id: <1441157100-1658-1-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 2.5.0 X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1441157118 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22142 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- From: Dave Chinner ->pfn_mkwrite support is needed so that when a page with allocated backing store first takes a write fault the timestamps on the file are updated. THis fixes a generic/080 failure. Signed-off-by: Dave Chinner --- fs/xfs/xfs_file.c | 11 +++++++++++ fs/xfs/xfs_trace.h | 1 + 2 files changed, 12 insertions(+) diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index de2c237..26535ba 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -1546,10 +1546,21 @@ xfs_filemap_fault( return ret; } +static int +xfs_filemap_pfn_mkwrite( + struct vm_area_struct *vma, + struct vm_fault *vmf) +{ + trace_xfs_filemap_pfn_mkwrite(XFS_I(file_inode(vma->vm_file))); + + return dax_pfn_mkwrite(vma, vmf); +} + static const struct vm_operations_struct xfs_file_vm_ops = { .fault = xfs_filemap_fault, .map_pages = filemap_map_pages, .page_mkwrite = xfs_filemap_page_mkwrite, + .pfn_mkwrite = xfs_filemap_pfn_mkwrite, }; STATIC int diff --git a/fs/xfs/xfs_trace.h b/fs/xfs/xfs_trace.h index 8b5432e..63d87f2 100644 --- a/fs/xfs/xfs_trace.h +++ b/fs/xfs/xfs_trace.h @@ -688,6 +688,7 @@ DEFINE_INODE_EVENT(xfs_inode_free_eofblocks_invalid); DEFINE_INODE_EVENT(xfs_filemap_fault); DEFINE_INODE_EVENT(xfs_filemap_page_mkwrite); +DEFINE_INODE_EVENT(xfs_filemap_pfn_mkwrite); DECLARE_EVENT_CLASS(xfs_iref_class, TP_PROTO(struct xfs_inode *ip, unsigned long caller_ip), -- 2.5.0 From qiaojianfeng@unitedstack.com Tue Sep 1 20:34:04 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E5BFB7F5F for ; Tue, 1 Sep 2015 20:34:03 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 8AAC2AC012 for ; Tue, 1 Sep 2015 18:34:03 -0700 (PDT) X-ASG-Debug-ID: 1441157635-04bdf06dd72f640001-NocioJ Received: from smtpbguseast2.qq.com (smtpbguseast2.qq.com [54.204.34.130]) by cuda.sgi.com with ESMTP id zROm8yuHaIDDaLFZ (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 01 Sep 2015 18:33:57 -0700 (PDT) X-Barracuda-Envelope-From: qiaojianfeng@unitedstack.com X-Barracuda-Apparent-Source-IP: 54.204.34.130 X-QQ-mid: bizesmtp9t1441157626t657t246 Received: from Jevons-MacBook-Pro.local (unknown [182.48.117.114]) by esmtp4.qq.com (ESMTP) with id ; Wed, 02 Sep 2015 09:33:45 +0800 (CST) X-QQ-SSF: 01400000000000F0F332B00A0000000 X-QQ-FEAT: oIoGrveFQB9JHABa9b3GdNSp2hbE5NsMTUB4XR2eArOie/NaXM0Dx7OhZLPfO 0Io4evcwiLVU9BbYKJ9aOO6pNtgQpLXaJObxpiHMMIIxl4Jhg5x4H1i8HtolRsg63r8P1D5 EKzDOwW++jT6TxLFED3H53Qh1XV5wQ/pPOo9ag3LckF10TTyC6SHjutGB7BSzipB6OF/nde XF286pnRge74NaMnTsdzdfxvC0zE17K+tzgNbbdb/se1vRjLbox5O X-QQ-GoodBg: 2 Subject: Re: Ask help on an issue 'XFS (sd*): discard failed for extent, error 5' To: Eric Sandeen , xfs-oss X-ASG-Orig-Subj: Re: Ask help on an issue 'XFS (sd*): discard failed for extent, error 5' References: <55E52198.7070607@unitedstack.com> <55E52975.8020005@sandeen.net> <55E53C84.1040606@unitedstack.com> <55E59905.80105@sandeen.net> From: Jevon Qiao Message-ID: <55E651F9.3020805@unitedstack.com> Date: Wed, 2 Sep 2015 09:33:45 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55E59905.80105@sandeen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-QQ-SENDSIZE: 520 X-QQ-Bgrelay: 1 X-Barracuda-Connect: smtpbguseast2.qq.com[54.204.34.130] X-Barracuda-Start-Time: 1441157636 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22142 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 1/9/15 20:24, Eric Sandeen wrote: > On 9/1/15 12:49 AM, Jevon Qiao wrote: >> Hi Eric >> >> Thank you very much for the prompt response. >> On 1/9/15 12:28, Eric Sandeen wrote: >>> On 8/31/15 10:55 PM, Jevon Qiao wrote: >>>> Hi All, >>>> >>>> Currently, I notice that there are lot's of errors written in the /var/log/messages file. >>>> >>>> 2015-08-29T23:58:54.477236+00:00 server-68 kernel: sd 0:0:4:0: [sdc] >>>> 2015-08-29T23:58:54.477255+00:00 server-68 kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE >>>> 2015-08-29T23:58:54.477256+00:00 server-68 kernel: sd 0:0:4:0: [sdc] >>>> 2015-08-29T23:58:54.477257+00:00 server-68 kernel: Sense Key : Illegal Request [current] >>>> 2015-08-29T23:58:54.477258+00:00 server-68 kernel: sd 0:0:4:0: [sdc] >>>> 2015-08-29T23:58:54.477259+00:00 server-68 kernel: Add. Sense: Invalid field in parameter list >>>> 2015-08-29T23:58:54.477260+00:00 server-68 kernel: sd 0:0:4:0: [sdc] CDB: >>>> 2015-08-29T23:58:54.477261+00:00 server-68 kernel: Unmap/Read sub-channel: 42 00 00 00 00 00 00 00 18 00 >>>> 2015-08-29T23:58:54.477263+00:00 server-68 kernel: end_request: critical target error, dev sdc, sector 325046824 >>>> 2015-08-29T23:58:54.477268+00:00 server-68 kernel: XFS (sdc2): discard failed for extent [0x64815,2021], error 5 >>>> >>>> Has anyone encountered the same issue before? How can you solve it? >>> Looks like xfs is simply reacting to errors from the storage; I'd try to get >>> to the bottom of why you're getting all those scsi errors. >> I just want to understand the meaning of 'XFS (sdc2): discard failed >> for extent [0x64815,2021], error 5', does it mean one of the layers >> beneath xfs does not support DISCARD? Could you please show me more >> clues? > "error 5" is EIO. That's as much as I can tell you from the XFS perspective. > > I don't know what the block/scsi errors mean, exactly; it does seem as > if it may not support discard, but it must have advertised that it did, or > the discard would not have been issued in the first place. Thank you for the further help on this. > You haven't said what kernel or storage you're on. > OTOH, even if you do, it's a scsi/storage issue that the xfs list probably > can't help much with. OK, I see. Thanks, Jevon > -Eric > >> Thanks, >> Jevon >>> But probably not on the xfs list. :) >>> >>> -Eric >>> >>>> Thanks, >>>> Jevon >>>> >>>> >>>> _______________________________________________ >>>> xfs mailing list >>>> xfs@oss.sgi.com >>>> http://oss.sgi.com/mailman/listinfo/xfs >>>> >>> _______________________________________________ >>> xfs mailing list >>> xfs@oss.sgi.com >>> http://oss.sgi.com/mailman/listinfo/xfs >> >> From sfr@canb.auug.org.au Tue Sep 1 21:16:57 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6A6AF7F5F for ; Tue, 1 Sep 2015 21:16:57 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 491CB8F8054 for ; Tue, 1 Sep 2015 19:16:54 -0700 (PDT) X-ASG-Debug-ID: 1441160210-04cb6c0e0c2c680001-NocioJ Received: from ozlabs.org (ozlabs.org [103.22.144.67]) by cuda.sgi.com with ESMTP id x4hinpP9D7VvJYY5 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 01 Sep 2015 19:16:52 -0700 (PDT) X-Barracuda-Envelope-From: sfr@canb.auug.org.au X-Barracuda-Apparent-Source-IP: 103.22.144.67 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id DC57314012C; Wed, 2 Sep 2015 12:16:49 +1000 (AEST) Date: Wed, 2 Sep 2015 12:16:49 +1000 From: Stephen Rothwell To: Jens Axboe , Ben Myers , David Chinner , xfs@oss.sgi.com Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph Hellwig , David Jeffery Subject: linux-next: manual merge of the block tree with the xfs tree Message-ID: <20150902121649.7a686b6c@canb.auug.org.au> X-ASG-Orig-Subj: linux-next: manual merge of the block tree with the xfs tree X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ozlabs.org[103.22.144.67] X-Barracuda-Start-Time: 1441160211 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22142 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Hi Jens, Today's linux-next merge of the block tree got a conflict in: fs/xfs/xfs_aops.c between commit: c9eb256eda44 ("xfs: return errors from partial I/O failures to files") from the xfs tree and commit: 4246a0b63bd8 ("block: add a bi_error field to struct bio") from the block tree. I fixed it up (I think - see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au diff --cc fs/xfs/xfs_aops.c index c8637073ef25,c77499bcbd7a..000000000000 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@@ -354,8 -355,7 +353,8 @@@ xfs_end_bio { xfs_ioend_t *ioend = bio->bi_private; - if (!ioend->io_error && !test_bit(BIO_UPTODATE, &bio->bi_flags)) - ioend->io_error = error; - ioend->io_error = bio->bi_error; ++ if (!ioend->io_error) ++ ioend->io_error = bio->bi_error; /* Toss bio and pass work off to an xfsdatad thread */ bio->bi_private = NULL; From eguan@redhat.com Tue Sep 1 21:19:24 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id DE7F27F5F for ; Tue, 1 Sep 2015 21:19:24 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id CA5AD8F8054 for ; Tue, 1 Sep 2015 19:19:24 -0700 (PDT) X-ASG-Debug-ID: 1441160362-04cbb06acd31cb0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id CetCaKOM7PqF7Dsx (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 01 Sep 2015 19:19:23 -0700 (PDT) X-Barracuda-Envelope-From: eguan@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id C0E50A4673 for ; Wed, 2 Sep 2015 02:19:22 +0000 (UTC) Received: from localhost (vpn1-4-221.pek2.redhat.com [10.72.4.221]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t822JKI4016143; Tue, 1 Sep 2015 22:19:22 -0400 Date: Wed, 2 Sep 2015 10:19:20 +0800 From: Eryu Guan To: Brian Foster Cc: xfs@oss.sgi.com Subject: Re: [PATCH] repair: fix wrong logic when validating node magic number Message-ID: <20150902021920.GF538@dhcp-13-216.nay.redhat.com> X-ASG-Orig-Subj: Re: [PATCH] repair: fix wrong logic when validating node magic number References: <1439449276-1699-1-git-send-email-eguan@redhat.com> <20150813071524.GI17933@dhcp-13-216.nay.redhat.com> <20150901140442.GA16640@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150901140442.GA16640@bfoster.bfoster> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1441160363 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 01, 2015 at 10:04:43AM -0400, Brian Foster wrote: > On Thu, Aug 13, 2015 at 03:15:24PM +0800, Eryu Guan wrote: > > On Thu, Aug 13, 2015 at 03:01:16PM +0800, Eryu Guan wrote: > > > Magic number is wrong only when != XFS_DA_NODE_MAGIC and > > > != XFS_DA3_NODE_MAGIC. > > > > > > This is triggered by shared/002 when testing 512 block size XFS. > > > > > > Phase 1 - find and verify superblock... > > > Phase 2 - using internal log > > > - scan filesystem freespace and inode maps... > > > - found root inode chunk > > > Phase 3 - for each AG... > > > - scan (but don't clear) agi unlinked lists... > > > - process known inodes and perform inode discovery... > > > - agno = 0 > > > bad magic number febe in block 64 (108) for directory inode 35 > > > ...... > > > > > > Fix it by changing "||" to "&&". > > > > > > Signed-off-by: Eryu Guan > > > > With this patch applied, shared/002 still fails on 512 block size XFS, > > full xfs_repair -n output is > > > > *** xfs_repair -n output *** > > Phase 1 - find and verify superblock... > > Phase 2 - using internal log > > - scan filesystem freespace and inode maps... > > - found root inode chunk > > Phase 3 - for each AG... > > - scan (but don't clear) agi unlinked lists... > > - process known inodes and perform inode discovery... > > - agno = 0 > > problem with attribute contents in inode 35 > > would clear attr fork > > bad nblocks 67 for inode 35, would reset to 0 > > bad anextents 5 for inode 35, would reset to 0 > > - agno = 1 > > - agno = 2 > > - agno = 3 > > - process newly discovered inodes... > > Phase 4 - check for duplicate blocks... > > - setting up duplicate extent list... > > - check for inodes claiming duplicate blocks... > > - agno = 0 > > - agno = 1 > > - agno = 2 > > - agno = 3 > > No modify flag set, skipping phase 5 > > Phase 6 - check inode connectivity... > > - traversing filesystem ... > > - traversal finished ... > > - moving disconnected inodes to lost+found ... > > Phase 7 - verify link counts... > > No modify flag set, skipping filesystem flush and exiting. > > *** end xfs_repair output > > > > And a simplified reproducer is just adding >= 577 xattrs to file foo on > > 512 block size XFS, no dmflaky is needed. > > > > num_xattrs=577 > > for ((i = 1; i <= $num_xattrs; i++)); do > > name="user.attr_$(printf "%04d" $i)" > > $SETFATTR_PROG -n $name -v "val_$(printf "%04d" $i)" $SCRATCH_MNT/foo > > done > > > > And it's easily reproduced. > > > > Thanks for the reproducer. This looks like a bug in xfs_repair. Care to > test the appended hunk? Test passed after applying this patch, thanks! Tested by shared/002 and the simplified reproducer above. Thanks, Eryu > > Brian > > ---8<--- > > diff --git a/repair/attr_repair.c b/repair/attr_repair.c > index 83a07a8..b76618a 100644 > --- a/repair/attr_repair.c > +++ b/repair/attr_repair.c > @@ -562,7 +562,7 @@ verify_da_path(xfs_mount_t *mp, > } > > newnode = (xfs_da_intnode_t *)XFS_BUF_PTR(bp); > - btree = M_DIROPS(mp)->node_tree_p(node); > + btree = M_DIROPS(mp)->node_tree_p(newnode); > M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, newnode); > > /* From BATV+2f3a38f770abcc6fe02d+4392+infradead.org+hch@bombadil.srs.infradead.org Wed Sep 2 00:12:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 0D7017F5F for ; Wed, 2 Sep 2015 00:12:20 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 94D3BAC012 for ; Tue, 1 Sep 2015 22:12:19 -0700 (PDT) X-ASG-Debug-ID: 1441170737-04cbb06acc35410001-NocioJ Received: from bombadil.infradead.org ([198.137.202.9]) by cuda.sgi.com with ESMTP id H6Vafm0QL2b2BNH0 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 01 Sep 2015 22:12:18 -0700 (PDT) X-Barracuda-Envelope-From: BATV+2f3a38f770abcc6fe02d+4392+infradead.org+hch@bombadil.srs.infradead.org X-Barracuda-Apparent-Source-IP: 198.137.202.9 Received: from hch by bombadil.infradead.org with local (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZX0LJ-0006JZ-7L; Wed, 02 Sep 2015 05:12:17 +0000 Date: Tue, 1 Sep 2015 22:12:17 -0700 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com, boaz@plexistor.com, kirill.shutemov@linux.intel.com Subject: Re: [PATCH] xfs: add ->pfn_mkwrite support for DAX Message-ID: <20150902051217.GA18906@infradead.org> X-ASG-Orig-Subj: Re: [PATCH] xfs: add ->pfn_mkwrite support for DAX References: <1441157100-1658-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441157100-1658-1-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: UNKNOWN[198.137.202.9] X-Barracuda-Start-Time: 1441170737 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.10 X-Barracuda-Spam-Status: No, SCORE=0.10 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22145 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS On Wed, Sep 02, 2015 at 11:25:00AM +1000, Dave Chinner wrote: > From: Dave Chinner > > ->pfn_mkwrite support is needed so that when a page with allocated > backing store first takes a write fault the timestamps on the > file are updated. THis fixes a generic/080 failure. Shouldn't you be able to drop the call to xfs_filemap_page_mkwrite from xfs_filemap_fault now? From jtulak@redhat.com Wed Sep 2 02:12:28 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id CEB1A7F5F for ; Wed, 2 Sep 2015 02:12:28 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id BD2ED304048 for ; Wed, 2 Sep 2015 00:12:25 -0700 (PDT) X-ASG-Debug-ID: 1441177944-04cb6c0e0f31de0001-NocioJ Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) by cuda.sgi.com with ESMTP id o6ObvTyoEYQTGVvF (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 02 Sep 2015 00:12:24 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com Received: by igbut12 with SMTP id ut12so7019406igb.1 for ; Wed, 02 Sep 2015 00:12:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Q9ug+oD5U04AmY0s8nmICz1eqPOGe7O1qKGVun/oVGs=; b=mOmskF1FuKpdE0ZFsIsQjQX2Yf8kUsrxoCQuhppondIbHUy9YhpkCot/SqPT8pwdsD 99CqXCo1EwYPn5r14kGWPwS9l7rQL/30spx3+RL1scybJaUKELW4kjMxhGD+IE/NbVU3 Tlo3vZb6w34WtpS0h2REpCHYAIDOJjig9Gs3melktnY+a6ZWztsQJ95xpXAlOKDPRIKZ hi6D4AG6dSpeU0xDip298ZAbyVUy1HJCgn/RHJWbznU2bsZ/hofUUGmuB+UX4kvVZkHE zawTb3pOUqhi6l0EZfabADxc1kjPIPir+5yVxCi/q11Y6PetdTcCVnhWLy2jq1U69C9i KIYQ== X-Gm-Message-State: ALoCoQlTs1oTulMz/CwEuoygJu4k1VxBNX794aXkExLvrDuvLP5m/K51+TSRIgmkRVuKjmopb2Oy X-Received: by 10.50.66.164 with SMTP id g4mr1741649igt.19.1441177944192; Wed, 02 Sep 2015 00:12:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Wed, 2 Sep 2015 00:12:04 -0700 (PDT) In-Reply-To: <20150901163120.GA10397@birch.djwong.org> References: <20150831185944.GI349@infradead.org> <1441094672-18368-1-git-send-email-jtulak@redhat.com> <20150901163120.GA10397@birch.djwong.org> From: Jan Tulak Date: Wed, 2 Sep 2015 09:12:04 +0200 Message-ID: Subject: Re: [PATCH v2] xfsprogs: add nftw64 translation for OS X To: "Darrick J. Wong" X-ASG-Orig-Subj: Re: [PATCH v2] xfsprogs: add nftw64 translation for OS X Cc: xfs-oss , Christoph Hellwig Content-Type: multipart/alternative; boundary=047d7bdc13386c1b81051ebe631a X-Barracuda-Connect: mail-ig0-f182.google.com[209.85.213.182] X-Barracuda-Start-Time: 1441177944 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22147 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message --047d7bdc13386c1b81051ebe631a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Sep 1, 2015 at 6:31 PM, Darrick J. Wong wrote: > On Tue, Sep 01, 2015 at 10:04:32AM +0200, Jan Tulak wrote: > > UPDATE: changed to #define > > > > OS X has only nftw variant - not the 64 suffix used in xfs. > > > > Signed-off-by: Jan Tulak > > --- > > include/darwin.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/include/darwin.h b/include/darwin.h > > index 72d9c1d..f0f05b3 100644 > > --- a/include/darwin.h > > +++ b/include/darwin.h > > @@ -157,6 +157,8 @@ typedef int64_t xfs_daddr_t; > > > > #define HAVE_FID 1 > > > > +#define nftw64 nftw > > + > > Sorry for chiming in late, but there's only one caller of nftw64 and > several > callers of nftw; why not just change it to use nftw? > > There could be other reasons why xfs_estimate requires the -64 > variant, but I don't know. :) > =E2=80=8BGood idea. I'll run tests after the change=E2=80=8B =E2=80=8Band if nothing bad happens, I send it here. =E2=80=8B --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --047d7bdc13386c1b81051ebe631a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 1, 2015 at 6:31 PM, Darrick J. Wong <darric= k.wong@oracle.com> wrote:
<= span class=3D"">On Tue, Sep 01, 2015 at 10:04:32AM +0200, Jan Tulak wrote:<= br> > UPDATE: changed to #define
>
> OS X has only nftw variant - not the 64 suffix used in xfs.
>
> Signed-off-by: Jan Tulak <jtul= ak@redhat.com>
> ---
>=C2=A0 include/darwin.h | 2 ++
>=C2=A0 1 file changed, 2 insertions(+)
>
> diff --git a/include/darwin.h b/include/darwin.h
> index 72d9c1d..f0f05b3 100644
> --- a/include/darwin.h
> +++ b/include/darwin.h
> @@ -157,6 +157,8 @@ typedef int64_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0xfs_daddr_t;
>
>=C2=A0 #define HAVE_FID=C2=A0 =C2=A0 =C2=A01
>
> +#define nftw64 nftw
> +

Sorry for chiming in late, but there's only one caller of nftw64= and several
callers of nftw; why not just change it to use nftw?

<shrug> There could be other reasons why xfs_estimate requires the -6= 4
variant, but I don't know. :)

=E2=80=8BGood idea. I'll run tests after the change=E2=80= =8B
=C2=A0
=E2=80=8Band if nothing bad happens, I sen= d
it here.
=E2=80=8B
--
--047d7bdc13386c1b81051ebe631a-- From boaz@plexistor.com Wed Sep 2 04:23:39 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 5D1667F5F for ; Wed, 2 Sep 2015 04:23:39 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3DD318F804B for ; Wed, 2 Sep 2015 02:23:36 -0700 (PDT) X-ASG-Debug-ID: 1441185813-04cb6c0e0d344f0001-NocioJ Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by cuda.sgi.com with ESMTP id bfK5Br9hhQi28wzp (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 02 Sep 2015 02:23:34 -0700 (PDT) X-Barracuda-Envelope-From: boaz@plexistor.com X-Barracuda-Apparent-Source-IP: 209.85.212.179 Received: by wicge5 with SMTP id ge5so33504044wic.0 for ; Wed, 02 Sep 2015 02:23:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=S5dbK71g6VLTkGxR3FRRLPiEb6qKkUK5EykqBh7YsAA=; b=QByKttPl30jfGELKwpBgZgvFjdeB6dBwoi60SEtaLyUwoLyE5T93qDPHUrsTZ/xczx MYoiHWycppsD49agnwmmZIY4Z5ll7Z+uLWkqf9WdR2Ui5CTiLdz27ud931DaT/BOyuFX sVEeMNtP+cW3JkgxETiGK4GV5Z0oiVL47CQJib2yRi6Kh15paLGX16PrkkXw4wpA4Pjc yyzJinCWVrPSZyYvF/GAiy49OfJv0yxUD4PprbYd/OyIhVgg7zXLIGxG7Lss7gD7VLD4 dXasNW2V5QakseQRuPI3/jjYuwQLM9oDbb5k6EMEPahnNoECdZX4Hi4shgB8f3bqlaue LAQQ== X-Gm-Message-State: ALoCoQkJYdB8N/TRXfAetRUJqYKoQo7J2ujmAYX1j2rPtTrHgi8UbJqpElkbEgEH913XVJIOijCO X-Received: by 10.180.82.106 with SMTP id h10mr2864476wiy.64.1441185813176; Wed, 02 Sep 2015 02:23:33 -0700 (PDT) Received: from [10.0.0.5] ([207.232.55.62]) by smtp.googlemail.com with ESMTPSA id s1sm2589258wix.13.2015.09.02.02.23.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Sep 2015 02:23:32 -0700 (PDT) Message-ID: <55E6C013.5050907@plexistor.com> Date: Wed, 02 Sep 2015 12:23:31 +0300 From: Boaz Harrosh User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dave Chinner , xfs@oss.sgi.com CC: kirill.shutemov@linux.intel.com Subject: Re: [PATCH] xfs: add ->pfn_mkwrite support for DAX References: <1441157100-1658-1-git-send-email-david@fromorbit.com> X-ASG-Orig-Subj: Re: [PATCH] xfs: add ->pfn_mkwrite support for DAX In-Reply-To: <1441157100-1658-1-git-send-email-david@fromorbit.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-wi0-f179.google.com[209.85.212.179] X-Barracuda-Start-Time: 1441185813 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22150 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 09/02/2015 04:25 AM, Dave Chinner wrote: > From: Dave Chinner > > ->pfn_mkwrite support is needed so that when a page with allocated > backing store first takes a write fault the timestamps on the > file are updated. THis fixes a generic/080 failure. > > Signed-off-by: Dave Chinner Reviewed-by: Boaz Harrosh I made a patch for this yesterday, but yours is better of-course I feel guilty because I sent the patch for the pfn_mkwrite thing, at the time xfs-dax was not yet in, but I forgot all about it when reviewing the xfs-dax. My bad, sorry. Thanks Dave Boaz > --- > fs/xfs/xfs_file.c | 11 +++++++++++ > fs/xfs/xfs_trace.h | 1 + > 2 files changed, 12 insertions(+) > > diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c > index de2c237..26535ba 100644 > --- a/fs/xfs/xfs_file.c > +++ b/fs/xfs/xfs_file.c > @@ -1546,10 +1546,21 @@ xfs_filemap_fault( > return ret; > } > > +static int > +xfs_filemap_pfn_mkwrite( > + struct vm_area_struct *vma, > + struct vm_fault *vmf) > +{ > + trace_xfs_filemap_pfn_mkwrite(XFS_I(file_inode(vma->vm_file))); > + > + return dax_pfn_mkwrite(vma, vmf); > +} > + > static const struct vm_operations_struct xfs_file_vm_ops = { > .fault = xfs_filemap_fault, > .map_pages = filemap_map_pages, > .page_mkwrite = xfs_filemap_page_mkwrite, > + .pfn_mkwrite = xfs_filemap_pfn_mkwrite, > }; > > STATIC int > diff --git a/fs/xfs/xfs_trace.h b/fs/xfs/xfs_trace.h > index 8b5432e..63d87f2 100644 > --- a/fs/xfs/xfs_trace.h > +++ b/fs/xfs/xfs_trace.h > @@ -688,6 +688,7 @@ DEFINE_INODE_EVENT(xfs_inode_free_eofblocks_invalid); > > DEFINE_INODE_EVENT(xfs_filemap_fault); > DEFINE_INODE_EVENT(xfs_filemap_page_mkwrite); > +DEFINE_INODE_EVENT(xfs_filemap_pfn_mkwrite); > > DECLARE_EVENT_CLASS(xfs_iref_class, > TP_PROTO(struct xfs_inode *ip, unsigned long caller_ip), > From roger@filmlight.ltd.uk Wed Sep 2 04:45:35 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 793887F5F for ; Wed, 2 Sep 2015 04:45:35 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 57FE9304043 for ; Wed, 2 Sep 2015 02:45:32 -0700 (PDT) X-ASG-Debug-ID: 1441187129-04cb6c0e0c34af0001-NocioJ Received: from c.mx.filmlight.ltd.uk (c.mx.filmlight.ltd.uk [54.76.112.217]) by cuda.sgi.com with ESMTP id lKvMeehFvsYHwyPk for ; Wed, 02 Sep 2015 02:45:29 -0700 (PDT) X-Barracuda-Envelope-From: roger@filmlight.ltd.uk X-Barracuda-Apparent-Source-IP: 54.76.112.217 Received: from [192.168.0.247] (cpc2-stev6-2-0-cust318.9-2.cable.virginm.net [213.107.89.63]) (Authenticated sender: roger) by omni.filmlight.ltd.uk (Postfix) with ESMTPSA id C31198608EC; Wed, 2 Sep 2015 10:45:27 +0100 (BST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: linux-next: manual merge of the block tree with the xfs tree From: Roger Willcocks X-ASG-Orig-Subj: Re: linux-next: manual merge of the block tree with the xfs tree In-Reply-To: <20150902121649.7a686b6c@canb.auug.org.au> Date: Wed, 2 Sep 2015 10:45:29 +0100 Cc: Roger Willcocks , Jens Axboe , Ben Myers , David Chinner , xfs@oss.sgi.com, David Jeffery , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph Hellwig Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150902121649.7a686b6c@canb.auug.org.au> To: Stephen Rothwell X-Mailer: Apple Mail (2.1878.6) X-Barracuda-Connect: c.mx.filmlight.ltd.uk[54.76.112.217] X-Barracuda-Start-Time: 1441187129 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22150 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 2 Sep 2015, at 03:16, Stephen Rothwell wrote: > Hi Jens, >=20 > Today's linux-next merge of the block tree got a conflict in: >=20 > fs/xfs/xfs_aops.c >=20 > between commit: >=20 > c9eb256eda44 ("xfs: return errors from partial I/O failures to = files") >=20 > from the xfs tree and commit: >=20 > 4246a0b63bd8 ("block: add a bi_error field to struct bio") >=20 > from the block tree. >=20 > I fixed it up (I think - see below) and can carry the fix as necessary > (no action is required). >=20 > --=20 > Cheers, > Stephen Rothwell sfr@canb.auug.org.au >=20 > diff --cc fs/xfs/xfs_aops.c > index c8637073ef25,c77499bcbd7a..000000000000 > --- a/fs/xfs/xfs_aops.c > +++ b/fs/xfs/xfs_aops.c > @@@ -354,8 -355,7 +353,8 @@@ xfs_end_bio > { > xfs_ioend_t *ioend =3D bio->bi_private; >=20 > - if (!ioend->io_error && !test_bit(BIO_UPTODATE, &bio->bi_flags)) > - ioend->io_error =3D error; > - ioend->io_error =3D bio->bi_error; > ++ if (!ioend->io_error) > ++ ioend->io_error =3D bio->bi_error; >=20 > /* Toss bio and pass work off to an xfsdatad thread */ > bio->bi_private =3D NULL; >=20 >=20 This is incorrect; it can clear an earlier error status. It should = probably read: if (!ioend->io_error && bio->bi_error) ioend->io_error =3D bio->bi_error; =97 Roger From jtulak@redhat.com Wed Sep 2 05:54:30 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E49A37F5F for ; Wed, 2 Sep 2015 05:54:29 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 8DF33AC013 for ; Wed, 2 Sep 2015 03:54:29 -0700 (PDT) X-ASG-Debug-ID: 1441191266-04bdf06dd93a120001-NocioJ Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by cuda.sgi.com with ESMTP id xxYpqohKJ0H10pGm (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 02 Sep 2015 03:54:27 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com Received: by iofh134 with SMTP id h134so15265568iof.0 for ; Wed, 02 Sep 2015 03:54:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QLfgLpnKjJ3GBVjBX/TG+1lp14uflKeKcIBL/jNfPd0=; b=TXYzT3cSffNAsr5NrfKBtcQ6FbNZ4Q5gQvdxhtD0RwJhnZUv1MIql1Dmr9fLoKuD+K PzI2Iwzkj0F/GzZTVDg7vFH9iB/GqT/Su49pYR3+F7BEGnOLf8yuiJ8tdJTMH4pcsI/I rZuVXEQTExxhJfD+Wkmtgul2PJLS1ttRILcFsBHBrnhKMMYvwGNXZwaFMR4LdIVDyflx viVtmjl6D/na8kEZoOPPboDKZp3DTZQ43Wflm/0V4HITvs6gxNIY32gemUbDnIqk93Un 5AUcExvXl7SKbCLijspinaQCS3rT2v8op3ARbgE2fw7r6tTklXymKP0gZt2kwpdr8/1H 2I0Q== X-Gm-Message-State: ALoCoQmJPUM4KbmKD6ZvN8EJGaEbnI1G8hNHq77u/SKVDNA+uIQi9GpNcGC5glK3xcdT6EA2MVXP X-Received: by 10.107.158.72 with SMTP id h69mr16147957ioe.52.1441191266316; Wed, 02 Sep 2015 03:54:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Wed, 2 Sep 2015 03:54:06 -0700 (PDT) In-Reply-To: <20150831190005.GJ349@infradead.org> References: <1440590449-20372-1-git-send-email-jtulak@redhat.com> <1440590555-20463-1-git-send-email-jtulak@redhat.com> <1440590555-20463-8-git-send-email-jtulak@redhat.com> <20150831190005.GJ349@infradead.org> From: Jan Tulak Date: Wed, 2 Sep 2015 12:54:06 +0200 Message-ID: Subject: Re: [PATCH 08/11] xfsprogs: Add a timer implementation for OS X To: Christoph Hellwig X-ASG-Orig-Subj: Re: [PATCH 08/11] xfsprogs: Add a timer implementation for OS X Cc: xfs-oss Content-Type: multipart/alternative; boundary=001a1141bd887b8d9f051ec17d71 X-Barracuda-Connect: mail-io0-f170.google.com[209.85.223.170] X-Barracuda-Start-Time: 1441191267 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22151 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --001a1141bd887b8d9f051ec17d71 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 31, 2015 at 9:00 PM, Christoph Hellwig wrote: > On Wed, Aug 26, 2015 at 02:02:32PM +0200, Jan Tulak wrote: > > OS X does not have the timer used in xfs_repair. > > Add a simple implementation providing the required > > capabilities. > > This doesn't look like it would actually work. > =E2=80=8BAs I understand the timer usage, it should periodically send a sig= nal. The timer code I posted really does this, at least when I take the timer_* functions "as it is" outside and test them, calling them in the same order as in the repair code. I tested that before sending the patch. I have to try it in xfs_repair yet - this is limited by having small storage space for a filesystem, where the reporting interval would be noticeable. The best thing for this I have now is an old USB2 8 GB flash drive, filled with multiple copies of installed Debian. However, even on a raspberry pi, it still runs quickly. I guess few hundreds of GB would do it, but I need to dig out an old USB2-sata reduction somewhere and a HDD... (And I didn't noticed any difference in output.) So in meantime, why do you think this won't work? Cheers, Jan --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --001a1141bd887b8d9f051ec17d71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 31, 2015 at 9:00 PM, Christoph Hellwig <hch@inf= radead.org> wrote:
On Wed, Aug 26, = 2015 at 02:02:32PM +0200, Jan Tulak wrote:
> OS X does not have the timer used in xfs_repair.
> Add a simple implementation providing the required
> capabilities.

This doesn't look like it would actually work.

=E2=80=8BAs I understand the timer usage, it shou= ld periodically send a signal. The timer code I posted really does this, at= least when I take the=C2=A0timer_* functions "as it is" outside a= nd test them, calling them in the same order as in the repair code. I teste= d that before sending the patch.

I have = to try it in xfs_repair yet - this is limited by having small storage space= for a filesystem, where the reporting interval would be noticeable. The be= st thing for this I have now is an old USB2 8 GB flash drive, filled with m= ultiple copies of installed Debian. However, even on a raspberry pi, it sti= ll runs quickly. I guess few hundreds of GB would do it, but I need to dig = out an old USB2-sata reduction somewhere and a HDD... (And I didn't not= iced any difference in output.)

So in meantime, w= hy do you think this won't work?

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">Cheers,
Jan

--
--001a1141bd887b8d9f051ec17d71-- From sfr@canb.auug.org.au Wed Sep 2 08:03:51 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 05AF07F5F for ; Wed, 2 Sep 2015 08:03:51 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 8494FAC012 for ; Wed, 2 Sep 2015 06:03:47 -0700 (PDT) X-ASG-Debug-ID: 1441199023-04cb6c0e0c392f0001-NocioJ Received: from ozlabs.org (ozlabs.org [103.22.144.67]) by cuda.sgi.com with ESMTP id BnHN56XZstNV34So (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 02 Sep 2015 06:03:45 -0700 (PDT) X-Barracuda-Envelope-From: sfr@canb.auug.org.au X-Barracuda-Apparent-Source-IP: 103.22.144.67 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 8C3CF14027F; Wed, 2 Sep 2015 23:03:42 +1000 (AEST) Date: Wed, 2 Sep 2015 23:03:42 +1000 From: Stephen Rothwell To: Roger Willcocks Cc: Jens Axboe , Ben Myers , David Chinner , xfs@oss.sgi.com, David Jeffery , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph Hellwig Subject: Re: linux-next: manual merge of the block tree with the xfs tree Message-ID: <20150902230342.125e23ce@canb.auug.org.au> X-ASG-Orig-Subj: Re: linux-next: manual merge of the block tree with the xfs tree In-Reply-To: References: <20150902121649.7a686b6c@canb.auug.org.au> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ozlabs.org[103.22.144.67] X-Barracuda-Start-Time: 1441199024 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22153 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Hi Roger, On Wed, 2 Sep 2015 10:45:29 +0100 Roger Willcocks wrote: > > On 2 Sep 2015, at 03:16, Stephen Rothwell wrote: > > > Today's linux-next merge of the block tree got a conflict in: > > > > fs/xfs/xfs_aops.c > > > > between commit: > > > > c9eb256eda44 ("xfs: return errors from partial I/O failures to files") > > > > from the xfs tree and commit: > > > > 4246a0b63bd8 ("block: add a bi_error field to struct bio") > > > > from the block tree. > > > > I fixed it up (I think - see below) and can carry the fix as necessary > > (no action is required). > > > > -- > > Cheers, > > Stephen Rothwell sfr@canb.auug.org.au > > > > diff --cc fs/xfs/xfs_aops.c > > index c8637073ef25,c77499bcbd7a..000000000000 > > --- a/fs/xfs/xfs_aops.c > > +++ b/fs/xfs/xfs_aops.c > > @@@ -354,8 -355,7 +353,8 @@@ xfs_end_bio > > { > > xfs_ioend_t *ioend = bio->bi_private; > > > > - if (!ioend->io_error && !test_bit(BIO_UPTODATE, &bio->bi_flags)) > > - ioend->io_error = error; > > - ioend->io_error = bio->bi_error; > > ++ if (!ioend->io_error) > > ++ ioend->io_error = bio->bi_error; > > > > /* Toss bio and pass work off to an xfsdatad thread */ > > bio->bi_private = NULL; > > > > > > This is incorrect; it can clear an earlier error status. It should probably read: > > if (!ioend->io_error && bio->bi_error) > ioend->io_error = bio->bi_error; Thanks, I will use that from tomorrow. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au From bfoster@redhat.com Wed Sep 2 08:21:16 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id BD8797F5F for ; Wed, 2 Sep 2015 08:21:16 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 972D18F8052 for ; Wed, 2 Sep 2015 06:21:16 -0700 (PDT) X-ASG-Debug-ID: 1441200075-04cbb06acd41000001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Agch6ubzLHOLMtub (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 02 Sep 2015 06:21:15 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 2C8DAC0F05E1; Wed, 2 Sep 2015 13:21:15 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-103.bos.redhat.com [10.18.41.103]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t82DLELb002808; Wed, 2 Sep 2015 09:21:14 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id C969D123E8A; Wed, 2 Sep 2015 09:21:13 -0400 (EDT) Date: Wed, 2 Sep 2015 09:21:13 -0400 From: Brian Foster To: Rich Johnston Cc: xfs@oss.sgi.com Subject: Re: [RESEND PATCH] xfsrestore: fix fs uuid order check for incremental restores Message-ID: <20150902132112.GB23587@bfoster.bfoster> X-ASG-Orig-Subj: Re: [RESEND PATCH] xfsrestore: fix fs uuid order check for incremental restores References: <20150826213133.GB3902@dastard> <55D5FB95.1280108@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55D5FB95.1280108@sgi.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441200075 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 01, 2015 at 03:38:29PM -0500, Rich Johnston wrote: > Restoring an incremental level 1 dump will fail with the following error > if the fs uuid of the most recent level 0 dump in the inventory does not > match level 1 dump we are restoring. > > xfsrestore: ERROR: selected dump not based on previously applied dump > > This can happen when you have multiple filesystems and you are restoring > a level 1 or greater dump of filesystem FS1 but the most recent level 0 > dump in the inventory was filesystem FS2 > > The fix is to ensure the fs uuid of the inventory entry and the dump to > be restored match. > > Signed-off-by: Rich Johnston > --- I'm not really familiar with xfsdump, but a few comments below... > dump/content.c | 8 ++- > inventory/inv_api.c | 108 ++++++++++++++++++++++++++++++-------------------- > inventory/inv_mgr.c | 32 ++++++++++---- > inventory/inv_priv.h | 7 +-- > inventory/inventory.h | 5 ++ > restore/content.c | 17 +++++-- > 6 files changed, 113 insertions(+), 64 deletions(-) > ... > Index: b/inventory/inv_mgr.c > =================================================================== > --- a/inventory/inv_mgr.c > +++ b/inventory/inv_mgr.c > @@ -134,6 +134,7 @@ get_sesstoken( inv_idbtoken_t tok ) > /*---------------------------------------------------------------------------*/ > bool_t > invmgr_query_all_sessions ( > + uuid_t *fsidp, > void *inarg, > void **outarg, > search_callback_t func) > @@ -169,7 +170,7 @@ invmgr_query_all_sessions ( > mlog( MLOG_NORMAL | MLOG_INV, _( > "INV: Cant get inv-name for uuid\n") > ); > - return BOOL_FALSE; > + continue; > } > strcat( fname, INV_INVINDEX_PREFIX ); > invfd = open( fname, INV_OFLAG(forwhat) ); > @@ -178,9 +179,9 @@ invmgr_query_all_sessions ( > "INV: Open failed on %s\n"), > fname > ); > - return BOOL_FALSE; > + continue; > } Now that the above two cases don't return false, we can end up returning true if these error cases persist throughout the loop. Perhaps we should define 'bool ret = false,' return that variable everywhere and only set it true when appropriate. > - result = search_invt( invfd, inarg, &objectfound, func ); > + result = search_invt(fsidp, invfd, inarg, &objectfound, func); > close(invfd); > > /* if error return BOOL_FALSE */ ... > @@ -272,19 +274,31 @@ search_invt( > } > free ( scnt ); > > - while ( nsess ) { > + for (j = nsess - 1; j >= 0; j--) { > + invt_session_t ses; > + > /* fd is kept locked until we return from the > callback routine */ > > /* Check to see if this session has been pruned > * by xfsinvutil before checking it. > */ > - if ( harr[nsess - 1].sh_pruned ) { > - --nsess; > + if (harr[j].sh_pruned) { > continue; > } > - found = (* do_chkcriteria ) ( fd, &harr[ --nsess ], > - arg, buf ); > + > + /* if we need to check the fs uuid's and they don't > + * match or we fail to get the session record, > + * then keep looking > + */ > + if (fsidp && > + (GET_REC_NOLOCK(fd, &ses, sizeof(invt_session_t), > + harr[j].sh_sess_off) == > + sizeof(invt_session_t)) && > + uuid_compare(ses.s_fsid, *fsidp)) > + continue ; > + This seems like kind of a loaded check. GET_REC_NOLOCK() looks like it returns -1 if the read doesn't return the exact size of the buffer, so we probably don't need to check that here. It also seems like we should return an error if an error occurs rather than just continue on. How about something like this? ... if (fsidp) { ret = GET_REC_NOLOCK(fd, &ses, sizeof(invt_session_t), harr[j].sh_sess_off); if (ret < 0) { /* XXX: clean up here */ return ret; } ret = uuid_compare(ses.s_fsid, *fsidp); if (ret) continue; } > + found = (* do_chkcriteria ) (fd, &harr[j], arg, buf); > if (! found ) continue; > > /* we found what we need; just return */ ... > Index: b/restore/content.c > =================================================================== > --- a/restore/content.c > +++ b/restore/content.c > @@ -2179,8 +2179,9 @@ content_stream_restore( ix_t thrdix ) > if ( ! drivep->d_isnamedpipepr > && > ! drivep->d_isunnamedpipepr ) { > - ok = inv_get_session_byuuid( &grhdrp->gh_dumpid, > - &sessp ); > + ok = inv_get_session_byuuid((uuid_t *)0, > + &grhdrp->gh_dumpid, > + &sessp); > if ( ok && sessp ) { > mlog( MLOG_VERBOSE, _( > "using online session inventory\n") ); > @@ -3736,9 +3737,11 @@ Inv_validate_cmdline( void ) > ok = BOOL_FALSE; > sessp = 0; > if ( tranp->t_reqdumpidvalpr ) { > - ok = inv_get_session_byuuid( &tranp->t_reqdumpid, &sessp ); > + ok = inv_get_session_byuuid((uuid_t *)0, &tranp->t_reqdumpid, > + &sessp ); > } else if ( tranp->t_reqdumplabvalpr ) { > - ok = inv_get_session_bylabel( tranp->t_reqdumplab, &sessp ); > + ok = inv_get_session_bylabel((uuid_t *)0, tranp->t_reqdumplab, > + &sessp ); Can we use NULL instead of 0 in these cases? Not sure the cast is really necessary either..?. Brian > } > rok = BOOL_FALSE; > if ( ok && sessp ) { > @@ -6812,11 +6815,13 @@ askinvforbaseof( uuid_t baseid, inv_sess > /* get the base session > */ > if ( resumedpr ) { > - ok = inv_lastsession_level_equalto( invtok, > + ok = inv_lastsession_level_equalto( &sessp->s_fsid, > + invtok, > ( u_char_t )level, > &basesessp ); > } else { > - ok = inv_lastsession_level_lessthan( invtok, > + ok = inv_lastsession_level_lessthan( &sessp->s_fsid, > + invtok, > ( u_char_t )level, > &basesessp ); > } > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Wed Sep 2 08:21:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id AFE227F66 for ; Wed, 2 Sep 2015 08:21:20 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 31737AC012 for ; Wed, 2 Sep 2015 06:21:20 -0700 (PDT) X-ASG-Debug-ID: 1441200079-04bdf06dd93e500001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 8nBcolQVUaopYgGF (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 02 Sep 2015 06:21:19 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 30DF1341AD6; Wed, 2 Sep 2015 13:21:19 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-103.bos.redhat.com [10.18.41.103]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t82DLIHr003692; Wed, 2 Sep 2015 09:21:19 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id E484B123E8A; Wed, 2 Sep 2015 09:21:17 -0400 (EDT) Date: Wed, 2 Sep 2015 09:21:17 -0400 From: Brian Foster To: Rich Johnston Cc: xfs@oss.sgi.com Subject: Re: xfsrestore: fix 2GB directory dump limitation for multi-stream Message-ID: <20150902132117.GC23587@bfoster.bfoster> X-ASG-Orig-Subj: Re: xfsrestore: fix 2GB directory dump limitation for multi-stream References: <20150827185445.6E13960EDE2F0@gulag1.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150827185445.6E13960EDE2F0@gulag1.americas.sgi.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441200079 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Aug 27, 2015 at 01:54:45PM -0500, Rich Johnston wrote: > > The drive_simple restore path has a 2GB directory limit. Instead of > ASSERTing if nreadneeded64 is greater than INTGENMAX (2GB), add a loop > to handle it. > > Signed-off-by: Rich Johnston > --- I'm not a huge fan of all the spaces used in this code (around the braces and whatnot). It is consistent with the rest of the code but I'd probably get away from that as code is modified. That aside, the change seems fine to me: Reviewed-by: Brian Foster > common/drive_simple.c | 24 +++++++++++++----------- > 1 file changed, 13 insertions(+), 11 deletions(-) > > Index: b/common/drive_simple.c > =================================================================== > --- a/common/drive_simple.c > +++ b/common/drive_simple.c > @@ -765,18 +765,20 @@ do_seek_mark( drive_t *drivep, drive_mar > /* use read_buf util func to eat up difference > */ > nreadneeded64 = mark - strmoff; > - ASSERT( nreadneeded64 <= INTGENMAX ); > - nreadneeded = ( intgen_t )nreadneeded64; > - nread = read_buf( 0, > - ( size_t )nreadneeded, > - ( void * )drivep, > - ( rfp_t )drivep->d_opsp->do_read, > - ( rrbfp_t )drivep->d_opsp->do_return_read_buf, > - &rval ); > - if ( rval ) { > - return rval; > + while ( nreadneeded64 > 0 ) { > + if ( nreadneeded64 > INTGENMAX ) > + nreadneeded = INTGENMAX; > + else > + nreadneeded = ( intgen_t )nreadneeded64; > + nread = read_buf( 0, nreadneeded, drivep, > + ( rfp_t )drivep->d_opsp->do_read, > + ( rrbfp_t )drivep->d_opsp->do_return_read_buf, > + &rval ); > + if ( rval ) { > + return rval; > + } > + nreadneeded64 -= nread; > } > - ASSERT( nread == nreadneeded ); > > /* verify we are on the mark > */ > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From roger@filmlight.ltd.uk Wed Sep 2 08:34:55 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id DB21C7F5F for ; Wed, 2 Sep 2015 08:34:54 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 74915AC013 for ; Wed, 2 Sep 2015 06:34:54 -0700 (PDT) X-ASG-Debug-ID: 1441200892-04bdf06dd93e980001-NocioJ Received: from c.mx.filmlight.ltd.uk (c.mx.filmlight.ltd.uk [54.76.112.217]) by cuda.sgi.com with ESMTP id B35FN6Eyyeblg0Tf for ; Wed, 02 Sep 2015 06:34:52 -0700 (PDT) X-Barracuda-Envelope-From: roger@filmlight.ltd.uk X-Barracuda-Apparent-Source-IP: 54.76.112.217 Received: from [10.44.0.132] (fiero.filmlight.ltd.uk [77.107.81.252]) (Authenticated sender: roger) by omni.filmlight.ltd.uk (Postfix) with ESMTPSA id A039E800480; Wed, 2 Sep 2015 14:34:51 +0100 (BST) Subject: Re: linux-next: manual merge of the block tree with the xfs tree From: Roger Willcocks X-ASG-Orig-Subj: Re: linux-next: manual merge of the block tree with the xfs tree To: Stephen Rothwell Cc: Jens Axboe , David Jeffery , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, Ben Myers , linux-next@vger.kernel.org, Christoph Hellwig In-Reply-To: <20150902230342.125e23ce@canb.auug.org.au> References: <20150902121649.7a686b6c@canb.auug.org.au> <20150902230342.125e23ce@canb.auug.org.au> Content-Type: text/plain Date: Wed, 02 Sep 2015 14:34:51 +0100 Message-Id: <1441200891.17400.1277.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-19.el5) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: c.mx.filmlight.ltd.uk[54.76.112.217] X-Barracuda-Start-Time: 1441200892 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22154 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Wed, 2015-09-02 at 23:03 +1000, Stephen Rothwell wrote: > Hi Roger, > > On Wed, 2 Sep 2015 10:45:29 +0100 Roger Willcocks wrote: > > > > On 2 Sep 2015, at 03:16, Stephen Rothwell wrote: > > > > > ++ if (!ioend->io_error) > > > ++ ioend->io_error = bio->bi_error; > > > > This is incorrect; it can clear an earlier error status. It should probably read: > > > > if (!ioend->io_error && bio->bi_error) > > ioend->io_error = bio->bi_error; > > Thanks, I will use that from tomorrow. > Huh, now I've had my coffee, that extra check doesn't add anything. (There's no harm done in assigning zero to io_error if it's already zero.) Apologies for the noise. -- Roger Willcocks From bfoster@redhat.com Wed Sep 2 08:35:12 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id F38AF7F5F for ; Wed, 2 Sep 2015 08:35:11 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id C42B6304048 for ; Wed, 2 Sep 2015 06:35:08 -0700 (PDT) X-ASG-Debug-ID: 1441200907-04bdf06dd73e990001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id j3RirBcdKpaGaF4Z (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 02 Sep 2015 06:35:08 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 96445A83 for ; Wed, 2 Sep 2015 13:35:07 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-103.bos.redhat.com [10.18.41.103]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t82DZ7bi011002; Wed, 2 Sep 2015 09:35:07 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 50B0E123E8A; Wed, 2 Sep 2015 09:35:06 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Cc: Eryu Guan Subject: [PATCH] xfs_repair: update btree ptr when attr node level moves to next buffer Date: Wed, 2 Sep 2015 09:35:06 -0400 X-ASG-Orig-Subj: [PATCH] xfs_repair: update btree ptr when attr node level moves to next buffer Message-Id: <1441200906-37170-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441200907 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 xfs_repair walks the attribute fork btree for files with a significant number of extended attributes. It creates a cursor, walks the leaf blocks, and verifies the path from each leaf block back to the root of the tree. Eryu reports that the following test causes xfs_repair to report corruption on 512b filesystems: num_xattrs=577 for ((i = 1; i <= $num_xattrs; i++)); do name="user.attr_$(printf "%04d" $i)" setfattr -n $name -v "val_$(printf "%04d" $i)" done xfs_repair complains that the block number of the leaf (level 0) does not match the block number of the level 1 node block entry. This occurs as soon as the left-most level 1 node block is completely processed and the cursor is walked to the next level 1 block in the array. The problem is that while verify_da_path() updates level 1 of the cursor to the next level 1 buffer, it fails to correctly update the btree pointer to the entry list of the new buffer. As a result, the child leaf block of the next node block is incorrectly validated against the entry list of the previous node block. Update verify_da_path() to correctly update the btree pointer to the entry list of the new node block when the cursor is walked forward at higher (non-leaf) levels. Reported-by: Eryu Guan Signed-off-by: Brian Foster --- repair/attr_repair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/repair/attr_repair.c b/repair/attr_repair.c index 83a07a8..b76618a 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -562,7 +562,7 @@ verify_da_path(xfs_mount_t *mp, } newnode = (xfs_da_intnode_t *)XFS_BUF_PTR(bp); - btree = M_DIROPS(mp)->node_tree_p(node); + btree = M_DIROPS(mp)->node_tree_p(newnode); M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, newnode); /* -- 2.1.0 From sfr@canb.auug.org.au Wed Sep 2 08:37:33 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id DBE417F5F for ; Wed, 2 Sep 2015 08:37:33 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id B7EE9304048 for ; Wed, 2 Sep 2015 06:37:33 -0700 (PDT) X-ASG-Debug-ID: 1441201050-04bdf06dd93eac0001-NocioJ Received: from ozlabs.org (ozlabs.org [103.22.144.67]) by cuda.sgi.com with ESMTP id 3L1Oqtae6rcOPcWM (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 02 Sep 2015 06:37:31 -0700 (PDT) X-Barracuda-Envelope-From: sfr@canb.auug.org.au X-Barracuda-Apparent-Source-IP: 103.22.144.67 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 1F8411401C7; Wed, 2 Sep 2015 23:37:30 +1000 (AEST) Date: Wed, 2 Sep 2015 23:37:29 +1000 From: Stephen Rothwell To: Roger Willcocks Cc: Jens Axboe , David Jeffery , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, Ben Myers , linux-next@vger.kernel.org, Christoph Hellwig Subject: Re: linux-next: manual merge of the block tree with the xfs tree Message-ID: <20150902233729.4e824342@canb.auug.org.au> X-ASG-Orig-Subj: Re: linux-next: manual merge of the block tree with the xfs tree In-Reply-To: <1441200891.17400.1277.camel@localhost.localdomain> References: <20150902121649.7a686b6c@canb.auug.org.au> <20150902230342.125e23ce@canb.auug.org.au> <1441200891.17400.1277.camel@localhost.localdomain> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ozlabs.org[103.22.144.67] X-Barracuda-Start-Time: 1441201051 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22154 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Hi Roger, On Wed, 02 Sep 2015 14:34:51 +0100 Roger Willcocks wrote: > > Huh, now I've had my coffee, that extra check doesn't add anything. > (There's no harm done in assigning zero to io_error if it's already > zero.) Apologies for the noise. That's OK, my excuse is being to far at the other end of the day ... I actually now remember thinking the same thing at the time I did it :-) -- Cheers, Stephen Rothwell sfr@canb.auug.org.au From sandeen@sandeen.net Wed Sep 2 11:06:31 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 882147F5F for ; Wed, 2 Sep 2015 11:06:31 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 74548304059 for ; Wed, 2 Sep 2015 09:06:27 -0700 (PDT) X-ASG-Debug-ID: 1441209985-04cb6c0e0f3e680001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id dUVBoa5RWqQyQrZ2 for ; Wed, 02 Sep 2015 09:06:26 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 3E4D363C5E2B; Wed, 2 Sep 2015 11:06:25 -0500 (CDT) Subject: Re: [PATCH] xfs_repair: update btree ptr when attr node level moves to next buffer To: Brian Foster , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs_repair: update btree ptr when attr node level moves to next buffer References: <1441200906-37170-1-git-send-email-bfoster@redhat.com> Cc: Eryu Guan From: Eric Sandeen X-Enigmail-Draft-Status: N1110 Message-ID: <55E71E80.3070508@sandeen.net> Date: Wed, 2 Sep 2015 11:06:24 -0500 MIME-Version: 1.0 In-Reply-To: <1441200906-37170-1-git-send-email-bfoster@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441209985 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22157 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/2/15 8:35 AM, Brian Foster wrote: > xfs_repair walks the attribute fork btree for files with a significant > number of extended attributes. It creates a cursor, walks the leaf > blocks, and verifies the path from each leaf block back to the root of > the tree. Eryu reports that the following test causes xfs_repair to > report corruption on 512b filesystems: > > num_xattrs=577 > for ((i = 1; i <= $num_xattrs; i++)); do > name="user.attr_$(printf "%04d" $i)" > setfattr -n $name -v "val_$(printf "%04d" $i)" > done > > xfs_repair complains that the block number of the leaf (level 0) does > not match the block number of the level 1 node block entry. This occurs > as soon as the left-most level 1 node block is completely processed and > the cursor is walked to the next level 1 block in the array. The problem > is that while verify_da_path() updates level 1 of the cursor to the next > level 1 buffer, it fails to correctly update the btree pointer to the > entry list of the new buffer. As a result, the child leaf block of the > next node block is incorrectly validated against the entry list of the > previous node block. > > Update verify_da_path() to correctly update the btree pointer to the > entry list of the new node block when the cursor is walked forward at > higher (non-leaf) levels. > > Reported-by: Eryu Guan > Signed-off-by: Brian Foster > --- > repair/attr_repair.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/repair/attr_repair.c b/repair/attr_repair.c > index 83a07a8..b76618a 100644 > --- a/repair/attr_repair.c > +++ b/repair/attr_repair.c > @@ -562,7 +562,7 @@ verify_da_path(xfs_mount_t *mp, > } > > newnode = (xfs_da_intnode_t *)XFS_BUF_PTR(bp); > - btree = M_DIROPS(mp)->node_tree_p(node); > + btree = M_DIROPS(mp)->node_tree_p(newnode); > M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, newnode); > > /* > Reviewed-by: Eric Sandeen Incidentally, the same (correct) logic exists in verify_dir2_path() Looks like it was just a thinko or cut/paste error here, originally. (Incidentally^2, I wonder if we should combine those functions, they are remarkably similar yet slightly divergent) Thanks, -Eric From MD-NO--34306-88-FR-PR--xfs=oss.sgi.com@lists.mdirector.com Wed Sep 2 12:47:30 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,T_DKIM_INVALID, T_KHOP_FOREIGN_CLICK autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id EFB657F5E for ; Wed, 2 Sep 2015 12:47:30 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id C94358F804C for ; Wed, 2 Sep 2015 10:47:30 -0700 (PDT) X-ASG-Debug-ID: 1441216025-04cb6c0e0f415c0001-NocioJ Received: from mta141.183.mdrctr.com (mta141.183.mdrctr.com [62.97.141.183]) by cuda.sgi.com with ESMTP id x5lzWKEqdStL8Tzo for ; Wed, 02 Sep 2015 10:47:06 -0700 (PDT) X-Barracuda-Envelope-From: MD-NO--34306-88-FR-PR--xfs=oss.sgi.com@lists.mdirector.com X-Barracuda-Apparent-Source-IP: 62.97.141.183 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=free; d=pictyear.frmdirector.com; h=From:Reply-To:To:Date:List-Id:List-Unsubscribe:Subject:MIME-Version:Content-Type:Message-ID; i=info@pictyear.frmdirector.com; bh=d6u4LDO/iuophdlrXBFLzNlILGQ=; b=GWYvAzpQcUJDmLDiRmvup+aWamSebtW77z8AfTHpn4p9ah5QYOYG18qq8d27I81pkV7BVThJ+okQ LRMYSLpy0s6nvPfuphXERdX1V7ia2PJqLmja7gkpzbp5lwkrmlhU/M2b8Q+TPM0aYtymLCvdwNce wbUE5eyKrP3beeFQBpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=free; d=pictyear.frmdirector.com; b=QMXBa97w3M46dmdazJx0BgU7drGEfRxxci2joSS8N5+Qg9z7URQ/XmQtRhBUGEPzeljjDyIUtOZf f6v8EGAh7ZqeWGUSmyTR69jaWFahc10sdI7ei2agR4oJ8uyKECSUh4tSjDJ3G2zDgDQ1LssA+t+m 1MFW7Vb38t2A2royBHU=; Received: from pmta4.mta.antevenio.com (127.0.0.1) by mta141.181.mdrctr.com id hssr1g15mio3 for ; Wed, 2 Sep 2015 19:45:53 +0200 (envelope-from ) From: PICTYEAR Reply-To: PICTYEAR To: Precedence: bulk X-rpcampaign: mdMDNO3430688FRPR X-rpcampaignok: mdmdMD-NO--34306-88-FR-PR X-reputation: 5 Date: Wed, 2 Sep 2015 19:45:53 +0200 List-Id: 34306-3.mdirector.com List-Unsubscribe: , X-LU: , Subject: PICTYEAR, =?UTF-8?B?IHTDqWzDqWNoYXJnZXogbGEgbm91dmVsbGUgQXBwIGdyYXR1aXRlIGV0IGltcHI=?= =?UTF-8?B?aW1leiBlbiAxIGNsaWMgdm9zIG1laWxsZXVycyBzb3V2ZW5pcnMgZGUgdmFjYW4=?= =?UTF-8?B?Y2VzLi4u?= MIME-Version: 1.0 X-ASG-Orig-Subj: PICTYEAR, =?UTF-8?B?IHTDqWzDqWNoYXJnZXogbGEgbm91dmVsbGUgQXBwIGdyYXR1aXRlIGV0IGltcHI=?= =?UTF-8?B?aW1leiBlbiAxIGNsaWMgdm9zIG1laWxsZXVycyBzb3V2ZW5pcnMgZGUgdmFjYW4=?= =?UTF-8?B?Y2VzLi4u?= Content-Type: multipart/mixed; boundary="boundaryTagForMixed" Message-ID: <0.0.B.33.1D0E5A737125C50.6E6674@mta141.181.mdrctr.com> X-Barracuda-Connect: mta141.183.mdrctr.com[62.97.141.183] X-Barracuda-Start-Time: 1441216025 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA038b, BSF_SC0_SA085b, DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22161 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.40 BSF_SC0_SA085b Custom Rule SA085b 0.20 BSF_SC0_SA038b Custom Rule SA038b --boundaryTagForMixed Content-Type: multipart/alternative; boundary="boundaryTagForAlternative" --boundaryTagForAlternative Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit ********************************************************************** Vous pourrez exercer vos droits d´accès, annulation, rectification et opposition concernant vos données à caractère personnel, en cliquant * annulation //www.mdirector.com/track/pre-unsubscribe/category/EMAIL/empId/34306/subId/88/listId/3/conId/27804/signature/c902cc80390f2310669664c1b934ad97/conEmail/xfs@oss.sgi.com/conMovil/- --boundaryTagForAlternative Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit PICTYEAR
Si vous n’arrivez pas à visualiser cet email, cliquez ici.
pictyear
La première application mobile gratuite et privée qui regroupe toutes les photos que vous prenez avec toutes celles qui sont prises par vos proches.
shoot - swipe - print
les selfies entre amis - les photos en famille
 
Ne laissez plus dans les smartphones des autres les photos sur lesquelles vous apparaissez
 
les éclats de rire - les photos entre copines
 
Réalisez instantanément vos albums photos personnalisés et recevez gratuitement votre FREEBOOK
 
les nouvelles rencontres - les bons moments entre amis
 
Téléchargez l’app et tentez de gagner* un voyage pour 2 à SAN FRANCISCO
 
OU UN ALBUM PHOTO INSTANTANÉMENT COMPOSÉ DE VOS PLUS BEAUX SOUVENIRS PARTAGÉS
 
Pictyear
 
Disponible sur l'APPSTORE - Disponible sur GOOGLE PLAY
 
 
 
pictyear
Pictyear est la première appli au
monde qui vous permet de créer
instantanément un album photos
imprimé, seul ou à plusieurs.		 SUIVEZ-NOUS
FacebookTwitterInstagramPinterest
 
Le règlement du jeu concours sans obligation d’achat « SUMMER PICTYEAR » est disponible en cliquant ici.
 
© Copyright 2015 Pictyear Tous droits réservés. Mentions légales.
 
Conformément à la loi "Informatique et libertés" du 6 janvier 1978, vous bénéficiez d'un droit d'accès, de modification, de rectification et de suppression des données qui vous concernent. Si vous souhaitez exercer ce droit et obtenir communication des informations vous concernant, veuillez vous adresser à : Venise Activation – 7, 13 Bd Paul Émile Victor 92200 Neuilly sur Seine.

Si vous souhaitez ne plus recevoir de messages, cliquez ici.
 
Vous pourrez exercer vos droits d´accès, annulation, rectification et opposition concernant vos données à caractère personnel, en cliquant annulation.
--boundaryTagForAlternative-- --boundaryTagForMixed-- From rjohnston@sgi.com Wed Sep 2 13:21:30 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 9B1B87F5F for ; Wed, 2 Sep 2015 13:21:30 -0500 (CDT) Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay3.corp.sgi.com (Postfix) with ESMTP id 26C11AC013; Wed, 2 Sep 2015 11:21:27 -0700 (PDT) Received: from gulag1.americas.sgi.com (gulag1.americas.sgi.com [128.162.236.41]) by estes.americas.sgi.com (Postfix) with ESMTP id BF39C700322B; Wed, 2 Sep 2015 13:21:26 -0500 (CDT) Received: by gulag1.americas.sgi.com (Postfix, from userid 48222) id AB280607C89BB; Wed, 2 Sep 2015 13:21:26 -0500 (CDT) Subject: [PATCH V2] xfsrestore: fix 2GB directory dump limitation for multi-stream From: Rich Johnston To: xfs@oss.sgi.com Message-Id: <20150902182126.AB280607C89BB@gulag1.americas.sgi.com> Date: Wed, 2 Sep 2015 13:21:26 -0500 (CDT) In reply to: <20150902132117.GC23587@bfoster.bfoster> References: <20150827185445.6E13960EDE2F0@gulag1.americas.sgi.com> On 09/02/2015 08:21 AM, Brian Foster wrote: > On Thu, Aug 27, 2015 at 01:54:45PM -0500, Rich Johnston wrote: >> >> The drive_simple restore path has a 2GB directory limit. Instead of >> ASSERTing if nreadneeded64 is greater than INTGENMAX (2GB), add a loop >> to handle it. >> >> Signed-off-by: Rich Johnston >> --- > > I'm not a huge fan of all the spaces used in this code (around the > braces and whatnot). It is consistent with the rest of the code but I'd > probably get away from that as code is modified. > > That aside, the change seems fine to me: > > Reviewed-by: Brian Foster ... Thanks for the review Brian and I agree with you about the spaces. I was just matching the current style. I have removed them. ********************* Begin Patch******************************* The drive_simple restore path has a 2GB directory limit. Instead of ASSERTing if nreadneeded64 is greater than INTGENMAX (2GB), add a loop to handle it. Signed-off-by: Rich Johnston Reviewed-by: Brian Foster --- Changelog: V2 remove extra spaces around braces common/drive_simple.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) Index: b/common/drive_simple.c =================================================================== --- a/common/drive_simple.c +++ b/common/drive_simple.c @@ -765,18 +765,20 @@ do_seek_mark( drive_t *drivep, drive_mar /* use read_buf util func to eat up difference */ nreadneeded64 = mark - strmoff; - ASSERT( nreadneeded64 <= INTGENMAX ); - nreadneeded = ( intgen_t )nreadneeded64; - nread = read_buf( 0, - ( size_t )nreadneeded, - ( void * )drivep, - ( rfp_t )drivep->d_opsp->do_read, - ( rrbfp_t )drivep->d_opsp->do_return_read_buf, - &rval ); - if ( rval ) { - return rval; + while (nreadneeded64 > 0) { + if (nreadneeded64 > INTGENMAX) + nreadneeded = INTGENMAX; + else + nreadneeded = (intgen_t)nreadneeded64; + nread = read_buf(0, nreadneeded, drivep, + (rfp_t)drivep->d_opsp->do_read, + (rrbfp_t)drivep->d_opsp->do_return_read_buf, + &rval ); + if (rval) { + return rval; + } + nreadneeded64 -= nread; } - ASSERT( nread == nreadneeded ); /* verify we are on the mark */ From rjohnston@sgi.com Wed Sep 2 13:49:50 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 7DE137F60 for ; Wed, 2 Sep 2015 13:49:50 -0500 (CDT) Received: from xmail.sgi.com (pv-excas3-dc21.corp.sgi.com [137.38.106.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 504AB304048; Wed, 2 Sep 2015 11:49:47 -0700 (PDT) Received: from [128.162.233.55] (128.162.233.55) by xmail.sgi.com (137.38.106.6) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 2 Sep 2015 13:49:46 -0500 Subject: Re: [RESEND PATCH] xfsrestore: fix fs uuid order check for incremental restores To: Brian Foster References: <20150826213133.GB3902@dastard> <55D5FB95.1280108@sgi.com> <20150902132112.GB23587@bfoster.bfoster> CC: From: Rich Johnston Message-ID: <55E744CB.1080409@sgi.com> Date: Wed, 2 Sep 2015 13:49:47 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150902132112.GB23587@bfoster.bfoster> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [128.162.233.55] On 09/02/2015 08:21 AM, Brian Foster wrote: > On Tue, Sep 01, 2015 at 03:38:29PM -0500, Rich Johnston wrote: >> Restoring an incremental level 1 dump will fail with the following error >> if the fs uuid of the most recent level 0 dump in the inventory does not >> match level 1 dump we are restoring. >> >> xfsrestore: ERROR: selected dump not based on previously applied dump >> >> This can happen when you have multiple filesystems and you are restoring >> a level 1 or greater dump of filesystem FS1 but the most recent level 0 >> dump in the inventory was filesystem FS2 >> >> The fix is to ensure the fs uuid of the inventory entry and the dump to >> be restored match. >> >> Signed-off-by: Rich Johnston >> --- > > I'm not really familiar with xfsdump, but a few comments below... > >> dump/content.c | 8 ++- >> inventory/inv_api.c | 108 ++++++++++++++++++++++++++++++-------------------- >> inventory/inv_mgr.c | 32 ++++++++++---- >> inventory/inv_priv.h | 7 +-- >> inventory/inventory.h | 5 ++ >> restore/content.c | 17 +++++-- >> 6 files changed, 113 insertions(+), 64 deletions(-) >> > ... >> Index: b/inventory/inv_mgr.c >> =================================================================== >> --- a/inventory/inv_mgr.c >> +++ b/inventory/inv_mgr.c >> @@ -134,6 +134,7 @@ get_sesstoken( inv_idbtoken_t tok ) >> /*---------------------------------------------------------------------------*/ >> bool_t >> invmgr_query_all_sessions ( >> + uuid_t *fsidp, >> void *inarg, >> void **outarg, >> search_callback_t func) >> @@ -169,7 +170,7 @@ invmgr_query_all_sessions ( >> mlog( MLOG_NORMAL | MLOG_INV, _( >> "INV: Cant get inv-name for uuid\n") >> ); >> - return BOOL_FALSE; >> + continue; >> } >> strcat( fname, INV_INVINDEX_PREFIX ); >> invfd = open( fname, INV_OFLAG(forwhat) ); >> @@ -178,9 +179,9 @@ invmgr_query_all_sessions ( >> "INV: Open failed on %s\n"), >> fname >> ); >> - return BOOL_FALSE; >> + continue; >> } > > Now that the above two cases don't return false, we can end up returning > true if these error cases persist throughout the loop. Yes I missed that case. > Perhaps we should > define 'bool ret = false,' return that variable everywhere and only set > it true when appropriate. Good suggestion. > >> - result = search_invt( invfd, inarg, &objectfound, func ); >> + result = search_invt(fsidp, invfd, inarg, &objectfound, func); >> close(invfd); >> >> /* if error return BOOL_FALSE */ > ... >> @@ -272,19 +274,31 @@ search_invt( >> } >> free ( scnt ); >> >> - while ( nsess ) { >> + for (j = nsess - 1; j >= 0; j--) { >> + invt_session_t ses; >> + >> /* fd is kept locked until we return from the >> callback routine */ >> >> /* Check to see if this session has been pruned >> * by xfsinvutil before checking it. >> */ >> - if ( harr[nsess - 1].sh_pruned ) { >> - --nsess; >> + if (harr[j].sh_pruned) { >> continue; >> } >> - found = (* do_chkcriteria ) ( fd, &harr[ --nsess ], >> - arg, buf ); >> + >> + /* if we need to check the fs uuid's and they don't >> + * match or we fail to get the session record, >> + * then keep looking >> + */ >> + if (fsidp && >> + (GET_REC_NOLOCK(fd, &ses, sizeof(invt_session_t), >> + harr[j].sh_sess_off) == >> + sizeof(invt_session_t)) && >> + uuid_compare(ses.s_fsid, *fsidp)) >> + continue ; >> + > > This seems like kind of a loaded check. GET_REC_NOLOCK() looks like it > returns -1 if the read doesn't return the exact size of the buffer, so > we probably don't need to check that here. It also seems like we should > return an error if an error occurs rather than just continue on. How > about something like this? Sounds reasonable, would be more readable. > > ... > if (fsidp) { > ret = GET_REC_NOLOCK(fd, &ses, > sizeof(invt_session_t), > harr[j].sh_sess_off); > if (ret < 0) { > /* XXX: clean up here */ > return ret; > } > ret = uuid_compare(ses.s_fsid, *fsidp); > if (ret) > continue; > } > >> + found = (* do_chkcriteria ) (fd, &harr[j], arg, buf); >> if (! found ) continue; >> >> /* we found what we need; just return */ > ... >> Index: b/restore/content.c >> =================================================================== >> --- a/restore/content.c >> +++ b/restore/content.c >> @@ -2179,8 +2179,9 @@ content_stream_restore( ix_t thrdix ) >> if ( ! drivep->d_isnamedpipepr >> && >> ! drivep->d_isunnamedpipepr ) { >> - ok = inv_get_session_byuuid( &grhdrp->gh_dumpid, >> - &sessp ); >> + ok = inv_get_session_byuuid((uuid_t *)0, >> + &grhdrp->gh_dumpid, >> + &sessp); >> if ( ok && sessp ) { >> mlog( MLOG_VERBOSE, _( >> "using online session inventory\n") ); >> @@ -3736,9 +3737,11 @@ Inv_validate_cmdline( void ) >> ok = BOOL_FALSE; >> sessp = 0; >> if ( tranp->t_reqdumpidvalpr ) { >> - ok = inv_get_session_byuuid( &tranp->t_reqdumpid, &sessp ); >> + ok = inv_get_session_byuuid((uuid_t *)0, &tranp->t_reqdumpid, >> + &sessp ); >> } else if ( tranp->t_reqdumplabvalpr ) { >> - ok = inv_get_session_bylabel( tranp->t_reqdumplab, &sessp ); >> + ok = inv_get_session_bylabel((uuid_t *)0, tranp->t_reqdumplab, >> + &sessp ); > > Can we use NULL instead of 0 in these cases? Not sure the cast is really > necessary either..?. I will check that out, if NULL works I will make that change. Thanks for your time --Rich > > Brian > >> } >> rok = BOOL_FALSE; >> if ( ok && sessp ) { >> @@ -6812,11 +6815,13 @@ askinvforbaseof( uuid_t baseid, inv_sess >> /* get the base session >> */ >> if ( resumedpr ) { >> - ok = inv_lastsession_level_equalto( invtok, >> + ok = inv_lastsession_level_equalto( &sessp->s_fsid, >> + invtok, >> ( u_char_t )level, >> &basesessp ); >> } else { >> - ok = inv_lastsession_level_lessthan( invtok, >> + ok = inv_lastsession_level_lessthan( &sessp->s_fsid, >> + invtok, >> ( u_char_t )level, >> &basesessp ); >> } >> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs From david@fromorbit.com Wed Sep 2 16:35:30 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 198287F66 for ; Wed, 2 Sep 2015 16:35:30 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id EFB14304032 for ; Wed, 2 Sep 2015 14:35:26 -0700 (PDT) X-ASG-Debug-ID: 1441229720-04bdf06dd84bd40001-NocioJ Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id V8yOPmxuiNqAhdDX for ; Wed, 02 Sep 2015 14:35:21 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ANBwBZa+dV/wUaLHldgxuBPalKAQEBBopdkRMCAgEBAoE6TQEBAQEBAYELhCMBAQEEJxMcIxAIAw4HAwklDwUlAyETiC3LBwELIBmGE4VChQsHhCwBBJIXgzKMc4oShGKLfiaEEiwzgk0BAQE Received: from ppp121-44-26-5.lns20.syd4.internode.on.net (HELO dastard) ([121.44.26.5]) by ipmail07.adl2.internode.on.net with ESMTP; 03 Sep 2015 07:04:52 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZXFfx-0005ME-J8; Thu, 03 Sep 2015 07:34:37 +1000 Date: Thu, 3 Sep 2015 07:34:37 +1000 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com, boaz@plexistor.com, kirill.shutemov@linux.intel.com Subject: Re: [PATCH] xfs: add ->pfn_mkwrite support for DAX Message-ID: <20150902213437.GT3902@dastard> X-ASG-Orig-Subj: Re: [PATCH] xfs: add ->pfn_mkwrite support for DAX References: <1441157100-1658-1-git-send-email-david@fromorbit.com> <20150902051217.GA18906@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150902051217.GA18906@infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1441229721 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22170 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 01, 2015 at 10:12:17PM -0700, Christoph Hellwig wrote: > On Wed, Sep 02, 2015 at 11:25:00AM +1000, Dave Chinner wrote: > > From: Dave Chinner > > > > ->pfn_mkwrite support is needed so that when a page with allocated > > backing store first takes a write fault the timestamps on the > > file are updated. THis fixes a generic/080 failure. > > Shouldn't you be able to drop the call to xfs_filemap_page_mkwrite from > xfs_filemap_fault now? No idea. It hasn't been removed from dax_fault, so I'm not going to remove it from xfs_filemap_page_mkwrite()... Cheers, Dave. -- Dave Chinner david@fromorbit.com From hitrich@gmail.com Wed Sep 2 21:25:04 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE, T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E7ED87F5F for ; Wed, 2 Sep 2015 21:25:03 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 607AAAC015 for ; Wed, 2 Sep 2015 19:25:03 -0700 (PDT) X-ASG-Debug-ID: 1441247098-04cbb06acb53c50001-NocioJ Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) by cuda.sgi.com with ESMTP id bJ3CAIbYDTTlABMZ (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 02 Sep 2015 19:24:58 -0700 (PDT) X-Barracuda-Envelope-From: hitrich@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.213.42 X-Barracuda-IPDD: Level1 [gmail.com/209.85.213.42] Received: by vkaw128 with SMTP id w128so16801967vka.2 for ; Wed, 02 Sep 2015 19:24:57 -0700 (PDT) X-Barracuda-IPDD: Level1 [gmail.com/209.85.213.42] X-Barracuda-IPDD: Level1 [gmail.com/209.85.213.42] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7GdxubFukJvhtX7QI14yb2IBNzlCMtxiIMayOy6BQSw=; b=wBMJoSlsDdkqTAEFIbMcCYBC1frPvu8371ZNulMR6BNrCZe4eJk+8XTrcvEcqqtrZg hccFeDVF5EUTNgnysB0Z7xj2rUStum6oXDNmSl3DeYzf04P0dkh2U7o5Xl5whxTv1ZRM Oay0FnAMrNknh4OO3Lbo1JNhZPJSHhI1Qx0EDyZ2s24WrXKFI6nV1g8y70H36S40lv23 x27C1jb01zimWdFNUsT/zcTsu28YHc8AuWjISu8nH+aiUAwj/8LRRwxM7mNQmbvfeqLj 5UATUng/wkF2owDlCa10i6fsduwF8My0uWj51mtlYAqfWUchDEyO0bx9qDTyoPiQX3sI Ybww== MIME-Version: 1.0 X-Received: by 10.52.115.168 with SMTP id jp8mr6224221vdb.14.1441247097379; Wed, 02 Sep 2015 19:24:57 -0700 (PDT) Received: by 10.103.32.132 with HTTP; Wed, 2 Sep 2015 19:24:57 -0700 (PDT) Date: Thu, 3 Sep 2015 14:24:57 +1200 Message-ID: Subject: XFS and nobarriers on Intel SSD From: Richard Bade X-ASG-Orig-Subj: XFS and nobarriers on Intel SSD To: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=bcaec548a7ef45e997051ece7d0b X-Barracuda-Connect: mail-vk0-f42.google.com[209.85.213.42] X-Barracuda-Start-Time: 1441247098 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22179 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 --bcaec548a7ef45e997051ece7d0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Everyone, I have a question about nobarriers. In the XFS FAQ it looks like the recommendation is that if you have a Battery Backed raid controller you should set nobarriers for performance reasons. Our LSI card doesn=E2=80=99t have battery backed cache as it=E2=80=99s conf= igured in HBA mode (IT) rather than Raid (IR). Our Intel s3710 SSD=E2=80=99s do have a ca= pacitor backed cache though. So is it recommended that barriers are turned off as the drive has a safe cache (I am confident that the cache will write out to disk on power failure)? The reason I am asking about this is that we are seeing some significant I/O delays on the disks causing a =E2=80=9CSCSI Task Abort=E2=80=9D from th= e OS. This seems to be triggered by the drive receiving a =E2=80=9CSynchronize cache command= =E2=80=9D. My current thinking is that setting no barriers will stop the drive receiving a sync command and therefore stop the I/O delay associated with it. This is happening on our Ceph storage cluster. For those not familiar with Ceph, it uses XFS as the underlying filesystem for the object stores. Has anyone else encountered this issue? Any info or suggestions about this would be appreciated. Regards, Richard --bcaec548a7ef45e997051ece7d0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Everyone,
I have a question about nobarr= iers. In the XFS FAQ it looks like the recommendation is that if you have a= Battery Backed raid controller you should set nobarriers for performance r= easons.
Our LSI card doesn=E2=80=99t have battery backed cache as= it=E2=80=99s configured in HBA mode (IT) rather than Raid (IR). Our Intel = s3710 SSD=E2=80=99s do have a capacitor backed cache though.
So i= s it recommended that barriers are turned off as the drive has a safe cache= (I am confident that the cache will write out to disk on power failure)?

The reason I am asking about this is that we are se= eing some significant I/O delays on the disks causing a =E2=80=9CSCSI Task = Abort=E2=80=9D from the OS. This seems to be triggered by the drive receivi= ng a =E2=80=9CSynchronize cache command=E2=80=9D.
My current thin= king is that setting no barriers will stop the drive receiving a sync comma= nd and therefore stop the I/O delay associated with it.

This is happening on our Ceph storage cluster. For those not familiar= with Ceph, it uses XFS as the underlying filesystem for the object stores.=

Has anyone else encountered this issue?
Any info or suggestions about this would be appreciated.=C2=A0
<= br>
Regards,
Richard

--bcaec548a7ef45e997051ece7d0b-- From jtulak@redhat.com Thu Sep 3 04:02:12 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E71227F60 for ; Thu, 3 Sep 2015 04:02:11 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 573D5AC002 for ; Thu, 3 Sep 2015 02:02:05 -0700 (PDT) X-ASG-Debug-ID: 1441270924-04cb6c0e0d53450001-NocioJ Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) by cuda.sgi.com with ESMTP id 8p7LfSaEfdCiuQX7 (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 03 Sep 2015 02:02:04 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com Received: by ioiz6 with SMTP id z6so50304335ioi.2 for ; Thu, 03 Sep 2015 02:02:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hEBVODThht6DTNPXMxqIYNAyqRGcHblrgpHs3GYubWU=; b=QNQgmROtQiKNmG3PrctjPVrWgmrMnF8SjT/GNwuUkiA6jKpH+RklJqZ1CfwlwUui9C D3/I/XgdCeQWdmGObw3VNsiTZexZdpTQgBDluspLMYOljK1tNrC03Qq7cTqipOy+MMFh Kfs+mrLNwxY8G65tacLSDUCwe1JReqSyz+mgmpziG142jSvIPj79PMdrseczFz/SNx1n eFLrT9LEoXxua2QWTDv3A9Uffp3pdWhX8d1BeReAp3mgDlrxl3tvsGGRFBPSrF9h5PUC jSkAqvXLzwoNS3KV3CFq1AoIGZl0MHGqp7GAIXn4zaJ3Tfj+8MtgqyVfgqT+kvSv8zLz f/5Q== X-Gm-Message-State: ALoCoQnht7XHhdjyXFx4qwhbCtLCcoinS9iUl05kr75wsp94leAkONObW4K9wJgTjsm/0iQcQeqY X-Received: by 10.107.14.203 with SMTP id 194mr31090147ioo.46.1441270924175; Thu, 03 Sep 2015 02:02:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Thu, 3 Sep 2015 02:01:44 -0700 (PDT) In-Reply-To: <20150831190120.GK349@infradead.org> References: <1440590449-20372-1-git-send-email-jtulak@redhat.com> <1440590555-20463-1-git-send-email-jtulak@redhat.com> <1440590555-20463-10-git-send-email-jtulak@redhat.com> <20150831190120.GK349@infradead.org> From: Jan Tulak Date: Thu, 3 Sep 2015 11:01:44 +0200 Message-ID: Subject: Re: [PATCH 10/11] xfsprogs: add dummy mntent for OS X To: Christoph Hellwig X-ASG-Orig-Subj: Re: [PATCH 10/11] xfsprogs: add dummy mntent for OS X Cc: xfs-oss Content-Type: multipart/alternative; boundary=001a11409e3e763f1f051ed4091a X-Barracuda-Connect: mail-io0-f180.google.com[209.85.223.180] X-Barracuda-Start-Time: 1441270924 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22185 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --001a11409e3e763f1f051ed4091a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 31, 2015 at 9:01 PM, Christoph Hellwig wrote: > On Wed, Aug 26, 2015 at 02:02:34PM +0200, Jan Tulak wrote: > > Because these calls are used only by xfs_fsr, which can't > > work on OS X unless a way how to mount XFS is found, > > there is not use in implementing these calls. > > Take a look at the quota code for the BSD alternative to mntent. > That code should be moved into a common location and used by fsr. > =E2=80=8BI tried to find it, but didn't found... Could you point me where i= t is? Quota/freebsd.h has just few lines with one definition with errno =3D -ENOSYS, and in other files in quota/, I didn't saw anything BSD specific. Thanks, Jan --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --001a11409e3e763f1f051ed4091a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 31, 2015 at 9:01 PM, Christoph Hellwig <hch@inf= radead.org> wrote:
On Wed, Aug 26, 2015 at 02:02:34PM +0200, Jan Tulak wrote:
> Because these calls are used only by xfs_fsr, which can't
> work on OS X unless a way how to mount XFS is found,
> there is not use in implementing these calls.

Take a look at the quota code for the BSD alternative to mntent.
That code should be moved into a common location and used by fsr.

=E2=80=8BI tried to find it, but didn't found= ... Could you point me where it is?=C2=A0
Quota/freebsd.h has just = few lines with one definition with errno =3D -ENOSYS, and in other files in= quota/, I didn't saw anything BSD specific.

Thank= s,
Jan


--
--001a11409e3e763f1f051ed4091a-- From colin.king@canonical.com Thu Sep 3 04:58:21 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 9AA9D7F66 for ; Thu, 3 Sep 2015 04:58:21 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 8BD4F304048 for ; Thu, 3 Sep 2015 02:58:18 -0700 (PDT) X-ASG-Debug-ID: 1441274296-04cb6c0e0d54b00001-NocioJ Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by cuda.sgi.com with ESMTP id 7h6onvzuq7J5cgd1 for ; Thu, 03 Sep 2015 02:58:16 -0700 (PDT) X-Barracuda-Envelope-From: colin.king@canonical.com X-Barracuda-Apparent-Source-IP: 91.189.89.112 Received: from 1.general.cking.uk.vpn ([10.172.193.212] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZXRHa-0001Gh-GZ; Thu, 03 Sep 2015 09:58:14 +0000 From: Colin King To: Dave Chinner , xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [PATCH] xfs: fix null pointer dereference when mapping is NULL Date: Thu, 3 Sep 2015 10:57:40 +0100 X-ASG-Orig-Subj: [PATCH] xfs: fix null pointer dereference when mapping is NULL Message-Id: <1441274260-10120-1-git-send-email-colin.king@canonical.com> X-Mailer: git-send-email 2.5.0 X-Barracuda-Connect: youngberry.canonical.com[91.189.89.112] X-Barracuda-Start-Time: 1441274296 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22186 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- From: Colin Ian King xfs_vm_set_page_dirty checks to see if mapping is NULL however before this unlikely check it already dereferenced mapping when initializing inode. Move the inode initialization after the mapping null check to avoid a potential null pointer dereference. Fixes: 22e757a49cf0 ("xfs: don't dirty buffers beyond EOF") Signed-off-by: Colin Ian King --- fs/xfs/xfs_aops.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c index c77499b..d15ae85 100644 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -1935,7 +1935,7 @@ xfs_vm_set_page_dirty( struct page *page) { struct address_space *mapping = page->mapping; - struct inode *inode = mapping->host; + struct inode *inode; loff_t end_offset; loff_t offset; int newly_dirty; @@ -1944,6 +1944,7 @@ xfs_vm_set_page_dirty( if (unlikely(!mapping)) return !TestSetPageDirty(page); + inode = mapping->host; end_offset = i_size_read(inode); offset = page_offset(page); -- 2.5.0 From jtulak@redhat.com Thu Sep 3 05:33:21 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id D87377F6B for ; Thu, 3 Sep 2015 05:33:21 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id C98418F8052 for ; Thu, 3 Sep 2015 03:33:18 -0700 (PDT) X-ASG-Debug-ID: 1441276397-04cbb06acb5e5b0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id XPlMDCjetNbNpGz4 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 03:33:18 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 93026A3039; Thu, 3 Sep 2015 10:33:17 +0000 (UTC) Received: from Jans-MacBook-Pro.local.com ([10.34.250.208]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83AXFhc019808; Thu, 3 Sep 2015 06:33:16 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: hch@infradead.org, Jan Tulak Subject: [PATCH 02a/11] xfsprogs: Add XATTR_LIST_MAX to OS X headers Date: Thu, 3 Sep 2015 12:33:09 +0200 X-ASG-Orig-Subj: [PATCH 02a/11] xfsprogs: Add XATTR_LIST_MAX to OS X headers Message-Id: <1441276391-23587-1-git-send-email-jtulak@redhat.com> In-Reply-To: <1440655340-27550-1-git-send-email-jtulak@redhat.com> References: <1440655340-27550-1-git-send-email-jtulak@redhat.com> 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: 1441276398 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 OS X has no XATTR_LIST_MAX value. So add it to the platform header. Signed-off-by: Jan Tulak --- include/darwin.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/darwin.h b/include/darwin.h index b904898..4b7ba3a 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -39,6 +39,11 @@ # ifndef SYS_fsctl # define SYS_fsctl 242 # endif + +#ifndef XATTR_LIST_MAX +#define XATTR_LIST_MAX 65536 +#endif + static __inline__ int xfsctl(const char *path, int fd, int cmd, void *p) { return syscall(SYS_fsctl, path, cmd, p, 0); -- 2.4.5 From david@fromorbit.com Thu Sep 3 05:33:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2918C7F6F for ; Thu, 3 Sep 2015 05:33:22 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 19861304043 for ; Thu, 3 Sep 2015 03:33:21 -0700 (PDT) X-ASG-Debug-ID: 1441276399-04cbb06aca5e5b0001-NocioJ Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id 6zN4OGUZBOFu4TZ9 for ; Thu, 03 Sep 2015 03:33:20 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.129 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AiCwBLIehVPAUaLHldgxuBPYMkgy6ifAEBAQEBAQabbwICAQECgTJNAQEBAQEBBwEBAQFBP4QkAQEEIw8BIyMQCAMOCgICBSECAg8FJQMHGhOILbVqlFgBCwEfGYEJhQqFQoQ9GzMHgmmBQwWVTox0mnKEOCwziAWBRwEBAQ Received: from ppp121-44-26-5.lns20.syd4.internode.on.net (HELO dastard) ([121.44.26.5]) by ipmail06.adl2.internode.on.net with ESMTP; 03 Sep 2015 20:03:18 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZXRpV-0006Xb-ND; Thu, 03 Sep 2015 20:33:17 +1000 Date: Thu, 3 Sep 2015 20:33:17 +1000 From: Dave Chinner To: Jan Tulak Cc: Christoph Hellwig , xfs-oss Subject: Re: [PATCH 10/11] xfsprogs: add dummy mntent for OS X Message-ID: <20150903103317.GV3902@dastard> X-ASG-Orig-Subj: Re: [PATCH 10/11] xfsprogs: add dummy mntent for OS X References: <1440590449-20372-1-git-send-email-jtulak@redhat.com> <1440590555-20463-1-git-send-email-jtulak@redhat.com> <1440590555-20463-10-git-send-email-jtulak@redhat.com> <20150831190120.GK349@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1441276399 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22187 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Thu, Sep 03, 2015 at 11:01:44AM +0200, Jan Tulak wrote: > On Mon, Aug 31, 2015 at 9:01 PM, Christoph Hellwig > wrote: > > > On Wed, Aug 26, 2015 at 02:02:34PM +0200, Jan Tulak wrote: > > > Because these calls are used only by xfs_fsr, which can't > > > work on OS X unless a way how to mount XFS is found, > > > there is not use in implementing these calls. > > > > Take a look at the quota code for the BSD alternative to mntent. > > That code should be moved into a common location and used by fsr. > > > > ​I tried to find it, but didn't found... Could you point me where it is? > Quota/freebsd.h has just few lines with one definition with errno = > -ENOSYS, and in other files in quota/, I didn't saw anything BSD specific. I think Christoph is refering to the code in libxcmd/paths.c: #if defined(HAVE_GETMNTENT) .... #elif defined(HAVE_GETMNTINFO) .... #else # error "How do I extract info about mounted filesystems on this platform?" #endif # HAVE_GETMNTINFO is for BSD systems, IIRC. Cheers, Dave. -- Dave Chinner david@fromorbit.com From jtulak@redhat.com Thu Sep 3 05:33:24 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 6F51A7F7B for ; Thu, 3 Sep 2015 05:33:24 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 51E6D304043 for ; Thu, 3 Sep 2015 03:33:21 -0700 (PDT) X-ASG-Debug-ID: 1441276400-04bdf06dd85bde0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id iKIcu7vat1gOkFLZ (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 03:33:20 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 4A4BA2B786B; Thu, 3 Sep 2015 10:33:20 +0000 (UTC) Received: from Jans-MacBook-Pro.local.com ([10.34.250.208]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83AXFhd019808; Thu, 3 Sep 2015 06:33:19 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: hch@infradead.org, Jan Tulak Subject: [PATCH 02b/11] xfsprogs: avoid dependency on Linux XATTR_SIZE_MAX Date: Thu, 3 Sep 2015 12:33:10 +0200 X-ASG-Orig-Subj: [PATCH 02b/11] xfsprogs: avoid dependency on Linux XATTR_SIZE_MAX Message-Id: <1441276391-23587-2-git-send-email-jtulak@redhat.com> In-Reply-To: <1441276391-23587-1-git-send-email-jtulak@redhat.com> References: <1440655340-27550-1-git-send-email-jtulak@redhat.com> <1441276391-23587-1-git-send-email-jtulak@redhat.com> 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: 1441276400 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Currently, we depends on Linux XATTR value for on disk definitions. Which causes trouble on other platforms and maybe also if this value was to change. Fix it by creating a custom definition independent from those in Linux (although with the same values), so it is OK with the be16 fields used for holding these attributes. Signed-off-by: Jan Tulak --- libxfs/xfs_attr_remote.c | 2 +- libxfs/xfs_format.h | 10 +++++++++- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/libxfs/xfs_attr_remote.c b/libxfs/xfs_attr_remote.c index 5feaf55..98893e2 100644 --- a/libxfs/xfs_attr_remote.c +++ b/libxfs/xfs_attr_remote.c @@ -102,7 +102,7 @@ xfs_attr3_rmt_verify( if (be32_to_cpu(rmt->rm_bytes) > fsbsize - sizeof(*rmt)) return false; if (be32_to_cpu(rmt->rm_offset) + - be32_to_cpu(rmt->rm_bytes) > XATTR_SIZE_MAX) + be32_to_cpu(rmt->rm_bytes) > XFS_XATTR_SIZE_MAX) return false; if (rmt->rm_owner == 0) return false; diff --git a/libxfs/xfs_format.h b/libxfs/xfs_format.h index bb7cc04..046b20f 100644 --- a/libxfs/xfs_format.h +++ b/libxfs/xfs_format.h @@ -60,6 +60,14 @@ struct xfs_ifork; #define XFS_SB_VERSION_MOREBITSBIT 0x8000 /* + * The size of a single extended attribute on disk is limited by + * the size of index values within the attribute entries themselves. + * These are be16 fields, so we can only support attribute data + * sizes up to 2^16 bytes in length. + */ +#define XFS_XATTR_SIZE_MAX (1 << 16) + +/* * Supported feature bit list is just all bits in the versionnum field because * we've used them all up and understand them all. Except, of course, for the * shared superblock bit, which nobody knows what it does and so is unsupported. @@ -1483,7 +1491,7 @@ struct xfs_acl { */ #define XFS_ACL_MAX_ENTRIES(mp) \ (xfs_sb_version_hascrc(&mp->m_sb) \ - ? (XATTR_SIZE_MAX - sizeof(struct xfs_acl)) / \ + ? (XFS_XATTR_SIZE_MAX - sizeof(struct xfs_acl)) / \ sizeof(struct xfs_acl_entry) \ : 25) -- 2.4.5 From jtulak@redhat.com Thu Sep 3 05:33:27 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 0F9807F80 for ; Thu, 3 Sep 2015 05:33:27 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 9FACFAC001 for ; Thu, 3 Sep 2015 03:33:23 -0700 (PDT) X-ASG-Debug-ID: 1441276402-04cbb06acc5e5c0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id G42EhZXyodoHVKQG (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 03:33:22 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 3B783C0A5147; Thu, 3 Sep 2015 10:33:22 +0000 (UTC) Received: from Jans-MacBook-Pro.local.com ([10.34.250.208]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83AXFhe019808; Thu, 3 Sep 2015 06:33:21 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: hch@infradead.org, Jan Tulak Subject: [PATCH 02c/11] xfsprogs: prefix XATTR_LIST_MAX with XFS_ Date: Thu, 3 Sep 2015 12:33:11 +0200 X-ASG-Orig-Subj: [PATCH 02c/11] xfsprogs: prefix XATTR_LIST_MAX with XFS_ Message-Id: <1441276391-23587-3-git-send-email-jtulak@redhat.com> In-Reply-To: <1441276391-23587-1-git-send-email-jtulak@redhat.com> References: <1440655340-27550-1-git-send-email-jtulak@redhat.com> <1441276391-23587-1-git-send-email-jtulak@redhat.com> 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: 1441276402 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 WILL CHANGE THE COMMIT MESSAGE. All right, I make the renaming with define - though I'm not sure that with the ifdef for OS X and SIZE_MAX moved to a standalone patch we need it - shouldn't be this change rather dropped? Signed-off-by: Jan Tulak --- include/xfs.h | 2 ++ libhandle/handle.c | 4 ++-- libhandle/jdm.c | 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/include/xfs.h b/include/xfs.h index bc94068..8ee0106 100644 --- a/include/xfs.h +++ b/include/xfs.h @@ -53,6 +53,8 @@ # define ASSERT(EX) ((void) 0) #endif +#define XFS_XATTR_LIST_MAX XATTR_LIST_MAX + /* * sparse kernel source annotations */ diff --git a/libhandle/handle.c b/libhandle/handle.c index b1c0c10..7207186 100644 --- a/libhandle/handle.c +++ b/libhandle/handle.c @@ -397,8 +397,8 @@ attr_list_by_handle( alhreq.buffer = buf; alhreq.buflen = bufsize; /* prevent needless EINVAL from the kernel */ - if (alhreq.buflen > XATTR_LIST_MAX) - alhreq.buflen = XATTR_LIST_MAX; + if (alhreq.buflen > XFS_XATTR_LIST_MAX) + alhreq.buflen = XFS_XATTR_LIST_MAX; error = xfsctl(path, fd, XFS_IOC_ATTRLIST_BY_HANDLE, &alhreq); diff --git a/libhandle/jdm.c b/libhandle/jdm.c index d804423..e52f5d8 100644 --- a/libhandle/jdm.c +++ b/libhandle/jdm.c @@ -168,8 +168,8 @@ jdm_attr_list( jdm_fshandle_t *fshp, int rval; /* prevent needless EINVAL from the kernel */ - if (bufsz > XATTR_LIST_MAX) - bufsz = XATTR_LIST_MAX; + if (bufsz > XFS_XATTR_LIST_MAX) + bufsz = XFS_XATTR_LIST_MAX; jdm_fill_filehandle( &filehandle, fshandlep, statp ); rval = attr_list_by_handle (( void * )&filehandle, -- 2.4.5 From jtulak@redhat.com Thu Sep 3 05:35:15 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 238027F6F for ; Thu, 3 Sep 2015 05:35:15 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 02542304051 for ; Thu, 3 Sep 2015 03:35:14 -0700 (PDT) X-ASG-Debug-ID: 1441276513-04cbb06acb5e6e0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id PUkg9WqWNzmmq2BL (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 03:35:14 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id ADB0240; Thu, 3 Sep 2015 10:35:13 +0000 (UTC) Received: from Jans-MacBook-Pro.local.com ([10.34.250.208]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83AZC8N017626; Thu, 3 Sep 2015 06:35:12 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: hch@infradead.org, Jan Tulak Subject: [PATCH v2] xfsprogs: Make mremap conditional Date: Thu, 3 Sep 2015 12:35:10 +0200 X-ASG-Orig-Subj: [PATCH v2] xfsprogs: Make mremap conditional Message-Id: <1441276510-23637-1-git-send-email-jtulak@redhat.com> In-Reply-To: <1440590555-20463-11-git-send-email-jtulak@redhat.com> References: <1440590555-20463-11-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441276514 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Don't build mremap (in xfs_io) on platforms where it has no support. CHANGELOG: - subject was xfsprogs: add dummy mremap for OS X Signed-off-by: Jan Tulak --- configure.ac | 1 + include/builddefs.in | 1 + include/darwin.h | 1 + io/mmap.c | 8 ++++++++ m4/package_libcdev.m4 | 13 +++++++++++++ 5 files changed, 24 insertions(+) diff --git a/configure.ac b/configure.ac index 13aa308..01dd1a3 100644 --- a/configure.ac +++ b/configure.ac @@ -124,6 +124,7 @@ AC_HAVE_MNTENT AC_HAVE_FLS AC_HAVE_READDIR AC_HAVE_FSETXATTR +AC_HAVE_MREMAP if test "$enable_blkid" = yes; then AC_HAVE_BLKID_TOPO diff --git a/include/builddefs.in b/include/builddefs.in index 31e21ba..c1797fd 100644 --- a/include/builddefs.in +++ b/include/builddefs.in @@ -107,6 +107,7 @@ HAVE_READDIR = @have_readdir@ HAVE_MNTENT = @have_mntent@ HAVE_FLS = @have_fls@ HAVE_FSETXATTR = @have_fsetxattr@ +HAVE_MREMAP = @have_mremap@ GCCFLAGS = -funsigned-char -fno-strict-aliasing -Wall # -Wbitwise -Wno-transparent-union -Wno-old-initializer -Wno-decl diff --git a/include/darwin.h b/include/darwin.h index af76f31..9f7a00b 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -33,6 +33,7 @@ #include #include #include +#include #include #define __BYTE_ORDER BYTE_ORDER diff --git a/io/mmap.c b/io/mmap.c index f26276e..7093650 100644 --- a/io/mmap.c +++ b/io/mmap.c @@ -28,7 +28,9 @@ static cmdinfo_t mread_cmd; static cmdinfo_t msync_cmd; static cmdinfo_t munmap_cmd; static cmdinfo_t mwrite_cmd; +#ifdef HAVE_MREMAP static cmdinfo_t mremap_cmd; +#endif /* HAVE_MREMAP */ mmap_region_t *maptable; int mapcount; @@ -574,6 +576,7 @@ mwrite_f( return 0; } +#ifdef HAVE_MREMAP static void mremap_help(void) { @@ -633,6 +636,7 @@ mremap_f( return 0; } +#endif /* HAVE_MREMAP */ void mmap_init(void) @@ -688,6 +692,7 @@ mmap_init(void) _("writes data into a region in the current memory mapping"); mwrite_cmd.help = mwrite_help; +#ifdef HAVE_MREMAP mremap_cmd.name = "mremap"; mremap_cmd.altname = "mrm"; mremap_cmd.cfunc = mremap_f; @@ -698,11 +703,14 @@ mmap_init(void) mremap_cmd.oneline = _("alters the size of the current memory mapping"); mremap_cmd.help = mremap_help; +#endif /* HAVE_MREMAP */ add_command(&mmap_cmd); add_command(&mread_cmd); add_command(&msync_cmd); add_command(&munmap_cmd); add_command(&mwrite_cmd); +#ifdef HAVE_MREMAP add_command(&mremap_cmd); +#endif /* HAVE_MREMAP */ } diff --git a/m4/package_libcdev.m4 b/m4/package_libcdev.m4 index 5e900ab..b6a7a54 100644 --- a/m4/package_libcdev.m4 +++ b/m4/package_libcdev.m4 @@ -235,3 +235,16 @@ AC_DEFUN([AC_HAVE_MNTENT], have_mntent=yes) AC_SUBST(have_mntent) ]) + +# +# Check if we have a mremap call (not on Mac OS X) +# +AC_DEFUN([AC_HAVE_MREMAP], + [ AC_CHECK_DECL([mremap], + have_mremap=yes, + [], + [#define _GNU_SOURCE + #include ] + ) + AC_SUBST(have_mremap) + ]) -- 2.4.5 From jtulak@redhat.com Thu Sep 3 05:37:44 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id CA5F17F58 for ; Thu, 3 Sep 2015 05:37:44 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id AB078304043 for ; Thu, 3 Sep 2015 03:37:44 -0700 (PDT) X-ASG-Debug-ID: 1441276663-04cb6c0e0f557f0001-NocioJ Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by cuda.sgi.com with ESMTP id YxZAvRvWWH7G57RT (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 03 Sep 2015 03:37:43 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com Received: by ioiz6 with SMTP id z6so52580085ioi.2 for ; Thu, 03 Sep 2015 03:37:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dCcN7m7ID8qMbaL5iNvzT2FgLNS3ZaOsULvWGMTVbKU=; b=MghM6OyqTymIzXWnhR7EOPARLrSnP8UzL9z1uhojPD78B57AeBdB9sg3n1UV1XmEuI x+/SONwxDXvKRpV4pEKFLEnyTQL2eTJcheI+fhGPX1GQfktffn+hQo1BIddHLn/WmlzX b0km+36f4RuIqfoWosChSyLRZsRq5sUg/UODWYasAaH51qlYDwksej0SzS/NEkvPWbmK qaNaERWhpCI+k5FZnXtZ33u7lxZJ6dwh0BeGhPjOs+ZhfX7ZlQfL9JoK4uzTAq0THFOu I8qOZcrWc8/DFayekqXuWyThOIw7nmtOr8Iwz7r6zmfaq3/pHasd3Cqm+rdliU4HAOLL aYYQ== X-Gm-Message-State: ALoCoQkrtK0v4hiX0wMlD36dNtSHrljVZI1XbTatZAj5+Yrcp7NkCpxUmm1Kd1nTFhPtCGkfCXio X-Received: by 10.107.14.203 with SMTP id 194mr31686083ioo.46.1441276663278; Thu, 03 Sep 2015 03:37:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Thu, 3 Sep 2015 03:37:23 -0700 (PDT) In-Reply-To: <20150903103317.GV3902@dastard> References: <1440590449-20372-1-git-send-email-jtulak@redhat.com> <1440590555-20463-1-git-send-email-jtulak@redhat.com> <1440590555-20463-10-git-send-email-jtulak@redhat.com> <20150831190120.GK349@infradead.org> <20150903103317.GV3902@dastard> From: Jan Tulak Date: Thu, 3 Sep 2015 12:37:23 +0200 Message-ID: Subject: Re: [PATCH 10/11] xfsprogs: add dummy mntent for OS X To: Dave Chinner X-ASG-Orig-Subj: Re: [PATCH 10/11] xfsprogs: add dummy mntent for OS X Cc: Christoph Hellwig , xfs-oss Content-Type: multipart/alternative; boundary=001a11409e3e89ccc1051ed55f77 X-Barracuda-Connect: mail-io0-f173.google.com[209.85.223.173] X-Barracuda-Start-Time: 1441276663 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22187 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --001a11409e3e89ccc1051ed55f77 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 3, 2015 at 12:33 PM, Dave Chinner wrote: > On Thu, Sep 03, 2015 at 11:01:44AM +0200, Jan Tulak wrote: > > On Mon, Aug 31, 2015 at 9:01 PM, Christoph Hellwig > > wrote: > > > > > On Wed, Aug 26, 2015 at 02:02:34PM +0200, Jan Tulak wrote: > > > > Because these calls are used only by xfs_fsr, which can't > > > > work on OS X unless a way how to mount XFS is found, > > > > there is not use in implementing these calls. > > > > > > Take a look at the quota code for the BSD alternative to mntent. > > > That code should be moved into a common location and used by fsr. > > > > > > > =E2=80=8BI tried to find it, but didn't found... Could you point me whe= re it is? > > Quota/freebsd.h has just few lines with one definition with errno =3D > > -ENOSYS, and in other files in quota/, I didn't saw anything BSD > specific. > > I think Christoph is refering to the code in libxcmd/paths.c: > > #if defined(HAVE_GETMNTENT) > .... > #elif defined(HAVE_GETMNTINFO) > .... > #else > # error "How do I extract info about mounted filesystems on this platform= ?" > #endif > # > > HAVE_GETMNTINFO is for BSD systems, IIRC. > > =E2=80=8BAll right, I will look on this. Thanks. :-) Cheers, Jan=E2=80=8B --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --001a11409e3e89ccc1051ed55f77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 3, 2015 at 12:33 PM, Dave Chinner <david@fromor= bit.com> wrote:
On Thu, Sep 03, 2015 at 11:01:44AM +0200, Jan Tulak wrote:
> On Mon, Aug 31, 2015 at 9:01 PM, Christoph Hellwig <hch@infradead.org>
> wrote:
>
> > On Wed, Aug 26, 2015 at 02:02:34PM +0200, Jan Tulak wrote:
> > > Because these calls are used only by xfs_fsr, which can'= t
> > > work on OS X unless a way how to mount XFS is found,
> > > there is not use in implementing these calls.
> >
> > Take a look at the quota code for the BSD alternative to mntent.<= br> > > That code should be moved into a common location and used by fsr.=
> >
>
> =E2=80=8BI tried to find it, but didn't found... Could you point m= e where it is?
> Quota/freebsd.h has just few lines with one definition with errno =3D<= br> > -ENOSYS, and in other files in quota/, I didn't saw anything BSD s= pecific.

I think Christoph is refering to the code in libxcmd/paths.c:

#if defined(HAVE_GETMNTENT)
....
#elif defined(HAVE_GETMNTINFO)
....
#else
# error "How do I extract info about mounted filesystems on this platf= orm?"
#endif
#

HAVE_GETMNTINFO is for BSD systems, IIRC.


=E2=80=8BAll right, = I will look on this. Thanks. :-)

Cheers,
Ja= n=E2=80=8B
=C2=A0

--
--001a11409e3e89ccc1051ed55f77-- From jtulak@redhat.com Thu Sep 3 05:39:51 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id E741D7F58 for ; Thu, 3 Sep 2015 05:39:51 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id D59EF8F8050 for ; Thu, 3 Sep 2015 03:39:51 -0700 (PDT) X-ASG-Debug-ID: 1441276790-04cbb06acd5e8c0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 0VBoLxevoqfuw7fU (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 03:39:51 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id A492F3FE73; Thu, 3 Sep 2015 10:39:50 +0000 (UTC) Received: from Jans-MacBook-Pro.local.com ([10.34.250.208]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83AdmvJ020505; Thu, 3 Sep 2015 06:39:49 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: hch@infradead.org, Jan Tulak Subject: [PATCH v2 07/11] xfsprogs: change nftw64 to nftw Date: Thu, 3 Sep 2015 12:39:44 +0200 X-ASG-Orig-Subj: [PATCH v2 07/11] xfsprogs: change nftw64 to nftw Message-Id: <1441276784-23701-1-git-send-email-jtulak@redhat.com> In-Reply-To: <1440590555-20463-7-git-send-email-jtulak@redhat.com> References: <1440590555-20463-7-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441276791 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Changelog: - Subject was "add nftw64 translation for OS X" - Changed from #define to renaming There is only one usage of nftw64 in entire xfsprogs, but multiple usages of nftw. It seems the 64 variant has no reason, and causes difficulties with some other platforms which has only nftw call. Signed-off-by: Jan Tulak --- estimate/xfs_estimate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/estimate/xfs_estimate.c b/estimate/xfs_estimate.c index 65b7168..632e4ec 100644 --- a/estimate/xfs_estimate.c +++ b/estimate/xfs_estimate.c @@ -168,7 +168,7 @@ main(int argc, char **argv) ndirs=0LL; /* number of directories */ nspecial=0LL; /* number of special files */ - nftw64(argv[optind], ffn, 40, FTW_PHYS | FTW_MOUNT); + nftw(argv[optind], ffn, 40, FTW_PHYS | FTW_MOUNT); if (__debug) { printf(_("dirsize=%llu\n"), dirsize); -- 2.4.5 From bfoster@redhat.com Thu Sep 3 05:45:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 860F67F83 for ; Thu, 3 Sep 2015 05:45:40 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 6693B8F8050 for ; Thu, 3 Sep 2015 03:45:40 -0700 (PDT) X-ASG-Debug-ID: 1441277139-04bdf06dd75c250001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id E3jKhkRJs44Qq18s (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 03:45:39 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id EAB1C8EA3E; Thu, 3 Sep 2015 10:45:38 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-103.bos.redhat.com [10.18.41.103]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83AjcOo015714; Thu, 3 Sep 2015 06:45:38 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 9E7F3123E8A; Thu, 3 Sep 2015 06:45:37 -0400 (EDT) Date: Thu, 3 Sep 2015 06:45:37 -0400 From: Brian Foster To: Colin King Cc: Dave Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] xfs: fix null pointer dereference when mapping is NULL Message-ID: <20150903104537.GA46225@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH] xfs: fix null pointer dereference when mapping is NULL References: <1441274260-10120-1-git-send-email-colin.king@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441274260-10120-1-git-send-email-colin.king@canonical.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441277139 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 03, 2015 at 10:57:40AM +0100, Colin King wrote: > From: Colin Ian King > > xfs_vm_set_page_dirty checks to see if mapping is NULL however > before this unlikely check it already dereferenced mapping when > initializing inode. Move the inode initialization after the mapping > null check to avoid a potential null pointer dereference. > > Fixes: 22e757a49cf0 ("xfs: don't dirty buffers beyond EOF") > Signed-off-by: Colin Ian King > --- Reviewed-by: Brian Foster > fs/xfs/xfs_aops.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c > index c77499b..d15ae85 100644 > --- a/fs/xfs/xfs_aops.c > +++ b/fs/xfs/xfs_aops.c > @@ -1935,7 +1935,7 @@ xfs_vm_set_page_dirty( > struct page *page) > { > struct address_space *mapping = page->mapping; > - struct inode *inode = mapping->host; > + struct inode *inode; > loff_t end_offset; > loff_t offset; > int newly_dirty; > @@ -1944,6 +1944,7 @@ xfs_vm_set_page_dirty( > if (unlikely(!mapping)) > return !TestSetPageDirty(page); > > + inode = mapping->host; > end_offset = i_size_read(inode); > offset = page_offset(page); > > -- > 2.5.0 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From danny@zadarastorage.com Thu Sep 3 06:09:37 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 5F5447F3F for ; Thu, 3 Sep 2015 06:09:37 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id D3F1AAC006 for ; Thu, 3 Sep 2015 04:09:33 -0700 (PDT) X-ASG-Debug-ID: 1441278570-04cbb06aca5f4e0001-NocioJ Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by cuda.sgi.com with ESMTP id GB69RhenWsKpoKPr (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 03 Sep 2015 04:09:31 -0700 (PDT) X-Barracuda-Envelope-From: danny@zadarastorage.com X-Barracuda-Apparent-Source-IP: 209.85.212.180 Received: by wicfx3 with SMTP id fx3so15956626wic.1 for ; Thu, 03 Sep 2015 04:09:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=B/K+5YvN7k4gGlAf+U9rIjz+dobLTvLyIg99DFtw8x8=; b=YI4U+Zj5/D/MK5bPj8aI4wJLKq4Rb3cqC0eoxherx6VkDFc6ELjy9OJuzaW3PdUw16 DnLtzddyV4J3vEiKNMURb77rjMh6h4tKcfzj+kuiJPzNUYpXNynAuxPAbW3V38RTIPtT is4MTyItZkRvBs9gBrLRX1zBoSpeGtzYkiBR0kN1dcNqYF2y+y3KrrZPamQXfcsnjeF1 pw/VpbsKYI3BEu0bDUxKPN6uXbQunPlti9hPrRjl1K+gaycOSVpReA2H79CqQZyfxqyj cjvGM3d0eJ/zosDakBTbTueINIbMWXYDLgWrjKCHYoXAglwBsbsbouk7odFZtuvL9DHy wZmA== X-Gm-Message-State: ALoCoQkj4gTQQ3/MtqnpTEV6VDoycibU8Lxrgl3j6A786+qrgB6gBZvzJ7SxGghIjaWMMReKOkyS MIME-Version: 1.0 X-Received: by 10.180.75.137 with SMTP id c9mr13502997wiw.16.1441278570244; Thu, 03 Sep 2015 04:09:30 -0700 (PDT) Received: by 10.28.93.134 with HTTP; Thu, 3 Sep 2015 04:09:30 -0700 (PDT) Date: Thu, 3 Sep 2015 14:09:30 +0300 Message-ID: Subject: xfs corruption From: Danny Shavit X-ASG-Orig-Subj: xfs corruption To: xfs@oss.sgi.com Cc: Alex Lyakas Content-Type: multipart/mixed; boundary=f46d04388e0d343012051ed5d1ea X-Barracuda-Connect: mail-wi0-f180.google.com[209.85.212.180] X-Barracuda-Start-Time: 1441278571 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22187 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --f46d04388e0d343012051ed5d1ea Content-Type: multipart/alternative; boundary=f46d04388e0d34300d051ed5d1e8 --f46d04388e0d34300d051ed5d1e8 Content-Type: text/plain; charset=UTF-8 Hi Dave, We couple of more xfs corruption that we would like to share: 1. This is an interesting one, since xfs reported corruption but when running xfs_repair, no error was found. Attached is the kernel log section regarding the corruption (6458). Does xfs_repair explicitly read data from the disk? In such case it might be a memory corruption. Are you familiar with such cases? 2. xfs corruption occurred suddenly with no apparent external event. Attached are xfs_repair and kernel logs are. Xfs dump can be found in: https://zadarastorage-public.s3.amazonaws.com/xfs/82.metadump.gz -- Thanks, Danny Shavit ZadaraStorage --f46d04388e0d34300d051ed5d1e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,

We couple of more xfs corrupti= on that we would like to share:

1. This is an inte= resting one, since xfs reported corruption but when running xfs_repair, no = error was found.
Attached is the kernel log section regarding the= corruption (6458).
Does xfs_repair explicitly read data from the= disk? In such case it might be a memory corruption. Are you familiar with = such cases?

2. xfs corruption occurred suddenly wi= th no apparent external event.=C2=A0
Attached are xfs_repair and = kernel logs are.=C2=A0
Xfs dump can be found in:
=



--
Thanks,
Danny Shav= it
ZadaraStorage
--f46d04388e0d34300d051ed5d1e8-- --f46d04388e0d343012051ed5d1ea Content-Type: application/octet-stream; name="6458-kernel.log" Content-Disposition: attachment; filename="6458-kernel.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ie40vumg0 VGhlIFhGUyB2b2x1bWVzIHRoZW4gZW50ZXJlZCBhIGNvcnJ1cHRlZCBzdGF0ZToKCkF1ZyAyNyAw MTowMTozNCB2c2EtMDAwMDAxNGUtdmMtMCBrZXJuZWw6IFszNTA3MTA1LjMwNzc0M10gWEZTIChk bS0zOSk6IEludGVybmFsIGVycm9yIHhmc19hbGxvY2J0X3ZlcmlmeSBhdCBsaW5lIDMzMCBvZiBm aWxlIC9tbnQvc2hhcmUvYnVpbGRzLzE0LjExLS0zLjguMTMtMDMwODEzLWdlbmVyaWMvMjAxNS0w NC0yOV8xMC00NS00Mi0tMTQuMTEtMTYwMS0xMjQvc3JjL3phZGFyYS1idHJmcy9mcy94ZnMveGZz X2FsbG9jX2J0cmVlLmMuICBDYWxsZXIgMHhmZmZmZmZmZmEwNjRlOWNlCkF1ZyAyNyAwMTowMToz NCB2c2EtMDAwMDAxNGUtdmMtMCBrZXJuZWw6IFszNTA3MTA1LjMwNzc0M10KQXVnIDI3IDAxOjAx OjM0IHZzYS0wMDAwMDE0ZS12Yy0wIGtlcm5lbDogWzM1MDcxMDUuMzE0NDQ2XSBQaWQ6IDI1MjMx LCBjb21tOiBrd29ya2VyLzA6MEggVGFpbnRlZDogR0YgICAgICAgVyAgTyAzLjguMTMtMDMwODEz LWdlbmVyaWMgIzIwMTMwNTExMTg0MwpBdWcgMjcgMDE6MDE6MzQgdnNhLTAwMDAwMTRlLXZjLTAg a2VybmVsOiBbMzUwNzEwNS4zMTQ0NDldIENhbGwgVHJhY2U6CkF1ZyAyNyAwMTowMTozNCB2c2Et MDAwMDAxNGUtdmMtMCBrZXJuZWw6IFszNTA3MTA1LjMxNDQ4N10gIFs8ZmZmZmZmZmZhMDYzMWJh Zj5dIHhmc19lcnJvcl9yZXBvcnQrMHgzZi8weDUwIFt4ZnNdCkF1ZyAyNyAwMTowMTozNCB2c2Et MDAwMDAxNGUtdmMtMCBrZXJuZWw6IFszNTA3MTA1LjMxNDUwMl0gIFs8ZmZmZmZmZmZhMDY0ZTlj ZT5dID8geGZzX2FsbG9jYnRfcmVhZF92ZXJpZnkrMHhlLzB4MTAgW3hmc10KQXVnIDI3IDAxOjAx OjM0IHZzYS0wMDAwMDE0ZS12Yy0wIGtlcm5lbDogWzM1MDcxMDUuMzE0NTE0XSAgWzxmZmZmZmZm ZmEwNjMxYzFlPl0geGZzX2NvcnJ1cHRpb25fZXJyb3IrMHg1ZS8weDkwIFt4ZnNdCkF1ZyAyNyAw MTowMTozNCB2c2EtMDAwMDAxNGUtdmMtMCBrZXJuZWw6IFszNTA3MTA1LjMxNDUyOF0gIFs8ZmZm ZmZmZmZhMDY0ZTg2Mj5dIHhmc19hbGxvY2J0X3ZlcmlmeSsweDkyLzB4MWUwIFt4ZnNdCkF1ZyAy NyAwMTowMTozNCB2c2EtMDAwMDAxNGUtdmMtMCBrZXJuZWw6IFszNTA3MTA1LjMxNDU0MF0gIFs8 ZmZmZmZmZmZhMDY0ZTljZT5dID8geGZzX2FsbG9jYnRfcmVhZF92ZXJpZnkrMHhlLzB4MTAgW3hm c10KQXVnIDI3IDAxOjAxOjM0IHZzYS0wMDAwMDE0ZS12Yy0wIGtlcm5lbDogWzM1MDcxMDUuMzE0 NTQ3XSAgWzxmZmZmZmZmZjgxMDEzNWFhPl0gPyBfX3N3aXRjaF90bysweDEyYS8weDRhMApBdWcg MjcgMDE6MDE6MzQgdnNhLTAwMDAwMTRlLXZjLTAga2VybmVsOiBbMzUwNzEwNS4zMTQ1NTFdICBb PGZmZmZmZmZmODEwOTZjZDg+XSA/IHNldF9uZXh0X2VudGl0eSsweGE4LzB4YzAKQXVnIDI3IDAx OjAxOjM0IHZzYS0wMDAwMDE0ZS12Yy0wIGtlcm5lbDogWzM1MDcxMDUuMzE0NTY2XSAgWzxmZmZm ZmZmZmEwNjRlOWNlPl0geGZzX2FsbG9jYnRfcmVhZF92ZXJpZnkrMHhlLzB4MTAgW3hmc10KQXVn IDI3IDAxOjAxOjM0IHZzYS0wMDAwMDE0ZS12Yy0wIGtlcm5lbDogWzM1MDcxMDUuMzE1MjUxXSAg WzxmZmZmZmZmZmEwNjJmNDhmPl0geGZzX2J1Zl9pb2RvbmVfd29yaysweDNmLzB4YTAgW3hmc10K QXVnIDI3IDAxOjAxOjM0IHZzYS0wMDAwMDE0ZS12Yy0wIGtlcm5lbDogWzM1MDcxMDUuMzE1MjU1 XSAgWzxmZmZmZmZmZjgxMDc4YjgxPl0gcHJvY2Vzc19vbmVfd29yaysweDE0MS8weDQ5MApBdWcg MjcgMDE6MDE6MzQgdnNhLTAwMDAwMTRlLXZjLTAga2VybmVsOiBbMzUwNzEwNS4zMTUyNTddICBb PGZmZmZmZmZmODEwNzliNDg+XSB3b3JrZXJfdGhyZWFkKzB4MTY4LzB4NDAwCkF1ZyAyNyAwMTow MTozNCB2c2EtMDAwMDAxNGUtdmMtMCBrZXJuZWw6IFszNTA3MTA1LjMxNTI1OV0gIFs8ZmZmZmZm ZmY4MTA3OTllMD5dID8gbWFuYWdlX3dvcmtlcnMrMHgxMjAvMHgxMjAKQXVnIDI3IDAxOjAxOjM0 IHZzYS0wMDAwMDE0ZS12Yy0wIGtlcm5lbDogWzM1MDcxMDUuMzE1MjYyXSAgWzxmZmZmZmZmZjgx MDdmMDUwPl0ga3RocmVhZCsweGMwLzB4ZDAKQXVnIDI3IDAxOjAxOjM0IHZzYS0wMDAwMDE0ZS12 Yy0wIGtlcm5lbDogWzM1MDcxMDUuMzE1MjY1XSAgWzxmZmZmZmZmZjgxMDdlZjkwPl0gPyBmbHVz aF9rdGhyZWFkX3dvcmtlcisweGIwLzB4YjAKQXVnIDI3IDAxOjAxOjM0IHZzYS0wMDAwMDE0ZS12 Yy0wIGtlcm5lbDogWzM1MDcxMDUuMzE1MjcwXSAgWzxmZmZmZmZmZjgxNmY2MWVjPl0gcmV0X2Zy b21fZm9yaysweDdjLzB4YjAKQXVnIDI3IDAxOjAxOjM0IHZzYS0wMDAwMDE0ZS12Yy0wIGtlcm5l bDogWzM1MDcxMDUuMzE1MjczXSAgWzxmZmZmZmZmZjgxMDdlZjkwPl0gPyBmbHVzaF9rdGhyZWFk X3dvcmtlcisweGIwLzB4YjAKQXVnIDI3IDAxOjAxOjM0IHZzYS0wMDAwMDE0ZS12Yy0wIGtlcm5l bDogWzM1MDcxMDUuMzE1Mjc1XSBYRlMgKGRtLTM5KTogQ29ycnVwdGlvbiBkZXRlY3RlZC4gVW5t b3VudCBhbmQgcnVuIHhmc19yZXBhaXIKQXVnIDI3IDAxOjAxOjM0IHZzYS0wMDAwMDE0ZS12Yy0w IGtlcm5lbDogWzM1MDcxMDUuMzE2NzA2XSBYRlMgKGRtLTM5KTogbWV0YWRhdGEgSS9PIGVycm9y OiBibG9jayAweDQxYTZlZmY4ICgieGZzX3RyYW5zX3JlYWRfYnVmX21hcCIpIGVycm9yIDExNyBu dW1ibGtzIDgK --f46d04388e0d343012051ed5d1ea Content-Type: application/octet-stream; name="6442-82-xfs_repair.log" Content-Disposition: attachment; filename="6442-82-xfs_repair.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ie43r2yp1 cm9vdEB2c2EtMDAwMDAxMTAtdmMtMDp+IyB4ZnNfcmVwYWlyIC9kZXYvZG0tODIKUGhhc2UgMSAt IGZpbmQgYW5kIHZlcmlmeSBzdXBlcmJsb2NrLi4uClBoYXNlIDIgLSB1c2luZyBpbnRlcm5hbCBs b2cKICAgICAgICAtIHplcm8gbG9nLi4uCkVSUk9SOiBUaGUgZmlsZXN5c3RlbSBoYXMgdmFsdWFi bGUgbWV0YWRhdGEgY2hhbmdlcyBpbiBhIGxvZyB3aGljaCBuZWVkcyB0bwpiZSByZXBsYXllZC4g IE1vdW50IHRoZSBmaWxlc3lzdGVtIHRvIHJlcGxheSB0aGUgbG9nLCBhbmQgdW5tb3VudCBpdCBi ZWZvcmUKcmUtcnVubmluZyB4ZnNfcmVwYWlyLiAgSWYgeW91IGFyZSB1bmFibGUgdG8gbW91bnQg dGhlIGZpbGVzeXN0ZW0sIHRoZW4gdXNlCnRoZSAtTCBvcHRpb24gdG8gZGVzdHJveSB0aGUgbG9n IGFuZCBhdHRlbXB0IGEgcmVwYWlyLgpOb3RlIHRoYXQgZGVzdHJveWluZyB0aGUgbG9nIG1heSBj YXVzZSBjb3JydXB0aW9uIC0tIHBsZWFzZSBhdHRlbXB0IGEgbW91bnQKb2YgdGhlIGZpbGVzeXN0 ZW0gYmVmb3JlIGRvaW5nIHRoaXMuCnJvb3RAdnNhLTAwMDAwMTEwLXZjLTA6fiMgeGZzX3JlcGFp ciAtTCAvZGV2L2RtLTgyClBoYXNlIDEgLSBmaW5kIGFuZCB2ZXJpZnkgc3VwZXJibG9jay4uLgpQ aGFzZSAyIC0gdXNpbmcgaW50ZXJuYWwgbG9nCiAgICAgICAgLSB6ZXJvIGxvZy4uLgpBTEVSVDog VGhlIGZpbGVzeXN0ZW0gaGFzIHZhbHVhYmxlIG1ldGFkYXRhIGNoYW5nZXMgaW4gYSBsb2cgd2hp Y2ggaXMgYmVpbmcKZGVzdHJveWVkIGJlY2F1c2UgdGhlIC1MIG9wdGlvbiB3YXMgdXNlZC4KICAg ICAgICAtIHNjYW4gZmlsZXN5c3RlbSBmcmVlc3BhY2UgYW5kIGlub2RlIG1hcHMuLi4KYWdpIHVu bGlua2VkIGJ1Y2tldCAxIGlzIDEyNTgwMzUzIGluIGFnIDMgKGlub2RlPTIxMzkwNjk0NSkKc2Jf aWNvdW50IDEyMjY0OTYsIGNvdW50ZWQgMTIyNzc3NgpzYl9pZnJlZSAyOTIxODAsIGNvdW50ZWQg Mjk3MDgyCnNiX2ZkYmxvY2tzIDMxMTgyNzM5LCBjb3VudGVkIDU1MTU4MDQ0CiAgICAgICAgLSBm b3VuZCByb290IGlub2RlIGNodW5rClBoYXNlIDMgLSBmb3IgZWFjaCBBRy4uLgogICAgICAgIC0g c2NhbiBhbmQgY2xlYXIgYWdpIHVubGlua2VkIGxpc3RzLi4uCiAgICAgICAgLSBwcm9jZXNzIGtu b3duIGlub2RlcyBhbmQgcGVyZm9ybSBpbm9kZSBkaXNjb3ZlcnkuLi4KICAgICAgICAtIGFnbm8g PSAwCiAgICAgICAgLSBhZ25vID0gMQogICAgICAgIC0gYWdubyA9IDIKN2Y4ZDIyYTJjNzAwOiBC YWRuZXNzIGluIGtleSBsb29rdXAgKGxlbmd0aCkKYnA9KGJubyA4NDkzMjk5MiwgbGVuIDE2Mzg0 IGJ5dGVzKSBrZXk9KGJubyA4NDkzMjk5MiwgbGVuIDgxOTIgYnl0ZXMpCiAgICAgICAgLSBhZ25v ID0gMwpiYWQgbWFnaWMgIyAweGVhYmIxMjNhIGluIGlub2RlIDIxMzkwNjk0NSAoZGF0YSBmb3Jr KSBibWJ0IGJsb2NrIDEzMzY5MjQyCmJhZCBkYXRhIGZvcmsgaW4gaW5vZGUgMjEzOTA2OTQ1CmNs ZWFyZWQgaW5vZGUgMjEzOTA2OTQ1CmNsZWFyaW5nIGZvcncvYmFjayBwb2ludGVycyBpbiBibG9j ayAwIGZvciBhdHRyaWJ1dGVzIGluIGlub2RlIDIxMzkwNjk1MwpiYWQgYXR0cmlidXRlIGxlYWYg bWFnaWMgIyAweGJjNmMgZm9yIGRpciBpbm8gMjEzOTA2OTUzCnByb2JsZW0gd2l0aCBhdHRyaWJ1 dGUgY29udGVudHMgaW4gaW5vZGUgMjEzOTA2OTUzCmNsZWFyaW5nIGlub2RlIDIxMzkwNjk1MyBh dHRyaWJ1dGVzCmNvcnJlY3RpbmcgbmJsb2NrcyBmb3IgaW5vZGUgMjEzOTA2OTUzLCB3YXMgNjYg LSBjb3VudGVkIDY1CmNsZWFyaW5nIGZvcncvYmFjayBwb2ludGVycyBpbiBibG9jayAwIGZvciBh dHRyaWJ1dGVzIGluIGlub2RlIDIxMzkwNjk1NApiYWQgYXR0cmlidXRlIGxlYWYgbWFnaWMgIyAw eGRlNzIgZm9yIGRpciBpbm8gMjEzOTA2OTU0CnByb2JsZW0gd2l0aCBhdHRyaWJ1dGUgY29udGVu dHMgaW4gaW5vZGUgMjEzOTA2OTU0CmNsZWFyaW5nIGlub2RlIDIxMzkwNjk1NCBhdHRyaWJ1dGVz CmNvcnJlY3RpbmcgbmJsb2NrcyBmb3IgaW5vZGUgMjEzOTA2OTU0LCB3YXMgMiAtIGNvdW50ZWQg MQpjbGVhcmluZyBmb3J3L2JhY2sgcG9pbnRlcnMgaW4gYmxvY2sgMCBmb3IgYXR0cmlidXRlcyBp biBpbm9kZSAyMTM5MDY5NjAKYmFkIGF0dHJpYnV0ZSBsZWFmIG1hZ2ljICMgMHhkMGViIGZvciBk aXIgaW5vIDIxMzkwNjk2MApwcm9ibGVtIHdpdGggYXR0cmlidXRlIGNvbnRlbnRzIGluIGlub2Rl IDIxMzkwNjk2MApjbGVhcmluZyBpbm9kZSAyMTM5MDY5NjAgYXR0cmlidXRlcwpjb3JyZWN0aW5n IG5ibG9ja3MgZm9yIGlub2RlIDIxMzkwNjk2MCwgd2FzIDQgLSBjb3VudGVkIDMKY2xlYXJpbmcg Zm9ydy9iYWNrIHBvaW50ZXJzIGluIGJsb2NrIDAgZm9yIGF0dHJpYnV0ZXMgaW4gaW5vZGUgMjEz OTA2OTYxCmJhZCBhdHRyaWJ1dGUgbGVhZiBtYWdpYyAjIDB4Yjg3NiBmb3IgZGlyIGlubyAyMTM5 MDY5NjEKcHJvYmxlbSB3aXRoIGF0dHJpYnV0ZSBjb250ZW50cyBpbiBpbm9kZSAyMTM5MDY5NjEK Y2xlYXJpbmcgaW5vZGUgMjEzOTA2OTYxIGF0dHJpYnV0ZXMKY29ycmVjdGluZyBuYmxvY2tzIGZv ciBpbm9kZSAyMTM5MDY5NjEsIHdhcyA1IC0gY291bnRlZCA0CiAgICAgICAgLSBhZ25vID0gNAog ICAgICAgIC0gYWdubyA9IDUKY2xlYXJpbmcgZm9ydy9iYWNrIHBvaW50ZXJzIGluIGJsb2NrIDAg Zm9yIGF0dHJpYnV0ZXMgaW4gaW5vZGUgMzQ3MjM1MTA1CmJhZCBhdHRyaWJ1dGUgbGVhZiBtYWdp YyAjIDB4YjAzMyBmb3IgZGlyIGlubyAzNDcyMzUxMDUKcHJvYmxlbSB3aXRoIGF0dHJpYnV0ZSBj b250ZW50cyBpbiBpbm9kZSAzNDcyMzUxMDUKY2xlYXJpbmcgaW5vZGUgMzQ3MjM1MTA1IGF0dHJp YnV0ZXMKY29ycmVjdGluZyBuYmxvY2tzIGZvciBpbm9kZSAzNDcyMzUxMDUsIHdhcyA5IC0gY291 bnRlZCA4CmNsZWFyaW5nIGZvcncvYmFjayBwb2ludGVycyBpbiBibG9jayAwIGZvciBhdHRyaWJ1 dGVzIGluIGlub2RlIDM0NzIzNTEwNgpiYWQgYXR0cmlidXRlIGxlYWYgbWFnaWMgIyAweGUxMyBm b3IgZGlyIGlubyAzNDcyMzUxMDYKcHJvYmxlbSB3aXRoIGF0dHJpYnV0ZSBjb250ZW50cyBpbiBp bm9kZSAzNDcyMzUxMDYKY2xlYXJpbmcgaW5vZGUgMzQ3MjM1MTA2IGF0dHJpYnV0ZXMKY29ycmVj dGluZyBuYmxvY2tzIGZvciBpbm9kZSAzNDcyMzUxMDYsIHdhcyA5IC0gY291bnRlZCA4CiAgICAg ICAgLSBhZ25vID0gNgogICAgICAgIC0gYWdubyA9IDcKY2xlYXJpbmcgZm9ydy9iYWNrIHBvaW50 ZXJzIGluIGJsb2NrIDAgZm9yIGF0dHJpYnV0ZXMgaW4gaW5vZGUgNDc4NzU5NzAyCmJhZCBhdHRy aWJ1dGUgbGVhZiBtYWdpYyAjIDB4YTA2NSBmb3IgZGlyIGlubyA0Nzg3NTk3MDIKcHJvYmxlbSB3 aXRoIGF0dHJpYnV0ZSBjb250ZW50cyBpbiBpbm9kZSA0Nzg3NTk3MDIKY2xlYXJpbmcgaW5vZGUg NDc4NzU5NzAyIGF0dHJpYnV0ZXMKY29ycmVjdGluZyBuYmxvY2tzIGZvciBpbm9kZSA0Nzg3NTk3 MDIsIHdhcyAxNTYxIC0gY291bnRlZCAxNTYwCiAgICAgICAgLSBhZ25vID0gOAogICAgICAgIC0g YWdubyA9IDkKICAgICAgICAtIGFnbm8gPSAxMAogICAgICAgIC0gYWdubyA9IDExCiAgICAgICAg LSBhZ25vID0gMTIKICAgICAgICAtIGFnbm8gPSAxMwogICAgICAgIC0gYWdubyA9IDE0CiAgICAg ICAgLSBhZ25vID0gMTUKICAgICAgICAtIGFnbm8gPSAxNgogICAgICAgIC0gYWdubyA9IDE3CiAg ICAgICAgLSBhZ25vID0gMTgKICAgICAgICAtIGFnbm8gPSAxOQogICAgICAgIC0gYWdubyA9IDIw CiAgICAgICAgLSBhZ25vID0gMjEKICAgICAgICAtIGFnbm8gPSAyMgogICAgICAgIC0gYWdubyA9 IDIzCiAgICAgICAgLSBhZ25vID0gMjQKICAgICAgICAtIHByb2Nlc3MgbmV3bHkgZGlzY292ZXJl ZCBpbm9kZXMuLi4KUGhhc2UgNCAtIGNoZWNrIGZvciBkdXBsaWNhdGUgYmxvY2tzLi4uCiAgICAg ICAgLSBzZXR0aW5nIHVwIGR1cGxpY2F0ZSBleHRlbnQgbGlzdC4uLgogICAgICAgIC0gY2hlY2sg Zm9yIGlub2RlcyBjbGFpbWluZyBkdXBsaWNhdGUgYmxvY2tzLi4uCiAgICAgICAgLSBhZ25vID0g MAogICAgICAgIC0gYWdubyA9IDEKICAgICAgICAtIGFnbm8gPSAyCiAgICAgICAgLSBhZ25vID0g MwpiYWQgbWFnaWMgIyAweDU4NDY1MzQyIGluIGlub2RlIDIxMzkwNjk1MyAoZGF0YSBmb3JrKSBi bWJ0IGJsb2NrIDAKYmFkIGRhdGEgZm9yayBpbiBpbm9kZSAyMTM5MDY5NTMKY2xlYXJlZCBpbm9k ZSAyMTM5MDY5NTMKYmFkIGF0dHJpYnV0ZSBmb3JtYXQgMSBpbiBpbm9kZSAyMTM5MDY5NTQsIHJl c2V0dGluZyB2YWx1ZQpiYWQgYXR0cmlidXRlIGZvcm1hdCAxIGluIGlub2RlIDIxMzkwNjk2MCwg cmVzZXR0aW5nIHZhbHVlCmJhZCBhdHRyaWJ1dGUgZm9ybWF0IDEgaW4gaW5vZGUgMjEzOTA2OTYx LCByZXNldHRpbmcgdmFsdWUKICAgICAgICAtIGFnbm8gPSA0CiAgICAgICAgLSBhZ25vID0gNQpi YWQgYXR0cmlidXRlIGZvcm1hdCAxIGluIGlub2RlIDM0NzIzNTEwNSwgcmVzZXR0aW5nIHZhbHVl CmJhZCBhdHRyaWJ1dGUgZm9ybWF0IDEgaW4gaW5vZGUgMzQ3MjM1MTA2LCByZXNldHRpbmcgdmFs dWUKICAgICAgICAtIGFnbm8gPSA2CiAgICAgICAgLSBhZ25vID0gNwpiYWQgbWFnaWMgIyAweDU4 NDY1MzQyIGluIGlub2RlIDQ3ODc1OTcwMiAoZGF0YSBmb3JrKSBibWJ0IGJsb2NrIDAKYmFkIGRh dGEgZm9yayBpbiBpbm9kZSA0Nzg3NTk3MDIKY2xlYXJlZCBpbm9kZSA0Nzg3NTk3MDIKICAgICAg ICAtIGFnbm8gPSA4CiAgICAgICAgLSBhZ25vID0gOQogICAgICAgIC0gYWdubyA9IDEwCiAgICAg ICAgLSBhZ25vID0gMTEKICAgICAgICAtIGFnbm8gPSAxMgogICAgICAgIC0gYWdubyA9IDEzCiAg ICAgICAgLSBhZ25vID0gMTQKICAgICAgICAtIGFnbm8gPSAxNQogICAgICAgIC0gYWdubyA9IDE2 CiAgICAgICAgLSBhZ25vID0gMTcKICAgICAgICAtIGFnbm8gPSAxOAogICAgICAgIC0gYWdubyA9 IDE5CiAgICAgICAgLSBhZ25vID0gMjAKICAgICAgICAtIGFnbm8gPSAyMQogICAgICAgIC0gYWdu byA9IDIyCiAgICAgICAgLSBhZ25vID0gMjMKICAgICAgICAtIGFnbm8gPSAyNApQaGFzZSA1IC0g cmVidWlsZCBBRyBoZWFkZXJzIGFuZCB0cmVlcy4uLgogICAgICAgIC0gcmVzZXQgc3VwZXJibG9j ay4uLgo3ZjhkMjQ0Nzg3NDA6IEJhZG5lc3MgaW4ga2V5IGxvb2t1cCAobGVuZ3RoKQpicD0oYm5v IDAsIGxlbiA0MDk2IGJ5dGVzKSBrZXk9KGJubyAwLCBsZW4gNTEyIGJ5dGVzKQpQaGFzZSA2IC0g Y2hlY2sgaW5vZGUgY29ubmVjdGl2aXR5Li4uCiAgICAgICAgLSByZXNldHRpbmcgY29udGVudHMg b2YgcmVhbHRpbWUgYml0bWFwIGFuZCBzdW1tYXJ5IGlub2RlcwogICAgICAgIC0gdHJhdmVyc2lu ZyBmaWxlc3lzdGVtIC4uLgplbnRyeSAiMzI0Ny5wbmciIGluIGRpcmVjdG9yeSBpbm9kZSAyMDEz MjY5MjQgcG9pbnRzIHRvIGZyZWUgaW5vZGUgMjEzOTA2OTUzCmJhZCBoYXNoIHRhYmxlIGZvciBk aXJlY3RvcnkgaW5vZGUgMjAxMzI2OTI0IChubyBkYXRhIGVudHJ5KTogcmVidWlsZGluZwpyZWJ1 aWxkaW5nIGRpcmVjdG9yeSBpbm9kZSAyMDEzMjY5MjQKZW50cnkgIjAyNTEwNTAuTldCIiBpbiBk aXJlY3RvcnkgaW5vZGUgNDY5NzYyMzY2IHBvaW50cyB0byBmcmVlIGlub2RlIDQ3ODc1OTcwMgpy ZWJ1aWxkaW5nIGRpcmVjdG9yeSBpbm9kZSA0Njk3NjIzNjYKICAgICAgICAtIHRyYXZlcnNhbCBm aW5pc2hlZCAuLi4KICAgICAgICAtIG1vdmluZyBkaXNjb25uZWN0ZWQgaW5vZGVzIHRvIGxvc3Qr Zm91bmQgLi4uClBoYXNlIDcgLSB2ZXJpZnkgYW5kIGNvcnJlY3QgbGluayBjb3VudHMuLi4KZG9u ZQpyb290QHZzYS0wMDAwMDExMC12Yy0wOn4jIGVjaG8gJD8KMApyb290QHZzYS0wMDAwMDExMC12 Yy0wOn4jIGNybV9tb24KQ29ubmVjdGlvbiB0byB0aGUgQ0lCIHRlcm1pbmF0ZWQKUmVjb25uZWN0 aW5nLi4ucm9vdEB2c2EtMDAwMDAxMTAtdmMtMDp+IyBsZXNzIC92YXIvbG9nL2tlcm4ubG9nCnJv b3RAdnNhLTAwMDAwMTEwLXZjLTA6fiMK --f46d04388e0d343012051ed5d1ea Content-Type: application/octet-stream; name="dm-82-kernel.log" Content-Disposition: attachment; filename="dm-82-kernel.log" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ie43rzge2 QXVnIDIyIDIzOjI0OjQ4IHZzYS0wMDAwMDExMC12Yy0wIGtlcm5lbDogWzQxOTQ1OTkuNjg1MzUz XSBmZmZmODgwMTBlYzM2MDAwOiBlYSBiYiAxMiAzYSA1ZiA0NCAwMSBhOCBiOSAyYSA4MCAxMCBi MyBhNyBkNSBhZiAgLi4uOl9ELi4uKi4uLi4uLgpBdWcgMjIgMjM6MjQ6NDggdnNhLTAwMDAwMTEw LXZjLTAga2VybmVsOiBbNDE5NDU5OS42ODY1NjhdIFhGUyAoZG0tODIpOiBJbnRlcm5hbCBlcnJv ciB4ZnNfYm1idF92ZXJpZnkgYXQgbGluZSA3NDcgb2YgZmlsZSAvbW50L3NoYXJlL2J1aWxkcy8x NC4xMS0tMy44LjEzLTAzMDgxMy1nZW5lcmljLzIwMTUtMDYtMTdfMDMtMzAtMzctLTE0LjExLTE2 MDEtMTI5L3NyYy96YWRhcmEtYnRyZnMvZnMveGZzL3hmc19ibWFwX2J0cmVlLmMuICBDYWxsZXIg MHhmZmZmZmZmZmEwNzc3OWVlCkF1ZyAyMiAyMzoyNDo0OCB2c2EtMDAwMDAxMTAtdmMtMCBrZXJu ZWw6IFs0MTk0NTk5LjY4NjU2OF0gCkF1ZyAyMiAyMzoyNDo0OCB2c2EtMDAwMDAxMTAtdmMtMCBr ZXJuZWw6IFs0MTk0NTk5LjY4OTM5M10gUGlkOiAxNzA2MywgY29tbToga3dvcmtlci8wOjFIIFRh aW50ZWQ6IEdGICAgICAgIFcgIE8gMy44LjEzLTAzMDgxMy1nZW5lcmljICMyMDEzMDUxMTE4NDMK QXVnIDIyIDIzOjI0OjQ4IHZzYS0wMDAwMDExMC12Yy0wIGtlcm5lbDogWzQxOTQ1OTkuNjg5Mzk1 XSBDYWxsIFRyYWNlOgpBdWcgMjIgMjM6MjQ6NDggdnNhLTAwMDAwMTEwLXZjLTAga2VybmVsOiBb NDE5NDU5OS42ODk0NDNdICBbPGZmZmZmZmZmYTA3NDZiYWY+XSB4ZnNfZXJyb3JfcmVwb3J0KzB4 M2YvMHg1MCBbeGZzXQpBdWcgMjIgMjM6MjQ6NDggdnNhLTAwMDAwMTEwLXZjLTAga2VybmVsOiBb NDE5NDU5OS42ODk0OTFdICBbPGZmZmZmZmZmYTA3Nzc5ZWU+XSA/IHhmc19ibWJ0X3JlYWRfdmVy aWZ5KzB4ZS8weDEwIFt4ZnNdCkF1ZyAyMiAyMzoyNDo0OCB2c2EtMDAwMDAxMTAtdmMtMCBrZXJu ZWw6IFs0MTk0NTk5LjY4OTUwM10gIFs8ZmZmZmZmZmZhMDc0NmMxZT5dIHhmc19jb3JydXB0aW9u X2Vycm9yKzB4NWUvMHg5MCBbeGZzXQpBdWcgMjIgMjM6MjQ6NDggdnNhLTAwMDAwMTEwLXZjLTAg a2VybmVsOiBbNDE5NDU5OS42ODk1MTddICBbPGZmZmZmZmZmYTA3Nzc4Njc+XSB4ZnNfYm1idF92 ZXJpZnkrMHg3Ny8weDFlMCBbeGZzXQpBdWcgMjIgMjM6MjQ6NDggdnNhLTAwMDAwMTEwLXZjLTAg a2VybmVsOiBbNDE5NDU5OS42ODk1MzVdICBbPGZmZmZmZmZmYTA3Nzc5ZWU+XSA/IHhmc19ibWJ0 X3JlYWRfdmVyaWZ5KzB4ZS8weDEwIFt4ZnNdCkF1ZyAyMiAyMzoyNDo0OCB2c2EtMDAwMDAxMTAt dmMtMCBrZXJuZWw6IFs0MTk0NTk5LjY4OTU0OF0gIFs8ZmZmZmZmZmZhMDc3NzllZT5dIHhmc19i bWJ0X3JlYWRfdmVyaWZ5KzB4ZS8weDEwIFt4ZnNdCkF1ZyAyMiAyMzoyNDo0OCB2c2EtMDAwMDAx MTAtdmMtMCBrZXJuZWw6IFs0MTk0NTk5LjY4OTU1OF0gIFs8ZmZmZmZmZmZhMDc0NDQ4Zj5dIHhm c19idWZfaW9kb25lX3dvcmsrMHgzZi8weGEwIFt4ZnNdCkF1ZyAyMiAyMzoyNDo0OCB2c2EtMDAw MDAxMTAtdmMtMCBrZXJuZWw6IFs0MTk0NTk5LjY4OTU2NF0gIFs8ZmZmZmZmZmY4MTA3OGI4MT5d IHByb2Nlc3Nfb25lX3dvcmsrMHgxNDEvMHg0OTAKQXVnIDIyIDIzOjI0OjQ4IHZzYS0wMDAwMDEx MC12Yy0wIGtlcm5lbDogWzQxOTQ1OTkuNjg5NTY2XSAgWzxmZmZmZmZmZjgxMDc5YjQ4Pl0gd29y a2VyX3RocmVhZCsweDE2OC8weDQwMApBdWcgMjIgMjM6MjQ6NDggdnNhLTAwMDAwMTEwLXZjLTAg a2VybmVsOiBbNDE5NDU5OS42ODk1NjldICBbPGZmZmZmZmZmODEwNzk5ZTA+XSA/IG1hbmFnZV93 b3JrZXJzKzB4MTIwLzB4MTIwCkF1ZyAyMiAyMzoyNDo0OCB2c2EtMDAwMDAxMTAtdmMtMCBrZXJu ZWw6IFs0MTk0NTk5LjY4OTU3MV0gIFs8ZmZmZmZmZmY4MTA3ZjA1MD5dIGt0aHJlYWQrMHhjMC8w eGQwCkF1ZyAyMiAyMzoyNDo0OCB2c2EtMDAwMDAxMTAtdmMtMCBrZXJuZWw6IFs0MTk0NTk5LjY4 OTU3NF0gIFs8ZmZmZmZmZmY4MTA3ZWY5MD5dID8gZmx1c2hfa3RocmVhZF93b3JrZXIrMHhiMC8w eGIwCkF1ZyAyMiAyMzoyNDo0OCB2c2EtMDAwMDAxMTAtdmMtMCBrZXJuZWw6IFs0MTk0NTk5LjY4 OTU3OV0gIFs8ZmZmZmZmZmY4MTZmNjFlYz5dIHJldF9mcm9tX2ZvcmsrMHg3Yy8weGIwCkF1ZyAy MiAyMzoyNDo0OCB2c2EtMDAwMDAxMTAtdmMtMCBrZXJuZWw6IFs0MTk0NTk5LjY4OTU4Ml0gIFs8 ZmZmZmZmZmY4MTA3ZWY5MD5dID8gZmx1c2hfa3RocmVhZF93b3JrZXIrMHhiMC8weGIwCkF1ZyAy MiAyMzoyNDo0OCB2c2EtMDAwMDAxMTAtdmMtMCBrZXJuZWw6IFs0MTk0NTk5LjY4OTU4NF0gWEZT IChkbS04Mik6IENvcnJ1cHRpb24gZGV0ZWN0ZWQuIFVubW91bnQgYW5kIHJ1biB4ZnNfcmVwYWly CkF1ZyAyMiAyMzoyNDo0OCB2c2EtMDAwMDAxMTAtdmMtMCBrZXJuZWw6IFs0MTk0NTk5LjY5MDUw OF0gWEZTIChkbS04Mik6IG1ldGFkYXRhIEkvTyBlcnJvcjogYmxvY2sgMHg1MGZmYjUwICgieGZz X3RyYW5zX3JlYWRfYnVmX21hcCIpIGVycm9yIDExNyBudW1ibGtzIDg= --f46d04388e0d343012051ed5d1ea-- From sandeen@sandeen.net Thu Sep 3 08:22:31 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 958837F73 for ; Thu, 3 Sep 2015 08:22:31 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 1618AAC001 for ; Thu, 3 Sep 2015 06:22:27 -0700 (PDT) X-ASG-Debug-ID: 1441286544-04cb6c0e0c59e20001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id Y9eB4pi9T1Ub3rAM for ; Thu, 03 Sep 2015 06:22:24 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 3D98E65AFC84; Thu, 3 Sep 2015 08:22:24 -0500 (CDT) Subject: Re: xfs corruption To: Danny Shavit , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs corruption References: Cc: Alex Lyakas From: Eric Sandeen X-Enigmail-Draft-Status: N1110 Message-ID: <55E8498F.8090508@sandeen.net> Date: Thu, 3 Sep 2015 08:22:23 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441286544 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22190 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/3/15 6:09 AM, Danny Shavit wrote: > Hi Dave, > > We couple of more xfs corruption that we would like to share: On the same box as the one that seemed to be experiencing some bit-flips in your earlier email? As a general note: You are not providing enough information for us to effectively help you. http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F Kernel version? xfsprogs version? At a bare minimum... Your dmesg snippets are edited. You've provided what you feel is important, omitting the parts that may actually be important or informational. You haven't described the sequence of events that led to these issues. You haven't made clear what these attachments are; which repair log goes with which kernel event? Etc... > 1. This is an interesting one, since xfs reported corruption but when > running xfs_repair, no error was found. Attached is the kernel log > section regarding the corruption (6458). Does xfs_repair explicitly > read data from the disk? In such case it might be a memory > corruption. Are you familiar with such cases? Yes, xfs_repair opens the block device O_DIRECT. your 6485-kernel.log shows a failure in xfs_allocbt_verify(), right after the allocation btree is read from disk. i.e. this is an in-kernel metadata consistency check that is failing. It also shows: kworker/0:1H Tainted: GF W So it's tainted: 2: 'F' if any module was force loaded by "insmod -f", ' ' if all modules were loaded normally. 10: 'W' if a warning has previously been issued by the kernel. (Though some warnings may set more specific taint flags.) You force-loaded a module? And previous warnings were emitted (though we can't see them in your edited dmesg). All bets are off. If you had included the full dmesg, we might know more about what's going on, at least. > 2. xfs corruption occurred suddenly with no apparent external event. > Attached are xfs_repair and kernel logs are. Xfs dump can be found > in: https://zadarastorage-public.s3.amazonaws.com/xfs/82.metadump.gz Your 6442-82-xfs_repair.log is from an xfs_repair -L, so of course it is finding corruption, and the output is more or less meaningless from a triage POV. Repair said: > Note that destroying the log may cause corruption -- please attempt a mount > of the filesystem before doing this. Why did you run it with -L? Did mount fail? If so how? dm-82-kernel.log also shows a failing verifier, this time xfs_bmbt_verify, when reading metadata from disk. You've truncated other parts, though: Aug 22 23:24:48 vsa-00000110-vc-0 kernel: [4194599.685353] ffff88010ec36000: ea bb 12 3a 5f 44 01 a8 b9 2a 80 10 b3 a7 d5 af ...:_D...* ...... so there's not a ton to go on, just hints that there is more information that's not provided. -Eric From sandeen@sandeen.net Thu Sep 3 08:33:57 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 8081C7F77 for ; Thu, 3 Sep 2015 08:33:57 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 629FE304048 for ; Thu, 3 Sep 2015 06:33:54 -0700 (PDT) X-ASG-Debug-ID: 1441287232-04cb6c0e0e5a390001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id qo4MLYAZLwycJkQL for ; Thu, 03 Sep 2015 06:33:52 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id B017E65AFC84; Thu, 3 Sep 2015 08:33:52 -0500 (CDT) Subject: Re: XFS and nobarriers on Intel SSD To: Richard Bade , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and nobarriers on Intel SSD References: From: Eric Sandeen X-Enigmail-Draft-Status: N1110 Message-ID: <55E84C40.8020602@sandeen.net> Date: Thu, 3 Sep 2015 08:33:52 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441287232 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22190 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/2/15 9:24 PM, Richard Bade wrote: > Hi Everyone, I have a question about nobarriers. In the XFS FAQ it > looks like the recommendation is that if you have a Battery Backed > raid controller you should set nobarriers for performance reasons. > Our LSI card doesn’t have battery backed cache as it’s configured in > HBA mode (IT) rather than Raid (IR). Our Intel s3710 SSD’s do have a > capacitor backed cache though. So is it recommended that barriers are > turned off as the drive has a safe cache (I am confident that the > cache will write out to disk on power failure)? If you have a device which guarantees that every acknowledged write will persist even if power is lost, then you can safely turn off barriers. > The reason I am asking about this is that we are seeing some > significant I/O delays on the disks causing a “SCSI Task Abort” from > the OS. This seems to be triggered by the drive receiving a > “Synchronize cache command”. My current thinking is that setting no > barriers will stop the drive receiving a sync command and therefore > stop the I/O delay associated with it. Interesting, I thought that usually devices with battery-backed cache will just ignore synchronize cache commands. But if not, then sure, maybe that's the issue. -Eric > This is happening on our Ceph storage cluster. For those not familiar > with Ceph, it uses XFS as the underlying filesystem for the object > stores. > > Has anyone else encountered this issue? Any info or suggestions about > this would be appreciated. > > Regards, Richard > > > > _______________________________________________ xfs mailing list > xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs > From sandeen@sandeen.net Thu Sep 3 08:43:18 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 00B8D7F7B for ; Thu, 3 Sep 2015 08:43:17 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id D373A30404E for ; Thu, 3 Sep 2015 06:43:17 -0700 (PDT) X-ASG-Debug-ID: 1441287796-04cb6c0e0f5a810001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id sX0ZD4dFh5crtqiv for ; Thu, 03 Sep 2015 06:43:16 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 674C065AFC84; Thu, 3 Sep 2015 08:43:16 -0500 (CDT) Subject: Re: XFS and nobarriers on Intel SSD To: Richard Bade , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and nobarriers on Intel SSD References: <55E84C40.8020602@sandeen.net> From: Eric Sandeen Message-ID: <55E84E74.9050404@sandeen.net> Date: Thu, 3 Sep 2015 08:43:16 -0500 MIME-Version: 1.0 In-Reply-To: <55E84C40.8020602@sandeen.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441287796 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22190 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/3/15 8:33 AM, Eric Sandeen wrote: > On 9/2/15 9:24 PM, Richard Bade wrote: ... >> The reason I am asking about this is that we are seeing some >> significant I/O delays on the disks causing a “SCSI Task Abort” from >> the OS. This seems to be triggered by the drive receiving a >> “Synchronize cache command”. My current thinking is that setting no >> barriers will stop the drive receiving a sync command and therefore >> stop the I/O delay associated with it. > > Interesting, I thought that usually devices with battery-backed cache > will just ignore synchronize cache commands. Or more precisely, the device should advertise itself in such a way that the commands wouldn't be sent, even if nobarrier wasn't specified... -Eric > But if not, then sure, maybe that's the issue. > > -Eric From sandeen@sandeen.net Thu Sep 3 08:45:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 808107F7B for ; Thu, 3 Sep 2015 08:45:05 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 0C9EEAC007 for ; Thu, 3 Sep 2015 06:45:04 -0700 (PDT) X-ASG-Debug-ID: 1441287903-04cb6c0e0e5a8f0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id r8GVs5ndRvJwPjkd for ; Thu, 03 Sep 2015 06:45:03 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 2070865AFC84; Thu, 3 Sep 2015 08:45:03 -0500 (CDT) Subject: Re: [PATCH] xfs: fix null pointer dereference when mapping is NULL To: Brian Foster , Colin King X-ASG-Orig-Subj: Re: [PATCH] xfs: fix null pointer dereference when mapping is NULL References: <1441274260-10120-1-git-send-email-colin.king@canonical.com> <20150903104537.GA46225@bfoster.bfoster> Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com From: Eric Sandeen Message-ID: <55E84EDE.2080404@sandeen.net> Date: Thu, 3 Sep 2015 08:45:02 -0500 MIME-Version: 1.0 In-Reply-To: <20150903104537.GA46225@bfoster.bfoster> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441287903 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22190 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/3/15 5:45 AM, Brian Foster wrote: > On Thu, Sep 03, 2015 at 10:57:40AM +0100, Colin King wrote: >> From: Colin Ian King >> >> xfs_vm_set_page_dirty checks to see if mapping is NULL however >> before this unlikely check it already dereferenced mapping when >> initializing inode. Move the inode initialization after the mapping >> null check to avoid a potential null pointer dereference. >> >> Fixes: 22e757a49cf0 ("xfs: don't dirty buffers beyond EOF") >> Signed-off-by: Colin Ian King >> --- > > Reviewed-by: Brian Foster Reviewed-by: Eric Sandeen Should probably cc: stable on this one too, the commit it fixes went in at 3.17, and it also cc'd stable. -Eric >> fs/xfs/xfs_aops.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c >> index c77499b..d15ae85 100644 >> --- a/fs/xfs/xfs_aops.c >> +++ b/fs/xfs/xfs_aops.c >> @@ -1935,7 +1935,7 @@ xfs_vm_set_page_dirty( >> struct page *page) >> { >> struct address_space *mapping = page->mapping; >> - struct inode *inode = mapping->host; >> + struct inode *inode; >> loff_t end_offset; >> loff_t offset; >> int newly_dirty; >> @@ -1944,6 +1944,7 @@ xfs_vm_set_page_dirty( >> if (unlikely(!mapping)) >> return !TestSetPageDirty(page); >> >> + inode = mapping->host; >> end_offset = i_size_read(inode); >> offset = page_offset(page); >> >> -- >> 2.5.0 >> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From rjohnston@sgi.com Thu Sep 3 09:07:06 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 09BD17F80 for ; Thu, 3 Sep 2015 09:07:06 -0500 (CDT) Received: from xmail.sgi.com (pv-excas3-dc21.corp.sgi.com [137.38.106.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id DE838304048; Thu, 3 Sep 2015 07:07:02 -0700 (PDT) Received: from [128.162.233.55] (128.162.233.55) by xmail.sgi.com (137.38.106.6) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 3 Sep 2015 09:07:02 -0500 From: Rich Johnston Subject: [PATCH V2] xfsrestore: fix fs uuid order check for incremental restores References: <20150826213133.GB3902@dastard> <55D5FB95.1280108@sgi.com> <20150902132112.GB23587@bfoster.bfoster> To: Brian Foster CC: xfs-oss Message-ID: <55E85407.7010106@sgi.com> Date: Thu, 3 Sep 2015 09:07:03 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150902132112.GB23587@bfoster.bfoster> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [128.162.233.55] Restoring an incremental level 1 dump will fail with the following error if the fs uuid of the most recent level 0 dump in the inventory does not match level 1 dump we are restoring. xfsrestore: ERROR: selected dump not based on previously applied dump To: BCC: Rich Johnston This can happen when you have multiple filesystems and you are restoring a level 1 or greater dump of filesystem FS1 but the most recent level 0 dump in the inventory was filesystem FS2 The fix is to ensure the fs uuid of the inventory entry and the dump to be restored match. Signed-off-by: Rich Johnston --- dump/content.c | 8 ++- inventory/inv_api.c | 108 ++++++++++++++++++++++++++++++-------------------- inventory/inv_mgr.c | 48 +++++++++++++++------- inventory/inv_priv.h | 7 +-- inventory/inventory.h | 5 ++ restore/content.c | 17 +++++-- 6 files changed, 124 insertions(+), 69 deletions(-) Index: b/dump/content.c =================================================================== --- a/dump/content.c +++ b/dump/content.c @@ -872,7 +872,7 @@ content_init( intgen_t argc, sameinterruptedpr = BOOL_FALSE; interruptedpr = BOOL_FALSE; - ok = inv_get_session_byuuid( &baseuuid, &sessp ); + ok = inv_get_session_byuuid( &fsid, &baseuuid, &sessp ); if ( ! ok ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "could not find specified base dump (%s) " @@ -983,7 +983,8 @@ content_init( intgen_t argc, "online inventory not available\n") ); return BOOL_FALSE; } - ok = inv_lastsession_level_lessthan( inv_idbt, + ok = inv_lastsession_level_lessthan( &fsid, + inv_idbt, ( u_char_t )sc_level, &sessp ); if ( ! ok ) { @@ -1022,7 +1023,8 @@ content_init( intgen_t argc, if ( inv_idbt != INV_TOKEN_NULL ) { /* REFERENCED */ bool_t ok1; - ok = inv_lastsession_level_equalto( inv_idbt, + ok = inv_lastsession_level_equalto( &fsid, + inv_idbt, ( u_char_t )sc_level, &sessp ); ok1 = inv_close( inv_idbt ); Index: b/inventory/inv_api.c =================================================================== --- a/inventory/inv_api.c +++ b/inventory/inv_api.c @@ -596,69 +596,78 @@ inv_free_session( /*----------------------------------------------------------------------*/ -/* inventory_lasttime_level_lessthan */ -/* */ -/* Given a token that refers to a file system, and a level, this returns*/ -/* the last time when a session of a lesser level was done. */ -/* */ -/* returns -1 on error. */ +/* inv_lasttime_level_lessthan */ +/* */ +/* Given a file system uuid, token that refers to a file system, and a */ +/* level, tm is populated with last time when a session of a lesser */ +/* level was done. */ +/* */ +/* Returns TRUE on success. */ /*----------------------------------------------------------------------*/ bool_t inv_lasttime_level_lessthan( - inv_idbtoken_t tok, - u_char level, - time32_t **tm ) + uuid_t *fsidp, + inv_idbtoken_t tok, + u_char level, + time32_t **tm ) { int rval; if ( tok != INV_TOKEN_NULL ) { - rval = search_invt( tok->d_invindex_fd, &level, (void **) tm, - (search_callback_t) tm_level_lessthan ); + rval = search_invt(fsidp, tok->d_invindex_fd, &level, + (void **) tm, + (search_callback_t) tm_level_lessthan); return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; } - return invmgr_query_all_sessions((void *) &level, /* in */ - (void **) tm, /* out */ + return invmgr_query_all_sessions(fsidp, /* fs uuid ptr*/ + (void *) &level, /* in */ + (void **) tm, /* out */ (search_callback_t) tm_level_lessthan); } - - - - /*----------------------------------------------------------------------*/ -/* */ -/* */ -/* */ +/* inv_lastsession_level_lessthan */ +/* */ +/* Given a file system uuid, token that refers to a file system, and a */ +/* level, ses is populated with a session of lesser than the level */ +/* passed in. */ +/* */ +/* Returns FALSE on an error, TRUE if not. If (*ses) is NULL, then the */ +/* search failed. */ /*----------------------------------------------------------------------*/ bool_t inv_lastsession_level_lessthan( - inv_idbtoken_t tok, + uuid_t *fsidp, + inv_idbtoken_t tok, u_char level, - inv_session_t **ses ) + inv_session_t **ses ) { int rval; if ( tok != INV_TOKEN_NULL ) { - rval = search_invt( tok->d_invindex_fd, &level, (void **) ses, - (search_callback_t) lastsess_level_lessthan ); + rval = search_invt(fsidp, tok->d_invindex_fd, &level, + (void **) ses, + (search_callback_t) lastsess_level_lessthan); return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; } - return invmgr_query_all_sessions((void *) &level, /* in */ + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *) &level, /* in */ (void **) ses, /* out */ (search_callback_t) lastsess_level_lessthan); } - - - /*----------------------------------------------------------------------*/ -/* */ -/* */ +/* inv_lastsession_level_equalto */ +/* */ +/* Given a file system uuid, token that refers to a file system, and a */ +/* level, this populates ses with last time when a session of a lesser */ +/* level was done. */ +/* */ /* Return FALSE on an error, TRUE if not. If (*ses) is NULL, then the */ /* search failed. */ /*----------------------------------------------------------------------*/ @@ -666,19 +675,22 @@ inv_lastsession_level_lessthan( bool_t inv_lastsession_level_equalto( + uuid_t *fsidp, inv_idbtoken_t tok, u_char level, inv_session_t **ses ) { int rval; if ( tok != INV_TOKEN_NULL ) { - rval = search_invt( tok->d_invindex_fd, &level, (void **) ses, - (search_callback_t) lastsess_level_equalto ); + rval = search_invt(fsidp, tok->d_invindex_fd, &level, + (void **) ses, + (search_callback_t) lastsess_level_equalto); return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; } - return invmgr_query_all_sessions((void *) &level, /* in */ + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *) &level, /* in */ (void **) ses, /* out */ (search_callback_t) lastsess_level_equalto); @@ -688,35 +700,45 @@ inv_lastsession_level_equalto( /*----------------------------------------------------------------------*/ /* inv_getsession_byuuid */ /* */ +/* Given a file system uuid and a session uuid , ses is populated with */ +/* the session that contains the matching system uuid. */ +/* */ +/* Returns FALSE on an error, TRUE if the session was found. */ /*----------------------------------------------------------------------*/ bool_t inv_get_session_byuuid( + uuid_t *fsidp, uuid_t *sesid, inv_session_t **ses) { - return (invmgr_query_all_sessions((void *)sesid, /* in */ - (void **) ses, /* out */ - (search_callback_t) stobj_getsession_byuuid)); + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *) sesid, /* in */ + (void **) ses, /* out */ + (search_callback_t) stobj_getsession_byuuid); } - - /*----------------------------------------------------------------------*/ -/* inv_getsession_byuuid */ +/* inv_getsession_bylabel */ /* */ +/* Given a file system uuid and a session uuid, ses is populated with */ +/* the session that contains the matching system label. */ +/* */ +/* Returns FALSE on an error, TRUE if the session was found. */ /*----------------------------------------------------------------------*/ bool_t inv_get_session_bylabel( + uuid_t *fsidp, char *session_label, inv_session_t **ses) { - return (invmgr_query_all_sessions((void *)session_label, /* in */ - (void **) ses, /* out */ - (search_callback_t) stobj_getsession_bylabel)); + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *) session_label, /* in */ + (void **) ses, /* out */ + (search_callback_t) stobj_getsession_bylabel); } @@ -786,7 +808,7 @@ inv_delete_mediaobj( uuid_t *moid ) return BOOL_FALSE; } - if ( search_invt( invfd, NULL, (void **)&moid, + if ( search_invt( &arr[i].ft_uuid, invfd, NULL, (void **)&moid, (search_callback_t) stobj_delete_mobj ) < 0 ) return BOOL_FALSE; Index: b/inventory/inv_mgr.c =================================================================== --- a/inventory/inv_mgr.c +++ b/inventory/inv_mgr.c @@ -134,6 +134,7 @@ get_sesstoken( inv_idbtoken_t tok ) /*---------------------------------------------------------------------------*/ bool_t invmgr_query_all_sessions ( + uuid_t *fsidp, void *inarg, void **outarg, search_callback_t func) @@ -145,6 +146,7 @@ invmgr_query_all_sessions ( int result; inv_oflag_t forwhat = INV_SEARCH_ONLY; void *objectfound; + bool ret = false; /* if on return, this is still null, the search failed */ *outarg = NULL; @@ -153,11 +155,11 @@ invmgr_query_all_sessions ( fd = fstab_getall( &arr, &cnt, &numfs, forwhat ); /* special case missing file: ok, outarg says zero */ if ( fd < 0 && errno == ENOENT ) { - return BOOL_TRUE; + return true; } if ( fd < 0 || numfs <= 0 ) { mlog( MLOG_NORMAL | MLOG_INV, _("INV: Error in fstab\n") ); - return BOOL_FALSE; + return ret; } close( fd ); @@ -169,7 +171,7 @@ invmgr_query_all_sessions ( mlog( MLOG_NORMAL | MLOG_INV, _( "INV: Cant get inv-name for uuid\n") ); - return BOOL_FALSE; + continue; } strcat( fname, INV_INVINDEX_PREFIX ); invfd = open( fname, INV_OFLAG(forwhat) ); @@ -178,26 +180,27 @@ invmgr_query_all_sessions ( "INV: Open failed on %s\n"), fname ); - return BOOL_FALSE; + continue; } - result = search_invt( invfd, inarg, &objectfound, func ); + result = search_invt(fsidp, invfd, inarg, &objectfound, func); close(invfd); /* if error return BOOL_FALSE */ if (result < 0) { - return BOOL_FALSE; + return ret; } else if ((result == 1) && *outarg) { /* multiple entries found, more info needed */ *outarg = NULL; - return BOOL_TRUE; + return true; } else if (result == 1) { *outarg = objectfound; + ret = true; } } /* return val indicates if there was an error or not. *buf says whether the search was successful */ - return BOOL_TRUE; + return ret; } @@ -213,6 +216,7 @@ invmgr_query_all_sessions ( intgen_t search_invt( + uuid_t *fsidp, int invfd, void *arg, void **buf, @@ -247,7 +251,7 @@ search_invt( /* we need to get all the invindex headers and seshdrs in reverse order */ for (i = nindices - 1; i >= 0; i--) { - int nsess; + int nsess, j; invt_sescounter_t *scnt = NULL; invt_seshdr_t *harr = NULL; bool_t found; @@ -272,19 +276,35 @@ search_invt( } free ( scnt ); - while ( nsess ) { + for (j = nsess - 1; j >= 0; j--) { + invt_session_t ses; + /* fd is kept locked until we return from the callback routine */ /* Check to see if this session has been pruned * by xfsinvutil before checking it. */ - if ( harr[nsess - 1].sh_pruned ) { - --nsess; + if (harr[j].sh_pruned) { continue; } - found = (* do_chkcriteria ) ( fd, &harr[ --nsess ], - arg, buf ); + + /* if we need to check the fs uuid's and they don't + * match or we fail to get the session record, + * then keep looking + */ + if (fsidp) { + int ret = GET_REC_NOLOCK(fd, &ses, + sizeof(invt_session_t), + harr[j].sh_sess_off); + if (ret < 0) + return ret; + + if (uuid_compare(ses.s_fsid, *fsidp)) + continue; + } + + found = (* do_chkcriteria ) (fd, &harr[j], arg, buf); if (! found ) continue; /* we found what we need; just return */ Index: b/inventory/inv_priv.h =================================================================== --- a/inventory/inv_priv.h +++ b/inventory/inv_priv.h @@ -548,11 +548,12 @@ get_headerinfo( int fd, void **hdrs, voi size_t hdrsz, size_t cntsz, bool_t doblock ); bool_t -invmgr_query_all_sessions (void *inarg, void **outarg, search_callback_t func); +invmgr_query_all_sessions(uuid_t *fsidp, void *inarg, void **outarg, + search_callback_t func); intgen_t -search_invt( int invfd, void *arg, void **buf, - search_callback_t do_chkcriteria ); +search_invt(uuid_t *fsidp, int invfd, void *arg, void **buf, + search_callback_t do_chkcriteria); intgen_t invmgr_inv_print( int invfd, invt_pr_ctx_t *prctx); Index: b/inventory/inventory.h =================================================================== --- a/inventory/inventory.h +++ b/inventory/inventory.h @@ -247,18 +247,21 @@ inv_put_mediafile( */ extern bool_t inv_lasttime_level_lessthan( + uuid_t *fsidp, inv_idbtoken_t tok, u_char level, time32_t **time );/* out */ extern bool_t inv_lastsession_level_lessthan( + uuid_t *fsidp, inv_idbtoken_t tok, u_char level, inv_session_t **ses );/* out */ extern bool_t inv_lastsession_level_equalto( + uuid_t *fsidp, inv_idbtoken_t tok, u_char level, inv_session_t **ses );/* out */ @@ -266,11 +269,13 @@ inv_lastsession_level_equalto( /* Given a uuid of a session, return the session structure.*/ extern bool_t inv_get_session_byuuid( + uuid_t *fsidp, uuid_t *sesid, inv_session_t **ses); extern bool_t inv_get_session_bylabel( + uuid_t *fsidp, char *session_label, inv_session_t **ses); Index: b/restore/content.c =================================================================== --- a/restore/content.c +++ b/restore/content.c @@ -2179,8 +2179,9 @@ content_stream_restore( ix_t thrdix ) if ( ! drivep->d_isnamedpipepr && ! drivep->d_isunnamedpipepr ) { - ok = inv_get_session_byuuid( &grhdrp->gh_dumpid, - &sessp ); + ok = inv_get_session_byuuid(NULL, + &grhdrp->gh_dumpid, + &sessp); if ( ok && sessp ) { mlog( MLOG_VERBOSE, _( "using online session inventory\n") ); @@ -3736,9 +3737,11 @@ Inv_validate_cmdline( void ) ok = BOOL_FALSE; sessp = 0; if ( tranp->t_reqdumpidvalpr ) { - ok = inv_get_session_byuuid( &tranp->t_reqdumpid, &sessp ); + ok = inv_get_session_byuuid(NULL, &tranp->t_reqdumpid, + &sessp ); } else if ( tranp->t_reqdumplabvalpr ) { - ok = inv_get_session_bylabel( tranp->t_reqdumplab, &sessp ); + ok = inv_get_session_bylabel(NULL, tranp->t_reqdumplab, + &sessp ); } rok = BOOL_FALSE; if ( ok && sessp ) { @@ -6812,11 +6815,13 @@ askinvforbaseof( uuid_t baseid, inv_sess /* get the base session */ if ( resumedpr ) { - ok = inv_lastsession_level_equalto( invtok, + ok = inv_lastsession_level_equalto( &sessp->s_fsid, + invtok, ( u_char_t )level, &basesessp ); } else { - ok = inv_lastsession_level_lessthan( invtok, + ok = inv_lastsession_level_lessthan( &sessp->s_fsid, + invtok, ( u_char_t )level, &basesessp ); } From rjohnston@sgi.com Thu Sep 3 09:23:30 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 721287F85 for ; Thu, 3 Sep 2015 09:23:30 -0500 (CDT) Received: from xmail.sgi.com (pv-excas3-dc21.corp.sgi.com [137.38.106.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 428478F8065; Thu, 3 Sep 2015 07:23:27 -0700 (PDT) Received: from [128.162.233.55] (128.162.233.55) by xmail.sgi.com (137.38.106.6) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 3 Sep 2015 09:23:26 -0500 Subject: Re: [PATCH V2] xfsrestore: fix fs uuid order check for incremental restores To: Brian Foster References: <20150826213133.GB3902@dastard> <55D5FB95.1280108@sgi.com> <20150902132112.GB23587@bfoster.bfoster> <55E85407.7010106@sgi.com> CC: xfs-oss From: Rich Johnston Message-ID: <55E857E0.3010604@sgi.com> Date: Thu, 3 Sep 2015 09:23:28 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E85407.7010106@sgi.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [128.162.233.55] Please disregard, not what I meat to send. --Rich From danny@zadarastorage.com Thu Sep 3 09:26:30 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 68DC37F88 for ; Thu, 3 Sep 2015 09:26:30 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 5672E304032 for ; Thu, 3 Sep 2015 07:26:30 -0700 (PDT) X-ASG-Debug-ID: 1441290386-04cb6c0e0d5bab0001-NocioJ Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by cuda.sgi.com with ESMTP id olcA5aJtkvkp3R3E (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 03 Sep 2015 07:26:26 -0700 (PDT) X-Barracuda-Envelope-From: danny@zadarastorage.com X-Barracuda-Apparent-Source-IP: 209.85.212.179 Received: by wicfx3 with SMTP id fx3so21897702wic.1 for ; Thu, 03 Sep 2015 07:26:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ATgBFIwy1w/gtD40xuHj+IxbYsuVDWCxpI4zqMT4S4M=; b=jkwDOIsB7a0sYJur1BZHwBFGgA2frCv+4Axuxbrb0GoW2LEASbfOuPMlXdWYS6TKqi 4clzQ2xVDATC5qfWchN/IjZwe9bF+i7f5tKrKVw8nJSPSkEue50TlJ++ealmw6+VxSvn qJpUJqVn7TymcQo0qcYQwNVNKuj5apvLySF3Yg1JGgb5X6FZ5LVpE1sTl+cEy9nR+sjr sw5wWR95ePRPzFAg310LexexOTRWDAus1JlgMDxbYJL6fpt62tB5BDJmJdFtWGBURsue LK7Bf8nz7nKBitUQBDZ3OGuhHAaJgdzUyUtdh0KWfQTSH4an1k2glTBCQp6qFuAgDpve cYNg== X-Gm-Message-State: ALoCoQljrGALV64+FoWwU0FG+TcCuay82IT0WQw+PDfiPWxgYigbmH5HOJYbZLSqF2+aYBl9v5hb MIME-Version: 1.0 X-Received: by 10.180.75.137 with SMTP id c9mr15125077wiw.16.1441290385825; Thu, 03 Sep 2015 07:26:25 -0700 (PDT) Received: by 10.28.93.134 with HTTP; Thu, 3 Sep 2015 07:26:25 -0700 (PDT) In-Reply-To: <55E8498F.8090508@sandeen.net> References: <55E8498F.8090508@sandeen.net> Date: Thu, 3 Sep 2015 17:26:25 +0300 Message-ID: Subject: Re: xfs corruption From: Danny Shavit X-ASG-Orig-Subj: Re: xfs corruption To: Eric Sandeen Cc: xfs@oss.sgi.com, Alex Lyakas Content-Type: multipart/alternative; boundary=f46d04388e0d773c3f051ed891fa X-Barracuda-Connect: mail-wi0-f179.google.com[209.85.212.179] X-Barracuda-Start-Time: 1441290386 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22191 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --f46d04388e0d773c3f051ed891fa Content-Type: text/plain; charset=UTF-8 Hi Eric, Thanks for the prompt response. Sorry for the missing parts, I was wrongly assuming that everybody knows our environment :-) More information: uname -a: Linux vsa-00000142 3.8.13-030813-generic #201305111843 SMP Sat May 11 22:44:40 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux xfs_repair version 3.1.7 We are using modified xfs. Mainly, added some reporting features and changed discard operation to be aligned with chunk sizes used in our systems. The modified code resides at https://github.com/zadarastora ge/zadara-xfs-pushback . We were in a hurry at the time we run xfs_repair with -L. Was not so smart... Any way, the xfs_dump was taken before running xfs_repair. We will use the original xfs meta data to run xfs_repair after mount and get back with the results. Regards, Danny On Thu, Sep 3, 2015 at 4:22 PM, Eric Sandeen wrote: > On 9/3/15 6:09 AM, Danny Shavit wrote: > > Hi Dave, > > > > We couple of more xfs corruption that we would like to share: > > On the same box as the one that seemed to be experiencing some > bit-flips in your earlier email? > > As a general note: You are not providing enough information for > us to effectively help you. > > > http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F > > Kernel version? xfsprogs version? At a bare minimum... > > Your dmesg snippets are edited. You've provided what you feel is > important, omitting the parts that may actually be important or > informational. > > You haven't described the sequence of events that led to these issues. > > You haven't made clear what these attachments are; which repair log goes > with which kernel event? > > Etc... > > > 1. This is an interesting one, since xfs reported corruption but when > > running xfs_repair, no error was found. Attached is the kernel log > > section regarding the corruption (6458). Does xfs_repair explicitly > > read data from the disk? In such case it might be a memory > > corruption. Are you familiar with such cases? > > Yes, xfs_repair opens the block device O_DIRECT. > > your 6485-kernel.log shows a failure in xfs_allocbt_verify(), right > after the allocation btree is read from disk. i.e. this is an in-kernel > metadata consistency check that is failing. > > It also shows: > > kworker/0:1H Tainted: GF W > > So it's tainted: > > 2: 'F' if any module was force loaded by "insmod -f", ' ' if all > modules were loaded normally. > > 10: 'W' if a warning has previously been issued by the kernel. > (Though some warnings may set more specific taint flags.) > > You force-loaded a module? And previous warnings were emitted (though we > can't see them in your edited dmesg). > All bets are off. If you had included the full dmesg, we might know > more about what's going on, at least. > > > 2. xfs corruption occurred suddenly with no apparent external event. > > Attached are xfs_repair and kernel logs are. Xfs dump can be found > > in: https://zadarastorage-public.s3.amazonaws.com/xfs/82.metadump.gz > > Your 6442-82-xfs_repair.log is from an xfs_repair -L, so of course it > is finding corruption, and the output is more or less meaningless > from a triage POV. Repair said: > > > Note that destroying the log may cause corruption -- please attempt a > mount > > of the filesystem before doing this. > > Why did you run it with -L? Did mount fail? If so how? > > dm-82-kernel.log also shows a failing verifier, this time xfs_bmbt_verify, > when reading metadata from disk. > > You've truncated other parts, though: > > Aug 22 23:24:48 vsa-00000110-vc-0 kernel: [4194599.685353] > ffff88010ec36000: ea bb 12 3a 5f 44 01 a8 b9 2a 80 10 b3 a7 d5 af > ...:_D...* > ...... > > so there's not a ton to go on, just hints that there is more information > that's not provided. > > > -Eric > -- Regards, Danny --f46d04388e0d773c3f051ed891fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Eric,

Thanks for the prompt response= .
Sorry for the missing parts, I was wrongly assuming that everyb= ody knows our environment :-)

More information:
uname -a: =C2=A0Linux vsa-00000142 3.8.13-030813-generic #= 201305111843 SMP Sat May 11 22:44:40 UTC 2013 x86_64 x86_64 x86_64 GNU/Linu= x
xfs_repair version 3.1.7

We are using modified xfs. Mainly, added some reporting features and chan= ged discard operation to be aligned with chunk sizes used in our systems.
The modified code resides at=C2=A0=C2=A0https://github.com/zadarastorage/zadara-xfs-pushback.

We were i= n a hurry at the time we run xfs_repair with -L. Was not so smart...
<= div>Any way, the xfs_dump was taken before running xfs_repair.
We= will use the original xfs meta data to run xfs_repair after mount and get = back with the results.

Regards,
Danny




On Thu, Sep 3, 2015 at 4:22 PM, Eric S= andeen <sandeen@sandeen.net> wrote:
On 9/3/15 6:09 AM, Danny Shavit wrote:
> Hi Dave,
>
> We couple of more xfs corruption that we would like to share:

On the same box as the one that seemed to be experiencing some
bit-flips in your earlier email?

As a general note: You are not providing enough information for
us to effectively help you.

htt= p://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_rep= orting_a_problem.3F

Kernel version?=C2=A0 xfsprogs version?=C2=A0 At a bare minimum...

Your dmesg snippets are edited.=C2=A0 You've provided what you feel is<= br> important, omitting the parts that may actually be important or
informational.

You haven't described the sequence of events that led to these issues.<= br>
You haven't made clear what these attachments are; which repair log goe= s
with which kernel event?

Etc...

> 1. This is an interesting one, since xfs reported corruption but when<= br> > running xfs_repair, no error was found. Attached is the kernel log
> section regarding the corruption (6458). Does xfs_repair explicitly > read data from the disk? In such case it might be a memory
> corruption. Are you familiar with such cases?

Yes, xfs_repair opens the block device O_DIRECT.

your 6485-kernel.log shows a failure in xfs_allocbt_verify(), right
after the allocation btree is read from disk.=C2=A0 i.e. this is an in-kern= el
metadata consistency check that is failing.

It also shows:

kworker/0:1H Tainted: GF=C2=A0 =C2=A0 =C2=A0 =C2=A0W

So it's tainted:

=C2=A0 2: 'F' if any module was force loaded by "insmod -f&quo= t;, ' ' if all
=C2=A0 =C2=A0 =C2=A0modules were loaded normally.

=C2=A010: 'W' if a warning has previously been issued by the kernel= .
=C2=A0 =C2=A0 =C2=A0(Though some warnings may set more specific taint flags= .)

You force-loaded a module?=C2=A0 And previous warnings were emitted (though= we
can't see them in your edited dmesg).
All bets are off.=C2=A0 If you had included the full dmesg, we might know more about what's going on, at least.

> 2. xfs corruption occurred suddenly with no apparent external event. >=C2=A0 Attached are xfs_repair and kernel logs are. Xfs dump can be fou= nd
> in: https://zadarastorage-publi= c.s3.amazonaws.com/xfs/82.metadump.gz

Your 6442-82-xfs_repair.log is from an xfs_repair -L, so of course i= t
is finding corruption, and the output is more or less meaningless
from a triage POV.=C2=A0 Repair said:

> Note that destroying the log may cause corruption -- please attempt a = mount
> of the filesystem before doing this.

Why did you run it with -L? Did mount fail? If so how?

dm-82-kernel.log also shows a failing verifier, this time xfs_bmbt_verify,<= br> when reading metadata from disk.

You've truncated other parts, though:

Aug 22 23:24:48 vsa-00000110-vc-0 kernel: [4194599.685353] ffff88010ec36000= : ea bb 12 3a 5f 44 01 a8 b9 2a 80 10 b3 a7 d5 af=C2=A0 ...:_D...*
......

so there's not a ton to go on, just hints that there is more informatio= n
that's not provided.


-Eric



--
Regards,
Da= nny
--f46d04388e0d773c3f051ed891fa-- From sandeen@sandeen.net Thu Sep 3 09:55:30 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id A76757F89 for ; Thu, 3 Sep 2015 09:55:30 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 67D4A304032 for ; Thu, 3 Sep 2015 07:55:29 -0700 (PDT) X-ASG-Debug-ID: 1441292128-04bdf06dd664730001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id rsVH3hVGckOMrzok for ; Thu, 03 Sep 2015 07:55:28 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id DFAD3654C8DF; Thu, 3 Sep 2015 09:55:27 -0500 (CDT) Subject: Re: xfs corruption To: Danny Shavit X-ASG-Orig-Subj: Re: xfs corruption References: <55E8498F.8090508@sandeen.net> Cc: Alex Lyakas , xfs@oss.sgi.com From: Eric Sandeen X-Enigmail-Draft-Status: N1110 Message-ID: <55E85F5F.6010005@sandeen.net> Date: Thu, 3 Sep 2015 09:55:27 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441292128 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22191 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/3/15 9:26 AM, Danny Shavit wrote: > Hi Eric, > > Thanks for the prompt response. Sorry for the missing parts, I was > wrongly assuming that everybody knows our environment :-) Maybe some do, but my brain is too small for that. ;) > More information: uname -a: Linux vsa-00000142 3.8.13-030813-generic > #201305111843 SMP Sat May 11 22:44:40 UTC 2013 x86_64 x86_64 x86_64 > GNU/Linux xfs_repair version 3.1.7 > > We are using modified xfs. Mainly, added some reporting features and > changed discard operation to be aligned with chunk sizes used in our > systems. The modified code resides at https://github.com/zadarastora > ge/zadara-xfs-pushback > . Interesting, thanks for the pointer. I guess at this point I have to ask, do you see these same problems without your modifications? I'd really encourage Zadara to work on submitting some of these upstream, if they are of general interest. It'll get more review, more testing, and will reduce your maintenance burden. Obviously some of it may not be desired upstream, but if you've solved a general problem, it'd be very good to propose a patch for inclusion. > We were in a hurry at the time we run xfs_repair with -L. Was not so > smart... Any way, the xfs_dump was taken before running xfs_repair. > We will use the original xfs meta data to run xfs_repair after mount > and get back with the results. Ok, from the metadump I see that log replay fails due to the corruption: [ 7708.169145] XFS (loop0): Mounting V4 Filesystem [ 7708.178379] XFS (loop0): Starting recovery (logdev: internal) [ 7708.185369] XFS (loop0): Metadata corruption detected at xfs_bmbt_read_verify+0x7e/0xc0 [xfs], block 0x50ffb50 [ 7708.195344] XFS (loop0): Unmount and run xfs_repair [ 7708.200214] XFS (loop0): First 64 bytes of corrupted metadata buffer: [ 7708.206638] ffff8802e5b9d000: ea bb 12 3a 5f 44 01 a8 b9 2a 80 10 b3 a7 d5 af ...:_D...*...... [ 7708.215312] ffff8802e5b9d010: f6 b0 39 2d 08 54 7a ec 37 1b 94 b0 c2 37 23 1f ..9-.Tz.7....7#. [ 7708.223986] ffff8802e5b9d020: 54 62 b5 fd ff 63 95 01 4b 23 fc 5d 8b d4 7b 78 Tb...c..K#.]..{x [ 7708.232662] ffff8802e5b9d030: 94 e6 fa cc e2 87 3d fe ab df b8 e9 e5 9b e5 da ......=......... [ 7708.241341] XFS (loop0): metadata I/O error: block 0x50ffb50 ("xfs_trans_read_buf_map") error 117 numblks 8 [ 7708.251058] XFS (loop0): xfs_do_force_shutdown(0x1) called from line 315 of file fs/xfs/xfs_trans_buf.c. Return address = 0xffffffffa036c41a [ 7708.263721] XFS (loop0): I/O Error Detected. Shutting down filesystem [ 7708.270144] XFS (loop0): Please umount the filesystem and rectify the problem(s) [ 7708.277533] XFS (loop0): Ending recovery (logdev: internal) [ 7708.283095] SELinux: (dev loop0, type xfs) getxattr errno 5 [ 7708.288664] XFS (loop0): xfs_log_force: error -5 returned. [ 7708.294136] XFS (loop0): Unmounting Filesystem From sandeen@sandeen.net Thu Sep 3 11:14:45 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id AE0837F8B for ; Thu, 3 Sep 2015 11:14:45 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 801728F8052 for ; Thu, 3 Sep 2015 09:14:41 -0700 (PDT) X-ASG-Debug-ID: 1441296880-04bdf06dd9674a0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id LHjzHjph6D5Tujes for ; Thu, 03 Sep 2015 09:14:40 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id B1655654C8DF; Thu, 3 Sep 2015 11:14:39 -0500 (CDT) Subject: Re: xfs corruption To: Danny Shavit X-ASG-Orig-Subj: Re: xfs corruption References: <55E8498F.8090508@sandeen.net> <55E85F5F.6010005@sandeen.net> Cc: Alex Lyakas , xfs@oss.sgi.com From: Eric Sandeen Message-ID: <55E871EF.4040603@sandeen.net> Date: Thu, 3 Sep 2015 11:14:39 -0500 MIME-Version: 1.0 In-Reply-To: <55E85F5F.6010005@sandeen.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441296880 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22192 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/3/15 9:55 AM, Eric Sandeen wrote: > On 9/3/15 9:26 AM, Danny Shavit wrote: ... >> We are using modified xfs. Mainly, added some reporting features and >> changed discard operation to be aligned with chunk sizes used in our >> systems. The modified code resides at https://github.com/zadarastora >> ge/zadara-xfs-pushback >> . > > Interesting, thanks for the pointer. I guess at this point I have to > ask, do you see these same problems without your modifications? Have you ever mounted this filesystem on non-zadara kernels? looking at https://github.com/zadarastorage/zadara-xfs-pushback/commit/094df949fd080ede546bb7518405ab873a444823 you've changed the disk format w/o adding a feature flag, which is pretty dangerous. -Eric From billodo@redhat.com Thu Sep 3 11:38:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 4774929DF5 for ; Thu, 3 Sep 2015 11:38:40 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 265908F8059 for ; Thu, 3 Sep 2015 09:38:40 -0700 (PDT) X-ASG-Debug-ID: 1441298318-04bdf06dd867dd0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 2CTUlIeHFwCgIzix (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 09:38:39 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id C7E38C0AAB02 for ; Thu, 3 Sep 2015 16:38:38 +0000 (UTC) Received: from localhost.localdomain.com (unused [10.10.50.102] (may be forged)) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83GccRf013867 for ; Thu, 3 Sep 2015 12:38:38 -0400 From: billodo To: xfs@oss.sgi.com Subject: [PATCH 0/3] xfs: new global stats in sysfs Date: Thu, 3 Sep 2015 11:36:24 -0500 X-ASG-Orig-Subj: [PATCH 0/3] xfs: new global stats in sysfs Message-Id: <1441298187-29064-1-git-send-email-billodo@redhat.com> 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: 1441298318 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi all- Here is a first pass at a series to add new global stats to sysfs. As a part of that, the /proc/fs/xfs/stat file becomes a symlink to the sysfs stats entry. The patch provides the beginnings of the infrastructure for per-fs stats (in addition to global accumulative stats). Patch 1 handles the bring-up and tear down of xfs/stats directory structure in sysfs when an fs is mounted. The directory contains the stats file and the stats_clear file. The stats file contents mimic those of /proc/fs/xfs/stat. The stats_clear file is empty, and much like the current stat_clear command, handles the zeroing of the stats file when a "1" is echoed to the stats_clear file. Patch 2 creates the symlink for stats from procfs to sysfs. Patch 3 removes the now unused portions of procfs for stat. Comments and questions are welcome. Thanks- Bill From billodo@redhat.com Thu Sep 3 11:38:41 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 2A52A29DF5 for ; Thu, 3 Sep 2015 11:38:41 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id B372AAC008 for ; Thu, 3 Sep 2015 09:38:40 -0700 (PDT) X-ASG-Debug-ID: 1441298319-04bdf06dd667dd0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id JVrlQhsGNobmfOX3 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 09:38:39 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 5BAD48EA4A for ; Thu, 3 Sep 2015 16:38:39 +0000 (UTC) Received: from localhost.localdomain.com (unused [10.10.50.102] (may be forged)) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83GccRg013867 for ; Thu, 3 Sep 2015 12:38:38 -0400 From: billodo To: xfs@oss.sgi.com Subject: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs Date: Thu, 3 Sep 2015 11:36:25 -0500 X-ASG-Orig-Subj: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs Message-Id: <1441298187-29064-2-git-send-email-billodo@redhat.com> In-Reply-To: <1441298187-29064-1-git-send-email-billodo@redhat.com> References: <1441298187-29064-1-git-send-email-billodo@redhat.com> 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: 1441298319 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Currently, xfs global stats are in procfs. This patch introduces (replicates) the global stats in sysfs. Additionally a stats_clear file is introduced in sysfs. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_stats.h | 2 ++ fs/xfs/xfs_super.c | 17 ++++++++--- fs/xfs/xfs_sysfs.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_sysfs.h | 1 + 5 files changed, 177 insertions(+), 4 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index f224038..856cf57 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -29,6 +29,89 @@ static int counter_val(int idx) return val; } +int xfs_stats_format(char *buf) +{ + int i, j; + int len = 0; + __uint64_t xs_xstrat_bytes = 0; + __uint64_t xs_write_bytes = 0; + __uint64_t xs_read_bytes = 0; + + static const struct xstats_entry { + char *desc; + int endpoint; + } xstats[] = { + { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, + { "abt", XFSSTAT_END_ALLOC_BTREE }, + { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, + { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, + { "dir", XFSSTAT_END_DIRECTORY_OPS }, + { "trans", XFSSTAT_END_TRANSACTIONS }, + { "ig", XFSSTAT_END_INODE_OPS }, + { "log", XFSSTAT_END_LOG_OPS }, + { "push_ail", XFSSTAT_END_TAIL_PUSHING }, + { "xstrat", XFSSTAT_END_WRITE_CONVERT }, + { "rw", XFSSTAT_END_READ_WRITE_OPS }, + { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, + { "icluster", XFSSTAT_END_INODE_CLUSTER }, + { "vnodes", XFSSTAT_END_VNODE_OPS }, + { "buf", XFSSTAT_END_BUF }, + { "abtb2", XFSSTAT_END_ABTB_V2 }, + { "abtc2", XFSSTAT_END_ABTC_V2 }, + { "bmbt2", XFSSTAT_END_BMBT_V2 }, + { "ibt2", XFSSTAT_END_IBT_V2 }, + { "fibt2", XFSSTAT_END_FIBT_V2 }, + /* we print both series of quota information together */ + { "qm", XFSSTAT_END_QM }, + }; + + /* Loop over all stats groups */ + + for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { + len += snprintf(buf + len, PATH_MAX - len, "%s", xstats[i].desc); + /* inner loop does each group */ + for (; j < xstats[i].endpoint; j++) + len += snprintf(buf + len, PATH_MAX - len, " %u", counter_val(j)); + len += snprintf(buf + len, PATH_MAX - len, "\n"); + } + /* extra precision counters */ + for_each_possible_cpu(i) { + xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; + xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; + xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; + } + + len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", + xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); + len += snprintf(buf+len, PATH_MAX-len, "debug %u\n", +#if defined(DEBUG) + 1); +#else + 0); +#endif + +return len; +} + +int xfs_stats_clearall(const char *buf) +{ + int c, n; + __uint32_t vn_active; + + n = sizeof(struct xfsstats); + xfs_notice(NULL, "Clearing xfsstats"); + for_each_possible_cpu(c) { + preempt_disable(); + /* save vn_active, it's a universal truth! */ + vn_active = per_cpu(xfsstats, c).vn_active; + memset(&per_cpu(xfsstats, c), 0, + sizeof(struct xfsstats)); + per_cpu(xfsstats, c).vn_active = vn_active; + preempt_enable(); + } + return n; +} + static int xfs_stat_proc_show(struct seq_file *m, void *v) { int i, j; diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index c8f238b..c117afc 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -18,6 +18,8 @@ #ifndef __XFS_STATS_H__ #define __XFS_STATS_H__ +int xfs_stats_format(char *buf); +int xfs_stats_clearall(const char *buf); #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 3bf503a..9a794cf 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -61,6 +61,7 @@ static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; static struct kset *xfs_kset; /* top-level xfs sysfs dir */ +static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ #ifdef DEBUG static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ #endif @@ -1838,15 +1839,20 @@ init_xfs_fs(void) xfs_kset = kset_create_and_add("xfs", NULL, fs_kobj); if (!xfs_kset) { error = -ENOMEM; - goto out_sysctl_unregister;; + goto out_sysctl_unregister; } + xfs_stats_kobj.kobject.kset = xfs_kset; + error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, "stats"); + if (error) + goto out_kset_unregister; + #ifdef DEBUG xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); - if (error) - goto out_kset_unregister; #endif + if (error) + goto out_remove_stats_kobj; error = xfs_qm_init(); if (error) @@ -1862,8 +1868,10 @@ init_xfs_fs(void) out_remove_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_kset_unregister: #endif + out_remove_stats_kobj: + xfs_sysfs_del(&xfs_stats_kobj); + out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: xfs_sysctl_unregister(); @@ -1889,6 +1897,7 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif + xfs_sysfs_del(&xfs_stats_kobj); kset_unregister(xfs_kset); xfs_sysctl_unregister(); xfs_cleanup_procfs(); diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index aa03670..ba8d097 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -21,6 +21,7 @@ #include "xfs_log_format.h" #include "xfs_log.h" #include "xfs_log_priv.h" +#include "xfs_stats.h" struct xfs_sysfs_attr { struct attribute attr; @@ -125,6 +126,83 @@ struct kobj_type xfs_dbg_ktype = { #endif /* DEBUG */ + +/* stats */ + +STATIC ssize_t +stats_show( + char *buf, + void *data) +{ + return xfs_stats_format(buf); +} +XFS_SYSFS_ATTR_RO(stats); + +STATIC ssize_t +stats_clear_show( + char *buf, + void *data) +{ + return 0; +} + +STATIC ssize_t +stats_clear_store( + const char *buf, + size_t count, + void *data) +{ + int ret; + int val; + + ret = kstrtoint(buf, 0, &val); + if (ret) + return ret; + + if (val != 1) + return -EINVAL; + return xfs_stats_clearall(buf); +} +XFS_SYSFS_ATTR_RW(stats_clear); + +static struct attribute *xfs_stats_attrs[] = { + ATTR_LIST(stats), + ATTR_LIST(stats_clear), + NULL, +}; + +STATIC ssize_t +xfs_stats_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; +} + +STATIC ssize_t +xfs_stats_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; +} + +static struct sysfs_ops xfs_stats_ops = { + .show = xfs_stats_show, + .store = xfs_stats_store, +}; + +struct kobj_type xfs_stats_ktype = { + .release = xfs_sysfs_release, + .sysfs_ops = &xfs_stats_ops, + .default_attrs = xfs_stats_attrs, +}; + /* xlog */ STATIC ssize_t diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h index 240eee3..be692e5 100644 --- a/fs/xfs/xfs_sysfs.h +++ b/fs/xfs/xfs_sysfs.h @@ -22,6 +22,7 @@ extern struct kobj_type xfs_mp_ktype; /* xfs_mount */ extern struct kobj_type xfs_dbg_ktype; /* debug */ extern struct kobj_type xfs_log_ktype; /* xlog */ +extern struct kobj_type xfs_stats_ktype; /* stats */ static inline struct xfs_kobj * to_kobj(struct kobject *kobject) -- 2.4.3 From billodo@redhat.com Thu Sep 3 11:38:42 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id BC45829E04 for ; Thu, 3 Sep 2015 11:38:41 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 5A554AC012 for ; Thu, 3 Sep 2015 09:38:41 -0700 (PDT) X-ASG-Debug-ID: 1441298320-04bdf06dd967de0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id MULbf3RxDHVMN5qn (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 09:38:40 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 65C5DAED37 for ; Thu, 3 Sep 2015 16:38:40 +0000 (UTC) Received: from localhost.localdomain.com (unused [10.10.50.102] (may be forged)) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83GccRi013867 for ; Thu, 3 Sep 2015 12:38:40 -0400 From: billodo To: xfs@oss.sgi.com Subject: [PATCH 3/3] xfs: remove unused procfs code Date: Thu, 3 Sep 2015 11:36:27 -0500 X-ASG-Orig-Subj: [PATCH 3/3] xfs: remove unused procfs code Message-Id: <1441298187-29064-4-git-send-email-billodo@redhat.com> In-Reply-To: <1441298187-29064-1-git-send-email-billodo@redhat.com> References: <1441298187-29064-1-git-send-email-billodo@redhat.com> 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: 1441298320 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch removes the now unused procfs code that was xfs stat specific. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 74 ------------------------------------------------------ 1 file changed, 74 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index ad435f1..9f20d3e 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -112,80 +112,6 @@ int xfs_stats_clearall(const char *buf) return n; } -static int xfs_stat_proc_show(struct seq_file *m, void *v) -{ - int i, j; - __uint64_t xs_xstrat_bytes = 0; - __uint64_t xs_write_bytes = 0; - __uint64_t xs_read_bytes = 0; - - static const struct xstats_entry { - char *desc; - int endpoint; - } xstats[] = { - { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, - { "abt", XFSSTAT_END_ALLOC_BTREE }, - { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, - { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, - { "dir", XFSSTAT_END_DIRECTORY_OPS }, - { "trans", XFSSTAT_END_TRANSACTIONS }, - { "ig", XFSSTAT_END_INODE_OPS }, - { "log", XFSSTAT_END_LOG_OPS }, - { "push_ail", XFSSTAT_END_TAIL_PUSHING }, - { "xstrat", XFSSTAT_END_WRITE_CONVERT }, - { "rw", XFSSTAT_END_READ_WRITE_OPS }, - { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, - { "icluster", XFSSTAT_END_INODE_CLUSTER }, - { "vnodes", XFSSTAT_END_VNODE_OPS }, - { "buf", XFSSTAT_END_BUF }, - { "abtb2", XFSSTAT_END_ABTB_V2 }, - { "abtc2", XFSSTAT_END_ABTC_V2 }, - { "bmbt2", XFSSTAT_END_BMBT_V2 }, - { "ibt2", XFSSTAT_END_IBT_V2 }, - { "fibt2", XFSSTAT_END_FIBT_V2 }, - /* we print both series of quota information together */ - { "qm", XFSSTAT_END_QM }, - }; - - /* Loop over all stats groups */ - for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { - seq_printf(m, "%s", xstats[i].desc); - /* inner loop does each group */ - for (; j < xstats[i].endpoint; j++) - seq_printf(m, " %u", counter_val(j)); - seq_putc(m, '\n'); - } - /* extra precision counters */ - for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; - } - - seq_printf(m, "xpc %Lu %Lu %Lu\n", - xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); - seq_printf(m, "debug %u\n", -#if defined(DEBUG) - 1); -#else - 0); -#endif - return 0; -} - -static int xfs_stat_proc_open(struct inode *inode, struct file *file) -{ - return single_open(file, xfs_stat_proc_show, NULL); -} - -static const struct file_operations xfs_stat_proc_fops = { - .owner = THIS_MODULE, - .open = xfs_stat_proc_open, - .read = seq_read, - .llseek = seq_lseek, - .release = single_release, -}; - /* legacy quota interfaces */ #ifdef CONFIG_XFS_QUOTA static int xqm_proc_show(struct seq_file *m, void *v) -- 2.4.3 From billodo@redhat.com Thu Sep 3 11:38:44 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 21B3229E10 for ; Thu, 3 Sep 2015 11:38:44 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 02C7B30405F for ; Thu, 3 Sep 2015 09:38:41 -0700 (PDT) X-ASG-Debug-ID: 1441298319-04cbb06aca69810001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 5cPXRgFShWpE7kVN (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 09:38:40 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id DC0ECA2C18 for ; Thu, 3 Sep 2015 16:38:39 +0000 (UTC) Received: from localhost.localdomain.com (unused [10.10.50.102] (may be forged)) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83GccRh013867 for ; Thu, 3 Sep 2015 12:38:39 -0400 From: billodo To: xfs@oss.sgi.com Subject: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Date: Thu, 3 Sep 2015 11:36:26 -0500 X-ASG-Orig-Subj: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-Id: <1441298187-29064-3-git-send-email-billodo@redhat.com> In-Reply-To: <1441298187-29064-1-git-send-email-billodo@redhat.com> References: <1441298187-29064-1-git-send-email-billodo@redhat.com> 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: 1441298320 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 856cf57..ad435f1 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -244,9 +244,13 @@ xfs_init_procfs(void) if (!proc_mkdir("fs/xfs", NULL)) goto out; - if (!proc_create("fs/xfs/stat", 0, NULL, - &xfs_stat_proc_fops)) + if (!proc_symlink("fs/xfs/stat", NULL, + "/sys/fs/xfs/stats/stats")) + { + printk(KERN_INFO "failed to created fs/xfs/stat symlink\n"); goto out_remove_xfs_dir; + } + #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, &xqmstat_proc_fops)) -- 2.4.3 From darrick.wong@oracle.com Thu Sep 3 12:58:12 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id DD0957F93 for ; Thu, 3 Sep 2015 12:58:11 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 89720AC001 for ; Thu, 3 Sep 2015 10:58:08 -0700 (PDT) X-ASG-Debug-ID: 1441303081-04bdf06dd969ef0001-NocioJ Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by cuda.sgi.com with ESMTP id JrcVvWqwYFsdCFBz (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 10:58:01 -0700 (PDT) X-Barracuda-Envelope-From: darrick.wong@oracle.com X-Barracuda-Apparent-Source-IP: 141.146.126.69 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t83Hw0pM008851 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Sep 2015 17:58:01 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t83Hw0ds006706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Sep 2015 17:58:00 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t83HvxUA002154; Thu, 3 Sep 2015 17:57:59 GMT Received: from localhost (/10.145.179.157) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Sep 2015 10:57:59 -0700 Date: Thu, 3 Sep 2015 10:57:57 -0700 From: "Darrick J. Wong" To: billodo Cc: xfs@oss.sgi.com Subject: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-ID: <20150903175757.GB10397@birch.djwong.org> X-ASG-Orig-Subj: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats References: <1441298187-29064-1-git-send-email-billodo@redhat.com> <1441298187-29064-3-git-send-email-billodo@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441298187-29064-3-git-send-email-billodo@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Barracuda-Connect: aserp1040.oracle.com[141.146.126.69] X-Barracuda-Start-Time: 1441303081 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22196 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines On Thu, Sep 03, 2015 at 11:36:26AM -0500, billodo wrote: > As a part of the work to move xfs global stats from procfs to sysfs, > this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. > > Signed-off-by: Bill O'Donnell > --- > fs/xfs/xfs_stats.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > index 856cf57..ad435f1 100644 > --- a/fs/xfs/xfs_stats.c > +++ b/fs/xfs/xfs_stats.c > @@ -244,9 +244,13 @@ xfs_init_procfs(void) > if (!proc_mkdir("fs/xfs", NULL)) > goto out; > > - if (!proc_create("fs/xfs/stat", 0, NULL, > - &xfs_stat_proc_fops)) > + if (!proc_symlink("fs/xfs/stat", NULL, > + "/sys/fs/xfs/stats/stats")) Uh.... is it actually guaranteed that sysfs is mounted on /sys now? I sort of recall gregkh grumbling years ago that sysfs can be mounted anywhere, and that /proc shouldn't hardcode links to it. But that's just handwaving on my part. --D > + { > + printk(KERN_INFO "failed to created fs/xfs/stat symlink\n"); > goto out_remove_xfs_dir; > + } > + > #ifdef CONFIG_XFS_QUOTA > if (!proc_create("fs/xfs/xqmstat", 0, NULL, > &xqmstat_proc_fops)) > -- > 2.4.3 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Thu Sep 3 13:32:34 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id BAFF97F94 for ; Thu, 3 Sep 2015 13:32:34 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 8C2AB304039 for ; Thu, 3 Sep 2015 11:32:31 -0700 (PDT) X-ASG-Debug-ID: 1441305145-04bdf06dd96ade0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id YLyat5LUwTWF7TJB for ; Thu, 03 Sep 2015 11:32:25 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 3995E65CCFD4; Thu, 3 Sep 2015 13:32:25 -0500 (CDT) Subject: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats To: "Darrick J. Wong" , billodo X-ASG-Orig-Subj: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats References: <1441298187-29064-1-git-send-email-billodo@redhat.com> <1441298187-29064-3-git-send-email-billodo@redhat.com> <20150903175757.GB10397@birch.djwong.org> Cc: xfs@oss.sgi.com From: Eric Sandeen Message-ID: <55E89239.60305@sandeen.net> Date: Thu, 3 Sep 2015 13:32:25 -0500 MIME-Version: 1.0 In-Reply-To: <20150903175757.GB10397@birch.djwong.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441305145 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22198 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/3/15 12:57 PM, Darrick J. Wong wrote: > On Thu, Sep 03, 2015 at 11:36:26AM -0500, billodo wrote: >> As a part of the work to move xfs global stats from procfs to sysfs, >> this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. >> >> Signed-off-by: Bill O'Donnell >> --- >> fs/xfs/xfs_stats.c | 8 ++++++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c >> index 856cf57..ad435f1 100644 >> --- a/fs/xfs/xfs_stats.c >> +++ b/fs/xfs/xfs_stats.c >> @@ -244,9 +244,13 @@ xfs_init_procfs(void) >> if (!proc_mkdir("fs/xfs", NULL)) >> goto out; >> >> - if (!proc_create("fs/xfs/stat", 0, NULL, >> - &xfs_stat_proc_fops)) >> + if (!proc_symlink("fs/xfs/stat", NULL, >> + "/sys/fs/xfs/stats/stats")) > > Uh.... is it actually guaranteed that sysfs is mounted on /sys now? > > I sort of recall gregkh grumbling years ago that sysfs can be mounted anywhere, > and that /proc shouldn't hardcode links to it. But that's just handwaving on > my part. You can blame me for that idea. At least one other driver does do it, though; of_core_init(): proc_symlink("device-tree", NULL, "/sys/firmware/devicetree/base"); worst-case scenario, your "legacy" stats file will be a broken symlink... -Eric > --D > >> + { >> + printk(KERN_INFO "failed to created fs/xfs/stat symlink\n"); >> goto out_remove_xfs_dir; >> + } >> + >> #ifdef CONFIG_XFS_QUOTA >> if (!proc_create("fs/xfs/xqmstat", 0, NULL, >> &xqmstat_proc_fops)) >> -- >> 2.4.3 From billodo@redhat.com Thu Sep 3 13:39:57 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 479B37F95 for ; Thu, 3 Sep 2015 13:39:57 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 246088F8066 for ; Thu, 3 Sep 2015 11:39:57 -0700 (PDT) X-ASG-Debug-ID: 1441305595-04cbb06acd6cc70001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id F22w8ENThcLQfgXd (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 11:39:56 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id AFFACC0AAB12; Thu, 3 Sep 2015 18:39:55 +0000 (UTC) Received: from redhat.com (unused [10.10.50.102] (may be forged)) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83Idr2B020851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Sep 2015 14:39:55 -0400 Date: Thu, 3 Sep 2015 13:39:53 -0500 From: "Bill O'Donnell" To: Eric Sandeen Cc: "Darrick J. Wong" , xfs@oss.sgi.com Subject: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-ID: <20150903183953.GA9848@redhat.com> X-ASG-Orig-Subj: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats References: <1441298187-29064-1-git-send-email-billodo@redhat.com> <1441298187-29064-3-git-send-email-billodo@redhat.com> <20150903175757.GB10397@birch.djwong.org> <55E89239.60305@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55E89239.60305@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441305596 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 03, 2015 at 01:32:25PM -0500, Eric Sandeen wrote: > On 9/3/15 12:57 PM, Darrick J. Wong wrote: > > On Thu, Sep 03, 2015 at 11:36:26AM -0500, billodo wrote: > >> As a part of the work to move xfs global stats from procfs to sysfs, > >> this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. > >> > >> Signed-off-by: Bill O'Donnell > >> --- > >> fs/xfs/xfs_stats.c | 8 ++++++-- > >> 1 file changed, 6 insertions(+), 2 deletions(-) > >> > >> diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > >> index 856cf57..ad435f1 100644 > >> --- a/fs/xfs/xfs_stats.c > >> +++ b/fs/xfs/xfs_stats.c > >> @@ -244,9 +244,13 @@ xfs_init_procfs(void) > >> if (!proc_mkdir("fs/xfs", NULL)) > >> goto out; > >> > >> - if (!proc_create("fs/xfs/stat", 0, NULL, > >> - &xfs_stat_proc_fops)) > >> + if (!proc_symlink("fs/xfs/stat", NULL, > >> + "/sys/fs/xfs/stats/stats")) > > > > Uh.... is it actually guaranteed that sysfs is mounted on /sys now? > > > > I sort of recall gregkh grumbling years ago that sysfs can be mounted anywhere, > > and that /proc shouldn't hardcode links to it. But that's just handwaving on > > my part. > > You can blame me for that idea. At least one other driver does > do it, though; of_core_init(): > > proc_symlink("device-tree", NULL, "/sys/firmware/devicetree/base"); > > worst-case scenario, your "legacy" stats file will be a broken symlink... > > -Eric > I'm still looking for something in documentation that dictates such a requirement regarding symlinks to sysfs elements. -Bill > > --D > > > >> + { > >> + printk(KERN_INFO "failed to created fs/xfs/stat symlink\n"); > >> goto out_remove_xfs_dir; > >> + } > >> + > >> #ifdef CONFIG_XFS_QUOTA > >> if (!proc_create("fs/xfs/xqmstat", 0, NULL, > >> &xqmstat_proc_fops)) > >> -- > >> 2.4.3 > From billodo@redhat.com Thu Sep 3 14:15:10 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id DA19C7F98 for ; Thu, 3 Sep 2015 14:15:09 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 69FDDAC001 for ; Thu, 3 Sep 2015 12:15:06 -0700 (PDT) X-ASG-Debug-ID: 1441307704-04cb6c0e0c65310001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id L2hWyLXlgE4PLK0x (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 12:15:05 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 3B2A8A19D0; Thu, 3 Sep 2015 19:15:04 +0000 (UTC) Received: from redhat.com (unused [10.10.50.102] (may be forged)) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t83JF1h6001228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Sep 2015 15:15:03 -0400 Date: Thu, 3 Sep 2015 14:15:01 -0500 From: "Bill O'Donnell" To: Eric Sandeen , xfs@oss.sgi.com, "Darrick J. Wong" Subject: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-ID: <20150903191501.GA11440@redhat.com> X-ASG-Orig-Subj: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats References: <1441298187-29064-1-git-send-email-billodo@redhat.com> <1441298187-29064-3-git-send-email-billodo@redhat.com> <20150903175757.GB10397@birch.djwong.org> <55E89239.60305@sandeen.net> <20150903183953.GA9848@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150903183953.GA9848@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441307705 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 03, 2015 at 01:39:53PM -0500, Bill O'Donnell wrote: > On Thu, Sep 03, 2015 at 01:32:25PM -0500, Eric Sandeen wrote: > > On 9/3/15 12:57 PM, Darrick J. Wong wrote: > > > On Thu, Sep 03, 2015 at 11:36:26AM -0500, billodo wrote: > > >> As a part of the work to move xfs global stats from procfs to sysfs, > > >> this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. > > >> > > >> Signed-off-by: Bill O'Donnell > > >> --- > > >> fs/xfs/xfs_stats.c | 8 ++++++-- > > >> 1 file changed, 6 insertions(+), 2 deletions(-) > > >> > > >> diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > > >> index 856cf57..ad435f1 100644 > > >> --- a/fs/xfs/xfs_stats.c > > >> +++ b/fs/xfs/xfs_stats.c > > >> @@ -244,9 +244,13 @@ xfs_init_procfs(void) > > >> if (!proc_mkdir("fs/xfs", NULL)) > > >> goto out; > > >> > > >> - if (!proc_create("fs/xfs/stat", 0, NULL, > > >> - &xfs_stat_proc_fops)) > > >> + if (!proc_symlink("fs/xfs/stat", NULL, > > >> + "/sys/fs/xfs/stats/stats")) > > > > > > Uh.... is it actually guaranteed that sysfs is mounted on /sys now? > > > > > > I sort of recall gregkh grumbling years ago that sysfs can be mounted anywhere, > > > and that /proc shouldn't hardcode links to it. But that's just handwaving on > > > my part. > > > > You can blame me for that idea. At least one other driver does > > do it, though; of_core_init(): > > > > proc_symlink("device-tree", NULL, "/sys/firmware/devicetree/base"); > > > > worst-case scenario, your "legacy" stats file will be a broken symlink... > > > > -Eric > > > > I'm still looking for something in documentation that dictates such a requirement > regarding symlinks to sysfs elements. > -Bill I did find this in: https://www.kernel.org/doc/Documentation/sysfs-rules.txt --------------snip-------------------------- - sysfs is always at /sys Parsing /proc/mounts is a waste of time. Other mount points are a system configuration bug you should not try to solve. For test cases, possibly support a SYSFS_PATH environment variable to overwrite the application's behavior, but never try to search for sysfs. Never try to mount it, if you are not an early boot script. -------------snip--------------------------- > > > > --D > > > > > >> + { > > >> + printk(KERN_INFO "failed to created fs/xfs/stat symlink\n"); > > >> goto out_remove_xfs_dir; > > >> + } > > >> + > > >> #ifdef CONFIG_XFS_QUOTA > > >> if (!proc_create("fs/xfs/xqmstat", 0, NULL, > > >> &xqmstat_proc_fops)) > > >> -- > > >> 2.4.3 > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From darrick.wong@oracle.com Thu Sep 3 14:17:59 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 7BA0C7F9A for ; Thu, 3 Sep 2015 14:17:59 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 6ABC28F8033 for ; Thu, 3 Sep 2015 12:17:56 -0700 (PDT) X-ASG-Debug-ID: 1441307874-04cb6c0e0e653e0001-NocioJ Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by cuda.sgi.com with ESMTP id VKQKSsSSPgtqgkBk (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 12:17:54 -0700 (PDT) X-Barracuda-Envelope-From: darrick.wong@oracle.com X-Barracuda-Apparent-Source-IP: 156.151.31.81 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t83JHrAq007498 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Sep 2015 19:17:53 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t83JHrID007504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Sep 2015 19:17:53 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t83JHr9E025751; Thu, 3 Sep 2015 19:17:53 GMT Received: from localhost (/10.145.179.157) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Sep 2015 12:17:52 -0700 Date: Thu, 3 Sep 2015 12:17:51 -0700 From: "Darrick J. Wong" To: "Bill O'Donnell" Cc: Eric Sandeen , xfs@oss.sgi.com Subject: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-ID: <20150903191751.GC10397@birch.djwong.org> X-ASG-Orig-Subj: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats References: <1441298187-29064-1-git-send-email-billodo@redhat.com> <1441298187-29064-3-git-send-email-billodo@redhat.com> <20150903175757.GB10397@birch.djwong.org> <55E89239.60305@sandeen.net> <20150903183953.GA9848@redhat.com> <20150903191501.GA11440@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150903191501.GA11440@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Barracuda-Connect: userp1040.oracle.com[156.151.31.81] X-Barracuda-Start-Time: 1441307874 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22200 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines On Thu, Sep 03, 2015 at 02:15:01PM -0500, Bill O'Donnell wrote: > On Thu, Sep 03, 2015 at 01:39:53PM -0500, Bill O'Donnell wrote: > > On Thu, Sep 03, 2015 at 01:32:25PM -0500, Eric Sandeen wrote: > > > On 9/3/15 12:57 PM, Darrick J. Wong wrote: > > > > On Thu, Sep 03, 2015 at 11:36:26AM -0500, billodo wrote: > > > >> As a part of the work to move xfs global stats from procfs to sysfs, > > > >> this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. > > > >> > > > >> Signed-off-by: Bill O'Donnell > > > >> --- > > > >> fs/xfs/xfs_stats.c | 8 ++++++-- > > > >> 1 file changed, 6 insertions(+), 2 deletions(-) > > > >> > > > >> diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > > > >> index 856cf57..ad435f1 100644 > > > >> --- a/fs/xfs/xfs_stats.c > > > >> +++ b/fs/xfs/xfs_stats.c > > > >> @@ -244,9 +244,13 @@ xfs_init_procfs(void) > > > >> if (!proc_mkdir("fs/xfs", NULL)) > > > >> goto out; > > > >> > > > >> - if (!proc_create("fs/xfs/stat", 0, NULL, > > > >> - &xfs_stat_proc_fops)) > > > >> + if (!proc_symlink("fs/xfs/stat", NULL, > > > >> + "/sys/fs/xfs/stats/stats")) > > > > > > > > Uh.... is it actually guaranteed that sysfs is mounted on /sys now? > > > > > > > > I sort of recall gregkh grumbling years ago that sysfs can be mounted anywhere, > > > > and that /proc shouldn't hardcode links to it. But that's just handwaving on > > > > my part. > > > > > > You can blame me for that idea. At least one other driver does > > > do it, though; of_core_init(): > > > > > > proc_symlink("device-tree", NULL, "/sys/firmware/devicetree/base"); > > > > > > worst-case scenario, your "legacy" stats file will be a broken symlink... > > > > > > -Eric > > > > > > > I'm still looking for something in documentation that dictates such a requirement > > regarding symlinks to sysfs elements. > > -Bill > > I did find this in: https://www.kernel.org/doc/Documentation/sysfs-rules.txt > --------------snip-------------------------- > - sysfs is always at /sys > Parsing /proc/mounts is a waste of time. Other mount points are a > system configuration bug you should not try to solve. For test cases, > possibly support a SYSFS_PATH environment variable to overwrite the > application's behavior, but never try to search for sysfs. Never try > to mount it, if you are not an early boot script. > -------------snip--------------------------- Ah, ok, sorry for the noise then. --D > > > > > > --D > > > > > > > >> + { > > > >> + printk(KERN_INFO "failed to created fs/xfs/stat symlink\n"); > > > >> goto out_remove_xfs_dir; > > > >> + } > > > >> + > > > >> #ifdef CONFIG_XFS_QUOTA > > > >> if (!proc_create("fs/xfs/xqmstat", 0, NULL, > > > >> &xqmstat_proc_fops)) > > > >> -- > > > >> 2.4.3 > > > > > > > _______________________________________________ > > xfs mailing list > > xfs@oss.sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Thu Sep 3 14:56:39 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 930257F88 for ; Thu, 3 Sep 2015 14:56:39 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 721E08F804C for ; Thu, 3 Sep 2015 12:56:39 -0700 (PDT) X-ASG-Debug-ID: 1441310196-04cbb06aca6f500001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id vQNDRbjOfQaoqzSh for ; Thu, 03 Sep 2015 12:56:36 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id ADE4A65AFC84; Thu, 3 Sep 2015 14:56:35 -0500 (CDT) Subject: Re: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs To: billodo , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs References: <1441298187-29064-1-git-send-email-billodo@redhat.com> <1441298187-29064-2-git-send-email-billodo@redhat.com> From: Eric Sandeen X-Enigmail-Draft-Status: N1110 Message-ID: <55E8A5F3.6010701@sandeen.net> Date: Thu, 3 Sep 2015 14:56:35 -0500 MIME-Version: 1.0 In-Reply-To: <1441298187-29064-2-git-send-email-billodo@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441310196 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22202 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/3/15 11:36 AM, billodo wrote: > Currently, xfs global stats are in procfs. This patch introduces > (replicates) the global stats in sysfs. Additionally a stats_clear file > is introduced in sysfs. Looks pretty good, a few things below. (FWIW, lots of these came from running scripts/checkpatch.pl against the patch - not everything it says is mandatory, but worth doing to catch some things) > Signed-off-by: Bill O'Donnell > --- > fs/xfs/xfs_stats.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > fs/xfs/xfs_stats.h | 2 ++ > fs/xfs/xfs_super.c | 17 ++++++++--- > fs/xfs/xfs_sysfs.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++ > fs/xfs/xfs_sysfs.h | 1 + > 5 files changed, 177 insertions(+), 4 deletions(-) > > diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > index f224038..856cf57 100644 > --- a/fs/xfs/xfs_stats.c > +++ b/fs/xfs/xfs_stats.c > @@ -29,6 +29,89 @@ static int counter_val(int idx) > return val; > } > > +int xfs_stats_format(char *buf) > +{ > + int i, j; > + int len = 0; > + __uint64_t xs_xstrat_bytes = 0; > + __uint64_t xs_write_bytes = 0; > + __uint64_t xs_read_bytes = 0; > + > + static const struct xstats_entry { > + char *desc; > + int endpoint; > + } xstats[] = { > + { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, > + { "abt", XFSSTAT_END_ALLOC_BTREE }, > + { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, > + { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, > + { "dir", XFSSTAT_END_DIRECTORY_OPS }, > + { "trans", XFSSTAT_END_TRANSACTIONS }, > + { "ig", XFSSTAT_END_INODE_OPS }, > + { "log", XFSSTAT_END_LOG_OPS }, > + { "push_ail", XFSSTAT_END_TAIL_PUSHING }, > + { "xstrat", XFSSTAT_END_WRITE_CONVERT }, > + { "rw", XFSSTAT_END_READ_WRITE_OPS }, > + { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, > + { "icluster", XFSSTAT_END_INODE_CLUSTER }, > + { "vnodes", XFSSTAT_END_VNODE_OPS }, > + { "buf", XFSSTAT_END_BUF }, > + { "abtb2", XFSSTAT_END_ABTB_V2 }, > + { "abtc2", XFSSTAT_END_ABTC_V2 }, > + { "bmbt2", XFSSTAT_END_BMBT_V2 }, > + { "ibt2", XFSSTAT_END_IBT_V2 }, > + { "fibt2", XFSSTAT_END_FIBT_V2 }, > + /* we print both series of quota information together */ > + { "qm", XFSSTAT_END_QM }, > + }; > + > + /* Loop over all stats groups */ > + > + for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { > + len += snprintf(buf + len, PATH_MAX - len, "%s", xstats[i].desc); This line is > 80 chars, might wrap the last arg onto the next line > + /* inner loop does each group */ > + for (; j < xstats[i].endpoint; j++) > + len += snprintf(buf + len, PATH_MAX - len, " %u", counter_val(j)); ditto > + len += snprintf(buf + len, PATH_MAX - len, "\n"); > + } > + /* extra precision counters */ > + for_each_possible_cpu(i) { > + xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; > + xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; > + xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; > + } > + > + len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", > + xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); > + len += snprintf(buf+len, PATH_MAX-len, "debug %u\n", > +#if defined(DEBUG) > + 1); > +#else > + 0); > +#endif > + > +return len; > +} > + > +int xfs_stats_clearall(const char *buf) given that *buf isn't used, I'd make this a (void) And returning the size of the struct isn't correct, and nothing can really fail, so may as well make return void too, void xfs_stats_clearall(void) And finally, given that the sysctl handler for clearing stats is still around, and this dupicates that code, may as well make the sysctl handler just call this function, and eliminate the duplicate code there. > +{ > + int c, n; > + __uint32_t vn_active; > + > + n = sizeof(struct xfsstats); > + xfs_notice(NULL, "Clearing xfsstats"); > + for_each_possible_cpu(c) { > + preempt_disable(); > + /* save vn_active, it's a universal truth! */ > + vn_active = per_cpu(xfsstats, c).vn_active; > + memset(&per_cpu(xfsstats, c), 0, > + sizeof(struct xfsstats)); > + per_cpu(xfsstats, c).vn_active = vn_active; > + preempt_enable(); > + } > + return n; > +} > + > static int xfs_stat_proc_show(struct seq_file *m, void *v) > { > int i, j; > diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h > index c8f238b..c117afc 100644 > --- a/fs/xfs/xfs_stats.h > +++ b/fs/xfs/xfs_stats.h > @@ -18,6 +18,8 @@ > #ifndef __XFS_STATS_H__ > #define __XFS_STATS_H__ > > +int xfs_stats_format(char *buf); > +int xfs_stats_clearall(const char *buf); > > #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) > > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > index 3bf503a..9a794cf 100644 > --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -61,6 +61,7 @@ static kmem_zone_t *xfs_ioend_zone; > mempool_t *xfs_ioend_pool; > > static struct kset *xfs_kset; /* top-level xfs sysfs dir */ > +static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ > #ifdef DEBUG > static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ > #endif > @@ -1838,15 +1839,20 @@ init_xfs_fs(void) > xfs_kset = kset_create_and_add("xfs", NULL, fs_kobj); > if (!xfs_kset) { > error = -ENOMEM; > - goto out_sysctl_unregister;; > + goto out_sysctl_unregister; > } > > + xfs_stats_kobj.kobject.kset = xfs_kset; > + error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, "stats"); over 80 chars > + if (error) > + goto out_kset_unregister; > + > #ifdef DEBUG > xfs_dbg_kobj.kobject.kset = xfs_kset; > error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); > - if (error) > - goto out_kset_unregister; > #endif > + if (error) > + goto out_remove_stats_kobj; this needs to stay inside the #ifdef, otherwise you have two if (error) goto BLAH;'s in a row if DEBUG is off... > > error = xfs_qm_init(); > if (error) > @@ -1862,8 +1868,10 @@ init_xfs_fs(void) > out_remove_kobj: I'd make this "out_remove_dbg_kobj" now that there are 2. > #ifdef DEBUG > xfs_sysfs_del(&xfs_dbg_kobj); > - out_kset_unregister: > #endif > + out_remove_stats_kobj: pretty sure this still needs to be inside the #ifdef too; think it through with and without DEBUG defined, make sure it does the right thing ... > + xfs_sysfs_del(&xfs_stats_kobj); > + out_kset_unregister: > kset_unregister(xfs_kset); > out_sysctl_unregister: > xfs_sysctl_unregister(); > @@ -1889,6 +1897,7 @@ exit_xfs_fs(void) > #ifdef DEBUG > xfs_sysfs_del(&xfs_dbg_kobj); > #endif > + xfs_sysfs_del(&xfs_stats_kobj); > kset_unregister(xfs_kset); > xfs_sysctl_unregister(); > xfs_cleanup_procfs(); > diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c > index aa03670..ba8d097 100644 > --- a/fs/xfs/xfs_sysfs.c > +++ b/fs/xfs/xfs_sysfs.c > @@ -21,6 +21,7 @@ > #include "xfs_log_format.h" > #include "xfs_log.h" > #include "xfs_log_priv.h" > +#include "xfs_stats.h" > > struct xfs_sysfs_attr { > struct attribute attr; > @@ -125,6 +126,83 @@ struct kobj_type xfs_dbg_ktype = { > > #endif /* DEBUG */ > > + > +/* stats */ > + > +STATIC ssize_t > +stats_show( > + char *buf, > + void *data) > +{ > + return xfs_stats_format(buf); > +} > +XFS_SYSFS_ATTR_RO(stats); > + > +STATIC ssize_t > +stats_clear_show( > + char *buf, > + void *data) > +{ > + return 0; > +} Ok, this means that if we try to read it we get nothing: # cat /sys/fs/xfs/stats/stats_clear # I think that's ok. Oh, but see below; we can declare it write-only, then it disappears! > +STATIC ssize_t > +stats_clear_store( > + const char *buf, > + size_t count, > + void *data) > +{ > + int ret; > + int val; > + > + ret = kstrtoint(buf, 0, &val); > + if (ret) > + return ret; > + > + if (val != 1) > + return -EINVAL; > + return xfs_stats_clearall(buf); Hm, I think this is supposed to return the number of bytes stored in the file, which is not what the clearall function does. Given that you sanitize the input and return an error if not sane, then by the time we get to something sane, just return "count" - the amt of data we got in. That will make writes to this file return the proper bytes written. i.e. xfs_stats_clearall(); return count; (and yeah, it doesn't need "buf") > +} > +XFS_SYSFS_ATTR_RW(stats_clear); Ooh, I just realized that there is an __ATTR_WO in core kernel code; using that in a new XFS_SYSFS_ATTR_WO would make sense here. Then you can drop the stats_clear_show I think. > + > +static struct attribute *xfs_stats_attrs[] = { > + ATTR_LIST(stats), > + ATTR_LIST(stats_clear), > + NULL, > +}; > + > +STATIC ssize_t > +xfs_stats_show( > + struct kobject *kobject, > + struct attribute *attr, > + char *buf) > +{ > + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); Add a blank line after the var declaration > + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; > +} > + > +STATIC ssize_t > +xfs_stats_store( > + struct kobject *kobject, > + struct attribute *attr, > + const char *buf, > + size_t count) > +{ > + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); Add a blank line after the var declaration > + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; > +} covert all those 8-spaces above to tabs, please > + > +static struct sysfs_ops xfs_stats_ops = { > + .show = xfs_stats_show, > + .store = xfs_stats_store, > +}; > + > +struct kobj_type xfs_stats_ktype = { > + .release = xfs_sysfs_release, > + .sysfs_ops = &xfs_stats_ops, > + .default_attrs = xfs_stats_attrs, > +}; > + > /* xlog */ > > STATIC ssize_t > diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h > index 240eee3..be692e5 100644 > --- a/fs/xfs/xfs_sysfs.h > +++ b/fs/xfs/xfs_sysfs.h > @@ -22,6 +22,7 @@ > extern struct kobj_type xfs_mp_ktype; /* xfs_mount */ > extern struct kobj_type xfs_dbg_ktype; /* debug */ > extern struct kobj_type xfs_log_ktype; /* xlog */ > +extern struct kobj_type xfs_stats_ktype; /* stats */ > > static inline struct xfs_kobj * > to_kobj(struct kobject *kobject) > From sandeen@sandeen.net Thu Sep 3 15:08:45 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 4BA717F95 for ; Thu, 3 Sep 2015 15:08:45 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id CDCA6AC005 for ; Thu, 3 Sep 2015 13:08:41 -0700 (PDT) X-ASG-Debug-ID: 1441310920-04cbb06acd6f980001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id 9cm2AACzHV7uUeAk for ; Thu, 03 Sep 2015 13:08:40 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 44CD56531E8D; Thu, 3 Sep 2015 15:08:40 -0500 (CDT) Subject: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats To: billodo , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats References: <1441298187-29064-1-git-send-email-billodo@redhat.com> <1441298187-29064-3-git-send-email-billodo@redhat.com> From: Eric Sandeen X-Enigmail-Draft-Status: N1110 Message-ID: <55E8A8C7.9080506@sandeen.net> Date: Thu, 3 Sep 2015 15:08:39 -0500 MIME-Version: 1.0 In-Reply-To: <1441298187-29064-3-git-send-email-billodo@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441310920 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22202 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/3/15 11:36 AM, billodo wrote: > As a part of the work to move xfs global stats from procfs to sysfs, > this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. > > Signed-off-by: Bill O'Donnell > --- > fs/xfs/xfs_stats.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > index 856cf57..ad435f1 100644 > --- a/fs/xfs/xfs_stats.c > +++ b/fs/xfs/xfs_stats.c > @@ -244,9 +244,13 @@ xfs_init_procfs(void) > if (!proc_mkdir("fs/xfs", NULL)) > goto out; > > - if (!proc_create("fs/xfs/stat", 0, NULL, > - &xfs_stat_proc_fops)) > + if (!proc_symlink("fs/xfs/stat", NULL, > + "/sys/fs/xfs/stats/stats")) > + { > + printk(KERN_INFO "failed to created fs/xfs/stat symlink\n"); > goto out_remove_xfs_dir; > + } > + I'm not sure we need the printk, we didn't say anything if proc_create(fs/xfs/stat) failed... I guess the cleanup is fine as it is, right, it can remove a symlink too AFAIK. -Eric > #ifdef CONFIG_XFS_QUOTA > if (!proc_create("fs/xfs/xqmstat", 0, NULL, > &xqmstat_proc_fops)) > From sandeen@sandeen.net Thu Sep 3 15:11:12 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 5A4C47F9B for ; Thu, 3 Sep 2015 15:11:12 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id DB696AC007 for ; Thu, 3 Sep 2015 13:11:11 -0700 (PDT) X-ASG-Debug-ID: 1441311070-04cbb06aca6fa70001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id EmEfku6CgGwykfEx for ; Thu, 03 Sep 2015 13:11:10 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 3103D6531E8D; Thu, 3 Sep 2015 15:11:10 -0500 (CDT) Subject: Re: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs To: billodo , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs References: <1441298187-29064-1-git-send-email-billodo@redhat.com> <1441298187-29064-2-git-send-email-billodo@redhat.com> From: Eric Sandeen Message-ID: <55E8A95D.9060103@sandeen.net> Date: Thu, 3 Sep 2015 15:11:09 -0500 MIME-Version: 1.0 In-Reply-To: <1441298187-29064-2-git-send-email-billodo@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441311070 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22202 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/3/15 11:36 AM, billodo wrote: > Currently, xfs global stats are in procfs. This patch introduces > (replicates) the global stats in sysfs. Additionally a stats_clear file > is introduced in sysfs. > > Signed-off-by: Bill O'Donnell > --- > fs/xfs/xfs_stats.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ > fs/xfs/xfs_stats.h | 2 ++ > fs/xfs/xfs_super.c | 17 ++++++++--- > fs/xfs/xfs_sysfs.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++ > fs/xfs/xfs_sysfs.h | 1 + > 5 files changed, 177 insertions(+), 4 deletions(-) > > diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > index f224038..856cf57 100644 > --- a/fs/xfs/xfs_stats.c > +++ b/fs/xfs/xfs_stats.c > @@ -29,6 +29,89 @@ static int counter_val(int idx) > return val; > } > > +int xfs_stats_format(char *buf) > +{ > + int i, j; > + int len = 0; Oh, one other little nitpick, tab over "len" to match the rest. > + __uint64_t xs_xstrat_bytes = 0; > + __uint64_t xs_write_bytes = 0; > + __uint64_t xs_read_bytes = 0; From sandeen@sandeen.net Thu Sep 3 15:34:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 32C0C7F9E for ; Thu, 3 Sep 2015 15:34:05 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 14B45304048 for ; Thu, 3 Sep 2015 13:34:01 -0700 (PDT) X-ASG-Debug-ID: 1441312439-04cb6c0e0e66e60001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id yYJN5EJLmcLTFVEp for ; Thu, 03 Sep 2015 13:33:59 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 96FF86531E8D; Thu, 3 Sep 2015 15:33:59 -0500 (CDT) Subject: Re: [PATCH 0/3] xfs: new global stats in sysfs To: billodo , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/3] xfs: new global stats in sysfs References: <1441298187-29064-1-git-send-email-billodo@redhat.com> From: Eric Sandeen Message-ID: <55E8AEB7.6050006@sandeen.net> Date: Thu, 3 Sep 2015 15:33:59 -0500 MIME-Version: 1.0 In-Reply-To: <1441298187-29064-1-git-send-email-billodo@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441312439 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22203 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/3/15 11:36 AM, billodo wrote: > > Hi all- > Here is a first pass at a series to add new global stats to sysfs. > As a part of that, the /proc/fs/xfs/stat file becomes a symlink to > the sysfs stats entry. The patch provides the beginnings of the > infrastructure for per-fs stats (in addition to global accumulative > stats). To flesh this out a little more: We already have per-fs information in /sys, so it makes sense to have per-fs stats there too. As a first step, moving existing global stats infrastructure to /sys will allow us to re-use that sysfs code for per-fs stats as well. -Eric From reinoudkoornstra@gmail.com Thu Sep 3 15:55:59 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 9F3D17FA0 for ; Thu, 3 Sep 2015 15:55:59 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 2A893AC005 for ; Thu, 3 Sep 2015 13:55:59 -0700 (PDT) X-ASG-Debug-ID: 1441313757-04cb6c0e0f67730001-NocioJ Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com [209.85.213.48]) by cuda.sgi.com with ESMTP id ZJ3aBBsRKqTwGDsl (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 03 Sep 2015 13:55:57 -0700 (PDT) X-Barracuda-Envelope-From: reinoudkoornstra@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.213.48 X-Barracuda-IPDD: Level1 [gmail.com/209.85.213.48] Received: by vkbf67 with SMTP id f67so1070954vkb.0 for ; Thu, 03 Sep 2015 13:55:57 -0700 (PDT) X-Barracuda-IPDD: Level1 [gmail.com/209.85.213.48] X-Barracuda-IPDD: Level1 [gmail.com/209.85.213.48] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XYmo41atUmBrPyMNPhSmMCSaz2boYuX3UIXnYSLIjGk=; b=b17UXnScRe+Da0+Jq1Ce3B798Rb9HdCvqzwNuOmZA2hB4Sqz+wv5n6EDPmWGcsUy/4 O7Yer6rUZhetEXT4Oq1CcWOdyJ3RpaSRSldM+iZ170vx8wNJXFe4RlM4Ar89ynMpdLsG N2kS2njSBWwo8ujpaDSaSdxrvIHgy6XLlzOj9GTAhrEGuGAtqpVZeW/286tdbwsWd00T knOAn5DpG2DnJEruMvKxbG0E08g2hoEA+FSval3/Y7jtf3IET3zbBbXKvtNyGSZmyiBh vjaEdoq4F5bwwg/o2dWAIC4fRg4FELlthFL8fRMqxZdBmfGKfB1okKXfa6wFncYhIeQy X8IA== MIME-Version: 1.0 X-Received: by 10.52.12.34 with SMTP id v2mr32911093vdb.38.1441313756875; Thu, 03 Sep 2015 13:55:56 -0700 (PDT) Received: by 10.103.23.5 with HTTP; Thu, 3 Sep 2015 13:55:56 -0700 (PDT) Date: Thu, 3 Sep 2015 14:55:56 -0600 Message-ID: Subject: every week new xfs errors From: Reinoud Koornstra X-ASG-Orig-Subj: every week new xfs errors To: xfs@oss.sgi.com Content-Type: text/plain; charset=UTF-8 X-Barracuda-Connect: mail-vk0-f48.google.com[209.85.213.48] X-Barracuda-Start-Time: 1441313757 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22204 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 Hi Everyone, I am running xfs on a SSD. smartd reports this: Device: /dev/sdb [SAT], Crucial_CT256M550SSD3, S/N:15020ED48DF8, WWN:5-00a075-10ed48df8, FW:MU02, 256 GB I am running a compiled linux 4.1.6 kernel (before 4.1.2 and before that 3.18.x) on ubuntu 14.04 xfs_repair had issues mostly every week to report. Now xfs_repair says it's finally clean. However: reinoud@Mipam:/$ sudo xfs_db -r /dev/sdb1 xfs_db> frag Metadata CRC error detected at block 0x773cac0/0x1000 Metadata CRC error detected at block 0xee79570/0x1000 Metadata CRC error detected at block 0x165b6020/0x1000 actual 2891336, ideal 2888294, fragmentation factor 0.11% There are still issue. Are there problems with running xfs on a SSD in general? It's fast and stable (seems like), but mostly i start noticing problems when i'm running git operations that fail, after that xfs_repair reports issues indeed. How can i fix these error reported here or can't i fix them? Thanks, Reinoud. From david@fromorbit.com Thu Sep 3 17:21:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 829CF7F90 for ; Thu, 3 Sep 2015 17:21:05 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 12E41AC001 for ; Thu, 3 Sep 2015 15:21:01 -0700 (PDT) X-ASG-Debug-ID: 1441318855-04cbb06aca73000001-NocioJ Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id iD9VJZk4tAUbZWuN for ; Thu, 03 Sep 2015 15:20:55 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.129 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DqCQA1x+hVPAUaLHlDGoMhVGmNA5xIBopeix+FcwQCAoE7TQEBAQEBAQcBAQEBQT+EIwEBAQMBOhwjBQsIAxgJJQ8FJQMHGhOIJgcOO8pzAQEIAiAZhhOFQoULB4QsBZVRhQeHbZpyhDgsMwGJSwEBAQ Received: from ppp121-44-26-5.lns20.syd4.internode.on.net (HELO dastard) ([121.44.26.5]) by ipmail06.adl2.internode.on.net with ESMTP; 04 Sep 2015 07:50:24 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZXcrn-0007w7-RV; Fri, 04 Sep 2015 08:20:23 +1000 Date: Fri, 4 Sep 2015 08:20:23 +1000 From: Dave Chinner To: Reinoud Koornstra Cc: xfs@oss.sgi.com Subject: Re: every week new xfs errors Message-ID: <20150903222023.GX3902@dastard> X-ASG-Orig-Subj: Re: every week new xfs errors 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-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1441318855 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.10 X-Barracuda-Spam-Status: No, SCORE=0.10 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA085 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22209 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 BSF_SC0_SA085 Custom Rule SA085 On Thu, Sep 03, 2015 at 02:55:56PM -0600, Reinoud Koornstra wrote: > Hi Everyone, > > I am running xfs on a SSD. > smartd reports this: > > Device: /dev/sdb [SAT], Crucial_CT256M550SSD3, S/N:15020ED48DF8, > WWN:5-00a075-10ed48df8, FW:MU02, 256 GB > > I am running a compiled linux 4.1.6 kernel (before 4.1.2 and before > that 3.18.x) on ubuntu 14.04 > xfs_repair had issues mostly every week to report. > Now xfs_repair says it's finally clean. > However: > > reinoud@Mipam:/$ sudo xfs_db -r /dev/sdb1 > xfs_db> frag > Metadata CRC error detected at block 0x773cac0/0x1000 > Metadata CRC error detected at block 0xee79570/0x1000 > Metadata CRC error detected at block 0x165b6020/0x1000 > actual 2891336, ideal 2888294, fragmentation factor 0.11% You're running on a mounted filesystem? (the "-r" is only necessary if the fs is mounted) If so, this is expected. > There are still issue. > Are there problems with running xfs on a SSD in general? > It's fast and stable (seems like), but mostly i start noticing > problems when i'm running git operations that fail, after that > xfs_repair reports issues indeed. Perhaps you'd like to start by reporting these issues, as solving them is far more important that what the (useless) frag command reports. Start here: http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F Cheers, Dave. -- Dave Chinner david@fromorbit.com From rjohnston@sgi.com Thu Sep 3 18:43:50 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 7A1FD7FA6 for ; Thu, 3 Sep 2015 18:43:50 -0500 (CDT) Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay3.corp.sgi.com (Postfix) with ESMTP id AC2D1AC001; Thu, 3 Sep 2015 16:43:46 -0700 (PDT) Received: from gulag1.americas.sgi.com (gulag1.americas.sgi.com [128.162.236.41]) by estes.americas.sgi.com (Postfix) with ESMTP id 5C14D700194E; Thu, 3 Sep 2015 18:43:46 -0500 (CDT) Received: by gulag1.americas.sgi.com (Postfix, from userid 48222) id 2473A600006AF; Thu, 3 Sep 2015 18:43:46 -0500 (CDT) Subject: [PATCH V3] xfsrestore: fix fs uuid order check for incremental restores From: Rich Johnston To: bfoster@redhat.com Cc: xfs@oss.sgi.com References: <20150826213133.GB3902@dastard> <55D5FB95.1280108@sgi.com> <20150902132112.GB23587@bfoster.bfoster> In-Reply-To: <20150902132112.GB23587@bfoster.bfoster> Content-Disposition: inline; filename=xfsrestore-fix-fs-uuid-order-check-for-incremental-restores.patch Message-Id: <20150903234346.2473A600006AF@gulag1.americas.sgi.com> Date: Thu, 3 Sep 2015 18:43:46 -0500 (CDT) Restoring an incremental level 1 dump will fail with the following error if the fs uuid of the most recent level 0 dump in the inventory does not match level 1 dump we are restoring. xfsrestore: ERROR: selected dump not based on previously applied dump This can happen when you have multiple filesystems and you are restoring a level 1 or greater dump of filesystem FS1 but the most recent level 0 dump in the inventory was filesystem FS2 The fix is to ensure the fs uuid of the inventory entry and the dump to be restored match. Signed-off-by: Rich Johnston --- Changelog V2 wrong file sent V3 Address review comments from Brian: fix invmgr_query_all_sessions() returning true if these error cases persist throughout the loop make if check more readable and less overloaded in search_inv() and return an error if GET_REC_NOLOCK() fails use NULL instead of (uuid_t *)0 in Inv_validate_cmdline() remove any spaces around braces of code that was changed dump/content.c | 16 +++--- inventory/inv_api.c | 130 +++++++++++++++++++++++++++++--------------------- inventory/inv_mgr.c | 55 ++++++++++++++------- inventory/inv_priv.h | 7 +- inventory/inventory.h | 21 +++++--- restore/content.c | 23 +++++--- 6 files changed, 152 insertions(+), 100 deletions(-) Index: b/dump/content.c =================================================================== --- a/dump/content.c +++ b/dump/content.c @@ -872,7 +872,7 @@ content_init( intgen_t argc, sameinterruptedpr = BOOL_FALSE; interruptedpr = BOOL_FALSE; - ok = inv_get_session_byuuid( &baseuuid, &sessp ); + ok = inv_get_session_byuuid(&fsid, &baseuuid, &sessp); if ( ! ok ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "could not find specified base dump (%s) " @@ -983,9 +983,10 @@ content_init( intgen_t argc, "online inventory not available\n") ); return BOOL_FALSE; } - ok = inv_lastsession_level_lessthan( inv_idbt, - ( u_char_t )sc_level, - &sessp ); + ok = inv_lastsession_level_lessthan(&fsid, + inv_idbt, + (u_char_t)sc_level, + &sessp); if ( ! ok ) { sessp = 0; } @@ -1022,9 +1023,10 @@ content_init( intgen_t argc, if ( inv_idbt != INV_TOKEN_NULL ) { /* REFERENCED */ bool_t ok1; - ok = inv_lastsession_level_equalto( inv_idbt, - ( u_char_t )sc_level, - &sessp ); + ok = inv_lastsession_level_equalto(&fsid, + inv_idbt, + (u_char_t)sc_level, + &sessp); ok1 = inv_close( inv_idbt ); ASSERT( ok1 ); if ( ! ok ) { Index: b/inventory/inv_api.c =================================================================== --- a/inventory/inv_api.c +++ b/inventory/inv_api.c @@ -596,69 +596,78 @@ inv_free_session( /*----------------------------------------------------------------------*/ -/* inventory_lasttime_level_lessthan */ -/* */ -/* Given a token that refers to a file system, and a level, this returns*/ -/* the last time when a session of a lesser level was done. */ -/* */ -/* returns -1 on error. */ +/* inv_lasttime_level_lessthan */ +/* */ +/* Given a file system uuid, token that refers to a file system, and a */ +/* level, tm is populated with last time when a session of a lesser */ +/* level was done. */ +/* */ +/* Returns TRUE on success. */ /*----------------------------------------------------------------------*/ bool_t inv_lasttime_level_lessthan( - inv_idbtoken_t tok, - u_char level, - time32_t **tm ) + uuid_t *fsidp, + inv_idbtoken_t tok, + u_char level, + time32_t **tm) { int rval; if ( tok != INV_TOKEN_NULL ) { - rval = search_invt( tok->d_invindex_fd, &level, (void **) tm, - (search_callback_t) tm_level_lessthan ); + rval = search_invt(fsidp, tok->d_invindex_fd, &level, + (void **)tm, + (search_callback_t)tm_level_lessthan); return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; } - return invmgr_query_all_sessions((void *) &level, /* in */ - (void **) tm, /* out */ - (search_callback_t) tm_level_lessthan); + return invmgr_query_all_sessions(fsidp, /* fs uuid ptr */ + (void *)&level, /* in */ + (void **)tm, /* out */ + (search_callback_t)tm_level_lessthan); } - - - - /*----------------------------------------------------------------------*/ -/* */ -/* */ -/* */ +/* inv_lastsession_level_lessthan */ +/* */ +/* Given a file system uuid, token that refers to a file system, and a */ +/* level, ses is populated with a session of lesser than the level */ +/* passed in. */ +/* */ +/* Returns FALSE on an error, TRUE if not. If (*ses) is NULL, then the */ +/* search failed. */ /*----------------------------------------------------------------------*/ bool_t inv_lastsession_level_lessthan( - inv_idbtoken_t tok, + uuid_t *fsidp, + inv_idbtoken_t tok, u_char level, - inv_session_t **ses ) + inv_session_t **ses) { int rval; if ( tok != INV_TOKEN_NULL ) { - rval = search_invt( tok->d_invindex_fd, &level, (void **) ses, - (search_callback_t) lastsess_level_lessthan ); + rval = search_invt(fsidp, tok->d_invindex_fd, &level, + (void **)ses, + (search_callback_t)lastsess_level_lessthan); return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; } - return invmgr_query_all_sessions((void *) &level, /* in */ - (void **) ses, /* out */ - (search_callback_t) lastsess_level_lessthan); + return invmgr_query_all_sessions(fsidp /* fs uuid */ + (void *)&level, /* in */ + (void **)ses, /* out */ + (search_callback_t)lastsess_level_lessthan); } - - - /*----------------------------------------------------------------------*/ -/* */ -/* */ +/* inv_lastsession_level_equalto */ +/* */ +/* Given a file system uuid, token that refers to a file system, and a */ +/* level, this populates ses with last time when a session of a lesser */ +/* level was done. */ +/* */ /* Return FALSE on an error, TRUE if not. If (*ses) is NULL, then the */ /* search failed. */ /*----------------------------------------------------------------------*/ @@ -666,21 +675,24 @@ inv_lastsession_level_lessthan( bool_t inv_lastsession_level_equalto( - inv_idbtoken_t tok, + uuid_t *fsidp, + inv_idbtoken_t tok, u_char level, inv_session_t **ses ) { int rval; if ( tok != INV_TOKEN_NULL ) { - rval = search_invt( tok->d_invindex_fd, &level, (void **) ses, - (search_callback_t) lastsess_level_equalto ); + rval = search_invt(fsidp, tok->d_invindex_fd, &level, + (void **)ses, + (search_callback_t)lastsess_level_equalto); return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; } - return invmgr_query_all_sessions((void *) &level, /* in */ - (void **) ses, /* out */ - (search_callback_t) lastsess_level_equalto); + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *)&level, /* in */ + (void **)ses, /* out */ + (search_callback_t)lastsess_level_equalto); } @@ -688,35 +700,45 @@ inv_lastsession_level_equalto( /*----------------------------------------------------------------------*/ /* inv_getsession_byuuid */ /* */ +/* Given a file system uuid and a session uuid , ses is populated with */ +/* the session that contains the matching system uuid. */ +/* */ +/* Returns FALSE on an error, TRUE if the session was found. */ /*----------------------------------------------------------------------*/ bool_t inv_get_session_byuuid( - uuid_t *sesid, - inv_session_t **ses) + uuid_t *fsidp, + uuid_t *sesid, + inv_session_t **ses) { - return (invmgr_query_all_sessions((void *)sesid, /* in */ - (void **) ses, /* out */ - (search_callback_t) stobj_getsession_byuuid)); + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *)sesid, /* in */ + (void **)ses, /* out */ + (search_callback_t)stobj_getsession_byuuid); } - - /*----------------------------------------------------------------------*/ -/* inv_getsession_byuuid */ +/* inv_getsession_bylabel */ /* */ +/* Given a file system uuid and a session uuid, ses is populated with */ +/* the session that contains the matching system label. */ +/* */ +/* Returns FALSE on an error, TRUE if the session was found. */ /*----------------------------------------------------------------------*/ bool_t inv_get_session_bylabel( - char *session_label, - inv_session_t **ses) + uuid_t *fsidp, + char *session_label, + inv_session_t **ses) { - return (invmgr_query_all_sessions((void *)session_label, /* in */ - (void **) ses, /* out */ - (search_callback_t) stobj_getsession_bylabel)); + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *)session_label, /* in */ + (void **)ses, /* out */ + (search_callback_t)stobj_getsession_bylabel); } @@ -786,8 +808,8 @@ inv_delete_mediaobj( uuid_t *moid ) return BOOL_FALSE; } - if ( search_invt( invfd, NULL, (void **)&moid, - (search_callback_t) stobj_delete_mobj ) + if (search_invt(&arr[i].ft_uuid, invfd, NULL, (void **)&moid, + (search_callback_t)stobj_delete_mobj) < 0 ) return BOOL_FALSE; /* we have to delete the session, etc */ Index: b/inventory/inv_mgr.c =================================================================== --- a/inventory/inv_mgr.c +++ b/inventory/inv_mgr.c @@ -134,8 +134,9 @@ get_sesstoken( inv_idbtoken_t tok ) /*---------------------------------------------------------------------------*/ bool_t invmgr_query_all_sessions ( - void *inarg, - void **outarg, + uuid_t *fsidp, + void *inarg, + void **outarg, search_callback_t func) { invt_counter_t *cnt; @@ -145,6 +146,7 @@ invmgr_query_all_sessions ( int result; inv_oflag_t forwhat = INV_SEARCH_ONLY; void *objectfound; + bool_t ret = BOOL_FALSE; /* if on return, this is still null, the search failed */ *outarg = NULL; @@ -157,7 +159,7 @@ invmgr_query_all_sessions ( } if ( fd < 0 || numfs <= 0 ) { mlog( MLOG_NORMAL | MLOG_INV, _("INV: Error in fstab\n") ); - return BOOL_FALSE; + return ret; } close( fd ); @@ -169,7 +171,7 @@ invmgr_query_all_sessions ( mlog( MLOG_NORMAL | MLOG_INV, _( "INV: Cant get inv-name for uuid\n") ); - return BOOL_FALSE; + continue; } strcat( fname, INV_INVINDEX_PREFIX ); invfd = open( fname, INV_OFLAG(forwhat) ); @@ -178,26 +180,27 @@ invmgr_query_all_sessions ( "INV: Open failed on %s\n"), fname ); - return BOOL_FALSE; + continue; } - result = search_invt( invfd, inarg, &objectfound, func ); + result = search_invt(fsidp, invfd, inarg, &objectfound, func); close(invfd); /* if error return BOOL_FALSE */ if (result < 0) { - return BOOL_FALSE; + return ret; } else if ((result == 1) && *outarg) { /* multiple entries found, more info needed */ *outarg = NULL; return BOOL_TRUE; } else if (result == 1) { *outarg = objectfound; + ret = BOOL_TRUE; } } /* return val indicates if there was an error or not. *buf says whether the search was successful */ - return BOOL_TRUE; + return ret; } @@ -213,10 +216,11 @@ invmgr_query_all_sessions ( intgen_t search_invt( - int invfd, - void *arg, - void **buf, - search_callback_t do_chkcriteria ) + uuid_t *fsidp, + int invfd, + void *arg, + void **buf, + search_callback_t do_chkcriteria) { int fd, i; @@ -247,7 +251,7 @@ search_invt( /* we need to get all the invindex headers and seshdrs in reverse order */ for (i = nindices - 1; i >= 0; i--) { - int nsess; + int nsess, j; invt_sescounter_t *scnt = NULL; invt_seshdr_t *harr = NULL; bool_t found; @@ -272,19 +276,34 @@ search_invt( } free ( scnt ); - while ( nsess ) { + for (j = nsess - 1; j >= 0; j--) { + invt_session_t ses; + /* fd is kept locked until we return from the callback routine */ /* Check to see if this session has been pruned * by xfsinvutil before checking it. */ - if ( harr[nsess - 1].sh_pruned ) { - --nsess; + if (harr[j].sh_pruned) { continue; } - found = (* do_chkcriteria ) ( fd, &harr[ --nsess ], - arg, buf ); + + /* if we need to check the fs uuid's and they don't + * match or we fail to get the session record, + * then keep looking + */ + if (fsidp) { + int ret = GET_REC_NOLOCK(fd, &ses, + sizeof(invt_session_t), + harr[j].sh_sess_off); + if (ret < 0) + return ret; + if (uuid_compare(ses.s_fsid, *fsidp)) + continue; + } + + found = (* do_chkcriteria)(fd, &harr[j], arg, buf); if (! found ) continue; /* we found what we need; just return */ Index: b/inventory/inv_priv.h =================================================================== --- a/inventory/inv_priv.h +++ b/inventory/inv_priv.h @@ -548,11 +548,12 @@ get_headerinfo( int fd, void **hdrs, voi size_t hdrsz, size_t cntsz, bool_t doblock ); bool_t -invmgr_query_all_sessions (void *inarg, void **outarg, search_callback_t func); +invmgr_query_all_sessions(uuid_t *fsidp, void *inarg, void **outarg, + search_callback_t func); intgen_t -search_invt( int invfd, void *arg, void **buf, - search_callback_t do_chkcriteria ); +search_invt(uuid_t *fsidp, int invfd, void *arg, void **buf, + search_callback_t do_chkcriteria); intgen_t invmgr_inv_print( int invfd, invt_pr_ctx_t *prctx); Index: b/inventory/inventory.h =================================================================== --- a/inventory/inventory.h +++ b/inventory/inventory.h @@ -247,32 +247,37 @@ inv_put_mediafile( */ extern bool_t inv_lasttime_level_lessthan( + uuid_t *fsidp, inv_idbtoken_t tok, - u_char level, - time32_t **time );/* out */ + u_char level, + time32_t **time); /* out */ extern bool_t inv_lastsession_level_lessthan( + uuid_t *fsidp, inv_idbtoken_t tok, u_char level, - inv_session_t **ses );/* out */ + inv_session_t **ses); /* out */ extern bool_t inv_lastsession_level_equalto( + uuid_t *fsidp, inv_idbtoken_t tok, u_char level, - inv_session_t **ses );/* out */ + inv_session_t **ses); /* out */ /* Given a uuid of a session, return the session structure.*/ extern bool_t inv_get_session_byuuid( - uuid_t *sesid, - inv_session_t **ses); + uuid_t *fsidp, + uuid_t *sesid, + inv_session_t **ses); extern bool_t inv_get_session_bylabel( - char *session_label, - inv_session_t **ses); + uuid_t *fsidp, + char *session_label, + inv_session_t **ses); /* on return, *ses is NULL */ Index: b/restore/content.c =================================================================== --- a/restore/content.c +++ b/restore/content.c @@ -2179,8 +2179,9 @@ content_stream_restore( ix_t thrdix ) if ( ! drivep->d_isnamedpipepr && ! drivep->d_isunnamedpipepr ) { - ok = inv_get_session_byuuid( &grhdrp->gh_dumpid, - &sessp ); + ok = inv_get_session_byuuid(NULL, + &grhdrp->gh_dumpid, + &sessp); if ( ok && sessp ) { mlog( MLOG_VERBOSE, _( "using online session inventory\n") ); @@ -3736,9 +3737,9 @@ Inv_validate_cmdline( void ) ok = BOOL_FALSE; sessp = 0; if ( tranp->t_reqdumpidvalpr ) { - ok = inv_get_session_byuuid( &tranp->t_reqdumpid, &sessp ); + ok = inv_get_session_byuuid(NULL, &tranp->t_reqdumpid, &sessp); } else if ( tranp->t_reqdumplabvalpr ) { - ok = inv_get_session_bylabel( tranp->t_reqdumplab, &sessp ); + ok = inv_get_session_bylabel(NULL, tranp->t_reqdumplab, &sessp); } rok = BOOL_FALSE; if ( ok && sessp ) { @@ -6812,13 +6813,15 @@ askinvforbaseof( uuid_t baseid, inv_sess /* get the base session */ if ( resumedpr ) { - ok = inv_lastsession_level_equalto( invtok, - ( u_char_t )level, - &basesessp ); + ok = inv_lastsession_level_equalto(&sessp->s_fsid, + invtok, + (u_char_t)level, + &basesessp); } else { - ok = inv_lastsession_level_lessthan( invtok, - ( u_char_t )level, - &basesessp ); + ok = inv_lastsession_level_lessthan(&sessp->s_fsid, + invtok, + (u_char_t)level, + &basesessp); } if ( ! ok ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_MEDIA, _( From darrick.wong@oracle.com Thu Sep 3 23:21:14 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 18E5D7FA7 for ; Thu, 3 Sep 2015 23:21:14 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 94994AC001 for ; Thu, 3 Sep 2015 21:21:10 -0700 (PDT) X-ASG-Debug-ID: 1441340468-04cbb06acc79b70001-NocioJ Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by cuda.sgi.com with ESMTP id 4jD2rbc2ohNreJOC (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 03 Sep 2015 21:21:08 -0700 (PDT) X-Barracuda-Envelope-From: darrick.wong@oracle.com X-Barracuda-Apparent-Source-IP: 141.146.126.69 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t844L6XS025060 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Sep 2015 04:21:06 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t844L50o018720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Sep 2015 04:21:06 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t844L5nS017100; Fri, 4 Sep 2015 04:21:05 GMT Received: from localhost (/24.21.154.84) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Sep 2015 21:21:05 -0700 Date: Thu, 3 Sep 2015 21:21:04 -0700 From: "Darrick J. Wong" To: david@fromorbit.com Cc: xfs@oss.sgi.com, sandeen@sandeen.net Subject: [PATCH] xfs_repair: release corrupt directory node buffer Message-ID: <20150904042104.GD10397@birch.djwong.org> X-ASG-Orig-Subj: [PATCH] xfs_repair: release corrupt directory node buffer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Barracuda-Connect: aserp1040.oracle.com[141.146.126.69] X-Barracuda-Start-Time: 1441340468 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22219 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines If repair encounters a dir node block that fails checksum or verification, free the buffer before the directory gets rebuilt. Reported-by: Eric Sandeen Signed-off-by: Darrick J. Wong --- repair/dir2.c | 1 + 1 file changed, 1 insertion(+) diff --git a/repair/dir2.c b/repair/dir2.c index a5646f8..54c49eb 100644 --- a/repair/dir2.c +++ b/repair/dir2.c @@ -200,6 +200,7 @@ _("bad dir magic number 0x%x in inode %" PRIu64 " bno = %u\n"), } /* corrupt node; rebuild the dir. */ if (bp->b_error == -EFSBADCRC || bp->b_error == -EFSCORRUPTED) { + libxfs_putbuf(bp); do_warn( _("corrupt tree block %u for directory inode %" PRIu64 "\n"), bno, da_cursor->ino); From sandeen@sandeen.net Thu Sep 3 23:27:19 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 05CC57FA8 for ; Thu, 3 Sep 2015 23:27:19 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id E8F7F304032 for ; Thu, 3 Sep 2015 21:27:15 -0700 (PDT) X-ASG-Debug-ID: 1441340833-04cbb06acb79d70001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id wid0jPYpnG9GgxtA for ; Thu, 03 Sep 2015 21:27:13 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 27CF96682A46; Thu, 3 Sep 2015 23:27:13 -0500 (CDT) Subject: Re: [PATCH] xfs_repair: release corrupt directory node buffer To: "Darrick J. Wong" , david@fromorbit.com X-ASG-Orig-Subj: Re: [PATCH] xfs_repair: release corrupt directory node buffer References: <20150904042104.GD10397@birch.djwong.org> Cc: xfs@oss.sgi.com From: Eric Sandeen Message-ID: <55E91DA0.7000306@sandeen.net> Date: Thu, 3 Sep 2015 23:27:12 -0500 MIME-Version: 1.0 In-Reply-To: <20150904042104.GD10397@birch.djwong.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441340833 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22219 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/3/15 11:21 PM, Darrick J. Wong wrote: > If repair encounters a dir node block that fails checksum or > verification, free the buffer before the directory gets rebuilt. > > Reported-by: Eric Sandeen > Signed-off-by: Darrick J. Wong Reviewed-by: Eric Sandeen > --- > repair/dir2.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/repair/dir2.c b/repair/dir2.c > index a5646f8..54c49eb 100644 > --- a/repair/dir2.c > +++ b/repair/dir2.c > @@ -200,6 +200,7 @@ _("bad dir magic number 0x%x in inode %" PRIu64 " bno = %u\n"), > } > /* corrupt node; rebuild the dir. */ > if (bp->b_error == -EFSBADCRC || bp->b_error == -EFSCORRUPTED) { > + libxfs_putbuf(bp); > do_warn( > _("corrupt tree block %u for directory inode %" PRIu64 "\n"), > bno, da_cursor->ino); > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From 3f0jpVQUPA2oQVNioOOZf.bcOaML.fghfNaWaa.aOQ.KWU@photos-server.bounces.google.com Fri Sep 4 02:30:13 2015 Return-Path: <3f0jpVQUPA2oQVNioOOZf.bcOaML.fghfNaWaa.aOQ.KWU@photos-server.bounces.google.com> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=5.0 tests=DEAR_SOMETHING,HTML_MESSAGE autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 10B517FAA for ; Fri, 4 Sep 2015 02:30:13 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 70ACDAC007 for ; Fri, 4 Sep 2015 00:30:12 -0700 (PDT) X-ASG-Debug-ID: 1441351808-04cb6c0e0d73f50001-NocioJ Received: from mail-ob0-f202.google.com (mail-ob0-f202.google.com [209.85.214.202]) by cuda.sgi.com with ESMTP id PTqcRKuLVubHk9Pi (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 04 Sep 2015 00:30:08 -0700 (PDT) X-Barracuda-Envelope-From: 3f0jpVQUPA2oQVNioOOZf.bcOaML.fghfNaWaa.aOQ.KWU@photos-server.bounces.google.com Received: by obcfb16 with SMTP id fb16so1052968obc.0 for ; Fri, 04 Sep 2015 00:30:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:reply-to:message-id:date:subject:from:to:content-type; bh=YmItFFBpFnasoXjXHI4SNxvYCQnTrn6atMR6NEdXKo8=; b=dKFWgXmwNGMSSyyet7C4cDVG5vd8jCoUVzOX7D3HiRTGyrsO58i2oiSQsQja3FA480 za6yTThzOqmTHMuONQxXtICgf6IYLmnFiQ6afTLRBV0/K4kNGO+XfCmfuuiCG0LvLDCw 2K79LJxp0+v/XFLL0kFNdogtbZyLF9JApWEn2U81biAd9SGdcquhhYNSn06nVn/ZjDij Oh7+ohOzqSfU0RswWQZkQJCvDNe1EXMcJbWA76QH4yuf1QW21RDHEcNcvY0w2zMdean+ bby/AzWB7UDC13dzk7G7FENS/oeLOgQrViZ1ggt8E/OaVPq1FIvaYh5G+beSS2FPmccE F/sg== MIME-Version: 1.0 X-Received: by 10.182.199.33 with SMTP id jh1mr2109151obc.45.1441351807821; Fri, 04 Sep 2015 00:30:07 -0700 (PDT) Reply-To: "Mould making/ Die-casting/ Precision stamping/ Machining parts/CNC Precision Parts Manufacturing" Message-ID: Date: Fri, 04 Sep 2015 07:30:07 +0000 Subject: =?GB2312?B?TW91bGQgbWFraW5nLyBEaWUtY2FzdGluZy8gUHJlY2lzaW9uIHN0YW1waW5nLyBNYWNoaQ==?= =?GB2312?B?bmluZyBwYXJ0cy9DTkMgUHJlY2lzaW9uIFBhcnRzIE1hbnVmYWN0dXJpbmfT68T6ubLP7cHL?= =?GB2312?B?z+Cy4aGj?= From: "Mould making/ Die-casting/ Precision stamping/ Machining parts/CNC Precision Parts Manufacturing" X-ASG-Orig-Subj: =?GB2312?B?TW91bGQgbWFraW5nLyBEaWUtY2FzdGluZy8gUHJlY2lzaW9uIHN0YW1waW5nLyBNYWNoaQ==?= =?GB2312?B?bmluZyBwYXJ0cy9DTkMgUHJlY2lzaW9uIFBhcnRzIE1hbnVmYWN0dXJpbmfT68T6ubLP7cHL?= =?GB2312?B?z+Cy4aGj?= To: xfs@oss.sgi.com Content-Type: multipart/related; boundary=e89a8ff1ca18806998051ee6de7c X-Barracuda-Connect: mail-ob0-f202.google.com[209.85.214.202] X-Barracuda-Start-Time: 1441351808 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22222 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --e89a8ff1ca18806998051ee6de7c Content-Type: multipart/alternative; boundary=e89a8ff1ca18806994051ee6de7b --e89a8ff1ca18806994051ee6de7b Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Dear Sir/Ms, Good day! As an ISO certified factory, we specialized manufacture Mould making/ Sheet metal process/ Die-casting/ Precision stamping/ Machining parts, with strong competitive price and excellent quality, for more than 20 years. Any questions and enquiries will be highly regarded. Just email us the drawing and detailed requirement, you will get a complete quotation with technical analysis within 24 hours. Your prompt reply is highly appreciated. Best regards sincerely! Michael ________________________________________ Shenzhen, China https://picasaweb.google.com/lh/sredir?uname=105423401121001619213&target=ALBUM&id=6112196526568809473&authkey=Gv1sRgCLO8v46ttN3rLg&invite=CNbdycoE&feat=email --e89a8ff1ca18806994051ee6de7b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
=D1=FB=C7=EB=C4=FA=B9=DB=BF=B4 Mould making/ Die-casting/ Precis= ion stamping/ Machining parts/CNC Precision Parts Manufacturing =B5=C4=CF= =E0=B2=E1=A3=BA Precision stamping Machini= ng parts
Precision stamping Machining parts
2015=C4=EA2=D4=C24=C8=D5
=CC=E1=B9=A9=D5=DF=A3=BAMould making/ Die-casting/ Precision stamping/ M= achining parts/CNC Precision Parts Manufacturing
=D2=AA=B7=D6=CF=ED=C4=FA=B5=C4=D5=D5=C6=AC=BB=F2=D4=DA=C5=F3=D3=D1= =D3=EB=C4=FA=B7=D6=CF=ED=D5=D5=C6=AC=CA=B1=CA=D5=B5=BD=CD=A8=D6=AA=A3=AC=C7= =EB=BB=F1=C8=A1=CA=F4=D3=DA=C4=FA= =D7=D4=BC=BA=B5=C4=C3=E2=B7=D1 Picasa =CD=F8=C2=E7=CF=E0=B2=E1=D5=CA=BB=A7<= /a>=A1=A3
--e89a8ff1ca18806994051ee6de7b-- --e89a8ff1ca18806998051ee6de7c Content-Type: image/gif; name="picasaweblogo-zh_CN.gif" Content-Disposition: attachment; filename="picasaweblogo-zh_CN.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhzQAfAOYAALu9v93e37C7wQClUJ99rtjd4OySN4mZovb3+Jmcn/f392uAi+ZXVcTM0eLm 6Kqtr9XW1+7v7wB6tObn53WIk+zu8LrEyaazubO1t3+RmsTGx/bJm87V2ZOiqpyqspGUl8De7MzO z9vP4fOrqkC8fKWFs+ff62Cs0P719aKkp4DSqO3n8OhiYPn3+vvr2sOuzLDjyet3dfPv9bGVvaDd vvbAwPnV1dXG3CCwZvrg4PGhoP758+yBgNDu34C92vCnXZDF3reewsDp1P3y5xCCufD69fD3+/TC j+6gUHd7f/O7gjCTwu2ZRJDYs4iMj72mxxCrW6uNuPS2tffQqICDh9Dm8eTn8OD06vGtaWF3g/// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5 BAAAAAAALAAAAADNAB8AAAf/gFqCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6iKKDo8DK4sPFIoqbS1tpcyTyI6rr2uIy47t8PExYQiJQQEIjW+vxs/LocVAtXWAg0VxtvclSLK 4DfNviMbBkzShQVZ7O3tHghaDgcc3fb3hSvg+y82LL3lDBj4IYzQuiwHEibMwK6DFgFZBOCbaC/K PnAzWuT4xyCgwCPq2BlqwM4BggbxihWg0GCBFpcUt327SCBIC0E5YnQ0J9DAEIMiDTG0MK8AoQYe DnSwkHJQBQsJLxi10CHl0w5Kmaq7kJBphQ4NBB3QQqFDhpjbZtB8UQhFDI8C/6cAzXLoQESIEuUx dLegnqCW7rJcWJDFqAPCfB0IQmDXHQULCMVqGZwX7bAWaw+hsMFTIJa5hyhkaYBXCwLCCy5wECC6 sBYO7Chg8+DOKGGWBSwQPqtlr4cGFlpHlqelgvFJCghNSG5oQoRFzLUoiB69mImLNxR1FgiaEALa WahF1EJ7geLFDA+czlJ10GF2BQ42dVCS5GhC4Mcm0gCgv///CQQwyAfRPRDCIf1JB0AADAaQwHNa aABBABqkEAAGDH4wwTbXgSPCItsZMJdCB+w1Hl4IsBMWIRUcgE0WCzQlCESF0ReRNoJcUBVDHhSC gGj6IbJgIgkMMuEgCnzQX/8CEBAypBZFDjgIAII0SKUWVxrTYQki+ACCdj1xN8hBgWXx2IwRHZQI RA75CJ8WjbFzgFSCvFnIBcMJKaAWATwwyAMODnIgBE1ioIEgfgoy4QMaBBilII9eaaUgWVpHQAkr nCDBl4mEOFd8oOKIpgDr8HZIaYa8iQBrgfUYVCEQBYkgBMmFAMGGWvgZpXO5KsBgBCEAgKsWEwSQ hAYBRPBBg4FSWiWDV1ZKjAyYaropmD0h0R0ieKnJLXuGVAAfAgXEQ24DjcHm2p15zqpBBA9Mp4EC GEApyAcYYKhAk1hKOwEVVy7bYKTPBhBtdcRYsYQEDHOKyHZKbHvqeIRZUMj/YaqxIyqahUF0QSF2 CcCjj4TJasiQ+QqiQID2SqfAgUaGgEGlGDwAQb2P2jsBAAn098DPPfOM7zZAMNwwJd5+KxGeCxiF HriiZdCUfYVBZt4gP2ZhgX0rmtaYyYUMGcIHEP7cshYHKhBBBE8G8EGTCvRncLOQTllwtN0YQYTR IJAwwN+ABw44CSHRteZ4COzVgQAeoKaYuqkJEGdh60XO6gLafC3ABaKVrMiCccPLJwQLRqnBAwDc urN/GPA775NOAGg3n9A6203RDfst+O4D9BASTEovNrmZ572GWDuAGSYcOwus+F1gGZAEtpMQHMrn ztI1qvIgG2Y5ZATd75kzy8G0G2x7N9b2zbvgNBiyql+IOCBA8fJYAz/WpAlggTYcWDzIatVAycWs EZb3fY5fgrBe3VTGn+R4b0+UEh8hyDcpLOFDU+pb39/aZxlKPOkQUUrBAyBkwQg6SYKDoGDtSngP H1RBd7zDAQw6WIkPIulmKRAECQWBIQYB6oT3YtajchiCABlsAjWLiQqgsDscNKEINKxEBBA2iB0W goRWDABzhkUs7ulQOs+ZjmV6AAMVqEAIV4iiGtfIxja68Y1wjKMc50jHOtpRFIEAADs= --e89a8ff1ca18806998051ee6de7c Content-Type: image/jpeg; name="email.jpg" Content-Disposition: attachment; filename="email.jpg" Content-Transfer-Encoding: base64 Content-ID: <6112196526568809473> /9j/4AAQSkZJRgABAQAAAQABAAD/4QB+RXhpZgAASUkqAAgAAAACADEBAgAHAAAAJgAAAGmHBAAB AAAALgAAAAAAAABHb29nbGUAAAMAAJAHAAQAAAAwMjIwAaADAAEAAAABAAAABaAEAAEAAABYAAAA AAAAAAIAAQACAAQAAABSOTgAAgAHAAQAAAAwMTAwAAAAAP/bAIQAAwICCAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICggICAgLCQkICAsYCggNCAgJCAEDBAQGBQYKBgYK DA0MDA0MDA0NDA0NDAwNDQwMDQwMDAwNDA0MDQwNDAwMDA0MDAwMDAwMDAwMDAwNDAwMDAwM/8AA EQgAkAB7AwERAAIRAQMRAf/EAB0AAQABBQEBAQAAAAAAAAAAAAAIAgQFBgcJAwH/xAA9EAACAQMC AwcBBgMHBAMAAAABAgMABBEFEgYhMQcIEyJBUXFhCRQjMkKBUpGhM2JygrHR8ENFc8EVFiT/xAAZ AQEAAwEBAAAAAAAAAAAAAAAAAQIDBAX/xAAkEQEBAAICAgIDAAMBAAAAAAAAAQIRITEDEkFRBBNh cZHBFP/aAAwDAQACEQMRAD8A9GIeg+BXO9tXQKBQKBQKBQKBQKBQKBQKBQUQ9B8CgroFAoFAoFAo FAoFAoFAoFAoKIeg+BQV0CgUCgUCgUCgUCgUCgUCgUFEPQfAoK6BQKBQKBQKBQKBQKBQKBQKCiHo PgUFdAoFAoFAoKXcAEkgAdSTgD5J5CpFSjIyOYPMEcwR9DUHBip0GKgKBQKBQKCiHoPgUFdAoFAo FBY63rcNtDJPcSJDDEpeSSRgqqqjJJJ+g6DJPsaItk5qGvDXeJXiXVryFFYWdrEDYwsVHiAS+HNc yISVaV90WwHPhRkgc2kLTLt5vl8ly/w+fZR2hQam90lrFfWNxZymC6geP7u8UgJAO+3k5htm4bir Y/RjBMySsbllj8uqaXrupRHy38xA9Jgsw+D4yO56ejir+n1tOPnyjaLHteu0A8VLeYY6qHt2/wBZ h8jYP93o2x/KvzGetu2mEkB7e4HTnGYXX19WkiY9B0X1p6VrPysb2vI+2bTuQeWWEnl+Nbzoo5Z5 yCNoxjpnfjPr61S42Np58L8tu0/UI5kWWJ0kjcZV0YMrD3BGR/sahtLL0uKhJQUQ9B8CgroFAoFB iOIuI0twoILyynbFEDguw6knoqLkFnPTIGGZlUyzzzmM5Qw782p3j2gd3YKrMpiXlHHuBVsKCQTt IHiMWJDdcHAzz24v2XK8ovd0HVTBrNmSVCTs1q+/8n4yFE3ewE3h/BAqMLzGec4r0j1VIrWOW4ch EihaaaSKX9MSluaggnCqcDp6da69acm7XDLHtN1W6Y3CC2tbVhmGO4tmuZmX0aRxPCBkekfTpk9a pPI09GI1ft+uraN3mtbKUKwX8KW5tXcYyWVJFu4xj/GOtW9kTFps3fd0g+W4tb2Bv4vCtbpF984k icj4XpVsc5C+Otz7P+8Jo2ouYLbUIvFOMRzrdWTN6bVMytASPZZD9Kt7RT1rq3ZPxZe22ozw3EZ+ 5FojBNHMjxMkqbJI5o9wkFxbzrv8QJseGVR+ZXzXKbdPh8nrZz2kua53rlBRF0HwP9KDHcS8T29n C9xdTR28EYy8kjBVHsB6sx9FUEk8sGnXaLZjN1FXtB+0g0y3YpY2014VODLKfusR/wAIdWkPyyp8 Vnc58Mb5vqOc2n2nV2XJbS7IxZ6LeShwOeAXMbJn/Lz+no91f25fTtXZ1389NvI5GuLa4s3jA2qW jnjmc8ljjkjwyl2wgMkarkjmKmZ4/K08v3GVHed0SHVI9NvrwLqsqxAh4XW2gNxiSCETlPDRmV0A JbmHQkgvk6zThzyuV2te9RwkbnTbvI8w68v7pCtj3OxMn1JPvUZTe2curHmLwJqrW8wZfzwyrKn/ AJImWRP5OuK5nQ9Vu1TTjqOhX3hNG33vS5JYiuA5V4BOFABzlkypC56mu6848fTik1lyh/2Hce26 QT2yPJKFaNxJK5kJV1KhUD7xHGNm5UUKPOTgkknlw5dNmmgd4biZWISLkoBJxnmT8YH9KvSIwXVq 0jHJOKjay6s9M2kEEjB6jqD9D6H61XadJqd1PtskuQNMvW8SRVJs52QNIwjBYwOww7FFG5GJJ2qV 54Wt/Hn8Vz+TH5j0a4M1n7xaxS5y23a+AR508rcjz5kZ/cUymnqeHP2xlZmqNmucc8c22m2U19dv sgt49zEc2Y8gkaL+qSRiEVfUkUvCLl6zbyO7yXebvtZuHklfw4lZhb2ysTHboc4VcYEku3lJOcb2 zjYvlrn5yu64sst81H62gMjb5HYn2ydo/YY/56VPtJxGe2y2epPGjxq58OT88eAY39PMuMH/ANVa VL5XXEPhpKIh4LSkKRFvCwKBzMW95GDSHDA5wnXJACisxRtNLsP0bQOOZrd9SkurPiGyjtxdQWk0 SR6zBaEeFOizxyneowlwkMkciJs8zoIivTJwpeE7uL+HDNa3cZ84aFtpI57o8OAefXCsBn096tpj Zw8c+LdKNpqdxD02zSAfs+R/MNXJXTLvl6l9z7WfvvD1kScvaGWycEblAgkJh3e3/wCaSH/ma6fH eGGc5aHw33CVguNVaCVVgu7wXVpGScxRNEC8HXmsM5l8Pl/YtGOqtVpjFcrWhdrvcouEidwyuADz BBOcH061Nx+ke1naNHFvdavbbTY9RMZ8GWSQbx7I5TH0yQcZxmufPG4unHKVxFsLyI6en+9RFrGT 4G4vkgv7OWIkPHcwlQp6neARy58wSP3qf6pZw9luyLVQHlt8YDfip59wzyDADrzHM/4c+tdWc3yt +Llzca6ZisHpID/aN9p7PdaZoMJ/NE1/c8+jOfAtAQOu1Bdvg4G7wz1UYzzvDn8t50gDxzCqzuiE FI/Kp9+Q559QccvpjrmsvZzVh7SGokRF/tfy7F3ZYDmcdfXOCMAcyTU26TX5o2pRJHKrx+JLLlhK WJ2xgkDAxgDALNy8ysvNduDSZ23SMbGOhM9rJFcQu8EqMs0EsbbZI2Una6MOasOYH0yOYJB6Zkix 6c9zfv8AtvqrJputMlpqDYSK58qWd8WXwyDkAWt0xYsYyxjlP5SrExjWX7UyxRj76HBZstakO0qH KvzB+sZOT7nB/lWHk4yWw6Sk+zG43BTU7AkklYLyNcjJODby7c+pxAPk1p4r3EZx2bu294r/AOyD UIZLCWwutOm2TwGUuMF3UKW2rtmGwh05EE+wydccuWWWOo2LjLsruJTmK8v4UY+aP8GdAPTazmNh /mZ8VvthZHJtb7vF28bQPql9JAzFvBns4Jokds5KL96XaffAzmss8Pbtpjn69OC8TfZ3F2Zk1GZc 5/7chAyfULeD1Ppms54tNP3MV2fdwSKxvFur28uLtYj4kMUdh4K+IhBUyt96m3hTzCgAH1zWkwUv lSX4T7V7e31eysJpHS5uIWmjWSDw1lTe0LrHJuwZVw0hjUE7AW6A4vlZ0eK2ZTL+6ScK1zvbeefa pw7HqPaPFbThlQ2tnb5TBZgtuZlI3AgHfKV6Y/rWVm7quPy3VQR4z01oryeJlKmOZ0KnqNrEEH6j GKy9WK1hgyQP3/ar9NGU1BmSGQjqI2x8leX9TWVVq34DtQZ5TkZSPaoI9iqY/kprll5Vxk2s+L4M TOkKnGxCy9dpPNgvsMY5fPsMd2NTXw4e4fe53GJN6g7D0wWxzHP3/frVrddojpnFet6lPbRRXkjX AgTw4HnYyTRxjpEZSWd0jP5Q5YoAFBVQAMrlL8rSaWPYN2wapomrwX9rgGIsssUpbwZoHGHjcrny MOalQdrBW5lVxtLMeVby9J+HftDNPKtKNDvklmKtO0J08CRwNuTK9xBLLgclaSMMB6Vpj5MbyysW 2p9/+x550jVcDmdlzY8h7lV1A8x68qt+zHHtnZWran9ovpi7c6VrJzkjbPZdB1J233ryx1z9Mco/ fj/UWVrzd/Szugxg0bWjtAz+JbsOfLnsuHOcZ5HmcfQ1X/04TjlT1t+L/p+6X3rhc58LRdaVhhdj iEEn+7lyScZ/50vPPjftaePKts4etb/UZIJxw5qSPGS8E949nA1uXwrMrzyJKm4DmIlbcADhvKav 7TLlrj4c/hMXTJHMcfigLJsXxFDbgHwNwDYG4Zzg4GfYVR6+M45QI+0IsH0vVdC4htyULn7nM6kg ia3/AB7b06vEbgcz/wBFRjrWOUvcYeWfKNPei4A23SavblXsdY3XUTodwjuG81zbSEKoSRJGLBcD KMpGR0rN1yuL2rYcZ+KirstfrmGT2CEn4Xmf6CsMrwXprfDd3suJsnHNsY5k4foAObE5wAOprLFT HtuUF14UoZwDIZBK6AjIZQFjiJ6ZQYU8yPEkP8Jxv206Sv7j3Y3Fr1jqcN5AIorW4QWd9CgiuVuJ /EluUbK7biI5ikCS7/D3bQVBwNccZlOV/Fj7bW3bL3ONa07xJoV/+UtVJbMClpgo9Xtf7QYHUwGU DryFY5eKxNwsRQ1zVSkxSdPDIU4jIYPnqMq2PcHn6VEsnbluXOq7V2EifVpEgTh0aqOhntkSwjiX pumu/AawJHUgrvOP1HFbYZ36JjbeN/8AE5+D+5TooSKS80yASg7mtxKs8ef4ZJVtrUyj3QIE9POM 56O3Vh+PrnKpBWulRRqqJFGiIoVERFVVVRgKqqAFUDkAAABR16n0uI4wOgA+ABUmo+gkqDUfhap2 PyoHO+3DsSs+INMk029DiN9kkUsZxLb3EYPhTx58paMk+VwVdSykYNSrlj7TVeWnFb6lwtPcaBrM KXVnLl4C4b7vcxgkJd2cmd0Uq/rQHfC+VO5dpfm8mFl3HJrXFcf1OBCzGE5jJJRWYM6r6KWAUMR/ FtGfaq7+1dPtayEoythQVIJbPQjB9h0PvVbpOqtoNVtrcgQL4ly3LxT533HkfAiX9WM8xuI5nK+j HCq6k7Y6O5kllWK3U3F1KyxIkXnO+QhVhjIJV5nY7WZSVXcVDHMjVt6q9vbju5dkg0PRrLTyQ06R iS7dej3coDTkdfIr/hpzPkRa1k1Hfhj6x0sGpXY3WOGra4AFxbW84HTxoY5cfHiI2KWS9o1F9bwK ihEVURRhVQBVAHQBQAAB7AVO08R9KgKBQKBQKCiLoPgf6UGJ4s4NtL+Bra9toLu3f80NxEksZPvt cEBh6MMEe4oal7R2l+zw0KN5ns3urPxs7oibe8gAJyFRL2Cd0VTuK7JlIyBnCqBFxjP9c+Ee+0v7 KO6WOR9N1VbpxlltriH7mzjl5RcrJcxgjzbQYEBBUb1wWMeuulMvFftEHtO7IL3RzJaXVnPp8hRe UibvvY3edRdglZU25cLG5Q7Su0ZrPLKzty5YWM92M93PV57Vtdt4pYbWzlQw3SHDi5jYMs0SdZIb eRQJX/IGITJxJtm25Y8EwutvZTsk47fULGKaaPwLtfwb23yD4N3HgTICOqMfxI2/VG6mtMeZu9/L vwu43KpWKBQKBQKBQKBQUQ9B8CgroFAobYziLhm3vIWt7uCG5gf88NxEk0Te2UkDKce+Kd9i6tdN jSMQpGiRKnhrEqKsax4xsCKAoTHLaBjFBhODuzy0sA33aIRl1iSR8sWkWBPDi3knBKJ5QcAke9ES SdNkokoFAoFAoFAoFBRD0HwKCugUCgUCgUCgUCgUCgUCgUCgoh6D4FBXQKBQKBQKBQKBQKBQKBQK BQUQ9B8CgroFAoFAoFAoFAoFAoFAoFAoP//Z --e89a8ff1ca18806998051ee6de7c-- From billodo@redhat.com Fri Sep 4 07:55:47 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 5EFD57F3F for ; Fri, 4 Sep 2015 07:55:47 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 30AF18F804C for ; Fri, 4 Sep 2015 05:55:47 -0700 (PDT) X-ASG-Debug-ID: 1441371345-04bdf06dd9826e0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id dJJq2wCDaBYInMaZ (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 05:55:45 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 9EFC1A2C0A for ; Fri, 4 Sep 2015 12:55:45 +0000 (UTC) Received: from localhost.localdomain.com (vpn-58-74.rdu2.redhat.com [10.10.58.74]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84Cti6q001002 for ; Fri, 4 Sep 2015 08:55:45 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs Date: Fri, 4 Sep 2015 07:55:17 -0500 X-ASG-Orig-Subj: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs Message-Id: <1441371319-31625-2-git-send-email-billodo@redhat.com> In-Reply-To: <1441371319-31625-1-git-send-email-billodo@redhat.com> References: <1441371319-31625-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441371345 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Currently, xfs global stats are in procfs. This patch introduces (replicates) the global stats in sysfs. Additionally a stats_clear file is introduced in sysfs. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_stats.h | 2 ++ fs/xfs/xfs_super.c | 20 +++++++++---- fs/xfs/xfs_sysctl.c | 15 ++-------- fs/xfs/xfs_sysfs.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_sysfs.h | 1 + 6 files changed, 179 insertions(+), 17 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index f224038..6008e25 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -29,6 +29,89 @@ static int counter_val(int idx) return val; } +int xfs_stats_format(char *buf) +{ + int i, j; + int len = 0; + __uint64_t xs_xstrat_bytes = 0; + __uint64_t xs_write_bytes = 0; + __uint64_t xs_read_bytes = 0; + + static const struct xstats_entry { + char *desc; + int endpoint; + } xstats[] = { + { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, + { "abt", XFSSTAT_END_ALLOC_BTREE }, + { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, + { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, + { "dir", XFSSTAT_END_DIRECTORY_OPS }, + { "trans", XFSSTAT_END_TRANSACTIONS }, + { "ig", XFSSTAT_END_INODE_OPS }, + { "log", XFSSTAT_END_LOG_OPS }, + { "push_ail", XFSSTAT_END_TAIL_PUSHING }, + { "xstrat", XFSSTAT_END_WRITE_CONVERT }, + { "rw", XFSSTAT_END_READ_WRITE_OPS }, + { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, + { "icluster", XFSSTAT_END_INODE_CLUSTER }, + { "vnodes", XFSSTAT_END_VNODE_OPS }, + { "buf", XFSSTAT_END_BUF }, + { "abtb2", XFSSTAT_END_ABTB_V2 }, + { "abtc2", XFSSTAT_END_ABTC_V2 }, + { "bmbt2", XFSSTAT_END_BMBT_V2 }, + { "ibt2", XFSSTAT_END_IBT_V2 }, + { "fibt2", XFSSTAT_END_FIBT_V2 }, + /* we print both series of quota information together */ + { "qm", XFSSTAT_END_QM }, + }; + + /* Loop over all stats groups */ + + for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { + len += snprintf(buf + len, PATH_MAX - len, "%s", + xstats[i].desc); + /* inner loop does each group */ + for (; j < xstats[i].endpoint; j++) + len += snprintf(buf + len, PATH_MAX - len, " %u", + counter_val(j)); + len += snprintf(buf + len, PATH_MAX - len, "\n"); + } + /* extra precision counters */ + for_each_possible_cpu(i) { + xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; + xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; + xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; + } + + len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", + xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); + len += snprintf(buf+len, PATH_MAX-len, "debug %u\n", +#if defined(DEBUG) + 1); +#else + 0); +#endif + +return len; +} + +void xfs_stats_clearall(void) +{ + int c; + __uint32_t vn_active; + + xfs_notice(NULL, "Clearing xfsstats"); + for_each_possible_cpu(c) { + preempt_disable(); + /* save vn_active, it's a universal truth! */ + vn_active = per_cpu(xfsstats, c).vn_active; + memset(&per_cpu(xfsstats, c), 0, + sizeof(struct xfsstats)); + per_cpu(xfsstats, c).vn_active = vn_active; + preempt_enable(); + } +} + static int xfs_stat_proc_show(struct seq_file *m, void *v) { int i, j; diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index c8f238b..18807b5 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -18,6 +18,8 @@ #ifndef __XFS_STATS_H__ #define __XFS_STATS_H__ +int xfs_stats_format(char *buf); +void xfs_stats_clearall(void); #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 3bf503a..31ad281 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -61,6 +61,7 @@ static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; static struct kset *xfs_kset; /* top-level xfs sysfs dir */ +static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ #ifdef DEBUG static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ #endif @@ -1838,19 +1839,25 @@ init_xfs_fs(void) xfs_kset = kset_create_and_add("xfs", NULL, fs_kobj); if (!xfs_kset) { error = -ENOMEM; - goto out_sysctl_unregister;; + goto out_sysctl_unregister; } + xfs_stats_kobj.kobject.kset = xfs_kset; + error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, + "stats"); + if (error) + goto out_kset_unregister; + #ifdef DEBUG xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_kset_unregister; + goto out_remove_stats_kobj; #endif error = xfs_qm_init(); if (error) - goto out_remove_kobj; + goto out_remove_dbg_kobj; error = register_filesystem(&xfs_fs_type); if (error) @@ -1859,11 +1866,13 @@ init_xfs_fs(void) out_qm_exit: xfs_qm_exit(); - out_remove_kobj: + out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_kset_unregister: + out_remove_stats_kobj: #endif + xfs_sysfs_del(&xfs_stats_kobj); + out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: xfs_sysctl_unregister(); @@ -1889,6 +1898,7 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif + xfs_sysfs_del(&xfs_stats_kobj); kset_unregister(xfs_kset); xfs_sysctl_unregister(); xfs_cleanup_procfs(); diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c index a0c8067..5defabb 100644 --- a/fs/xfs/xfs_sysctl.c +++ b/fs/xfs/xfs_sysctl.c @@ -19,6 +19,7 @@ #include #include #include "xfs_error.h" +#include "xfs_stats.h" static struct ctl_table_header *xfs_table_header; @@ -31,22 +32,12 @@ xfs_stats_clear_proc_handler( size_t *lenp, loff_t *ppos) { - int c, ret, *valp = ctl->data; - __uint32_t vn_active; + int ret, *valp = ctl->data; ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); if (!ret && write && *valp) { - xfs_notice(NULL, "Clearing xfsstats"); - for_each_possible_cpu(c) { - preempt_disable(); - /* save vn_active, it's a universal truth! */ - vn_active = per_cpu(xfsstats, c).vn_active; - memset(&per_cpu(xfsstats, c), 0, - sizeof(struct xfsstats)); - per_cpu(xfsstats, c).vn_active = vn_active; - preempt_enable(); - } + xfs_stats_clearall(); xfs_stats_clear = 0; } diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index aa03670..3704873 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -21,6 +21,7 @@ #include "xfs_log_format.h" #include "xfs_log.h" #include "xfs_log_priv.h" +#include "xfs_stats.h" struct xfs_sysfs_attr { struct attribute attr; @@ -38,6 +39,8 @@ to_attr(struct attribute *attr) static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RW(name) #define XFS_SYSFS_ATTR_RO(name) \ static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RO(name) +#define XFS_SYSFS_ATTR_WO(name) \ + static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_WO(name) #define ATTR_LIST(name) &xfs_sysfs_attr_##name.attr @@ -125,6 +128,78 @@ struct kobj_type xfs_dbg_ktype = { #endif /* DEBUG */ + +/* stats */ + +STATIC ssize_t +stats_show( + char *buf, + void *data) +{ + return xfs_stats_format(buf); +} +XFS_SYSFS_ATTR_RO(stats); + +STATIC ssize_t +stats_clear_store( + const char *buf, + size_t count, + void *data) +{ + int ret; + int val; + + ret = kstrtoint(buf, 0, &val); + if (ret) + return ret; + + if (val != 1) + return -EINVAL; + xfs_stats_clearall(); + return count; +} +XFS_SYSFS_ATTR_WO(stats_clear); + +static struct attribute *xfs_stats_attrs[] = { + ATTR_LIST(stats), + ATTR_LIST(stats_clear), + NULL, +}; + +STATIC ssize_t +xfs_stats_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; +} + +STATIC ssize_t +xfs_stats_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; +} + +static struct sysfs_ops xfs_stats_ops = { + .show = xfs_stats_show, + .store = xfs_stats_store, +}; + +struct kobj_type xfs_stats_ktype = { + .release = xfs_sysfs_release, + .sysfs_ops = &xfs_stats_ops, + .default_attrs = xfs_stats_attrs, +}; + /* xlog */ STATIC ssize_t diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h index 240eee3..be692e5 100644 --- a/fs/xfs/xfs_sysfs.h +++ b/fs/xfs/xfs_sysfs.h @@ -22,6 +22,7 @@ extern struct kobj_type xfs_mp_ktype; /* xfs_mount */ extern struct kobj_type xfs_dbg_ktype; /* debug */ extern struct kobj_type xfs_log_ktype; /* xlog */ +extern struct kobj_type xfs_stats_ktype; /* stats */ static inline struct xfs_kobj * to_kobj(struct kobject *kobject) -- 2.4.3 From billodo@redhat.com Fri Sep 4 07:55:47 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 7D2847F5A for ; Fri, 4 Sep 2015 07:55:47 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 6CF848F804B for ; Fri, 4 Sep 2015 05:55:47 -0700 (PDT) X-ASG-Debug-ID: 1441371346-04cbb06aca856d0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 1xyzyxWdizMNUCNY (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 05:55:46 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 2AA55A2C34 for ; Fri, 4 Sep 2015 12:55:46 +0000 (UTC) Received: from localhost.localdomain.com (vpn-58-74.rdu2.redhat.com [10.10.58.74]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84Cti6r001002 for ; Fri, 4 Sep 2015 08:55:45 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Date: Fri, 4 Sep 2015 07:55:18 -0500 X-ASG-Orig-Subj: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-Id: <1441371319-31625-3-git-send-email-billodo@redhat.com> In-Reply-To: <1441371319-31625-1-git-send-email-billodo@redhat.com> References: <1441371319-31625-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441371346 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 6008e25..734b867 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -244,9 +244,12 @@ xfs_init_procfs(void) if (!proc_mkdir("fs/xfs", NULL)) goto out; - if (!proc_create("fs/xfs/stat", 0, NULL, - &xfs_stat_proc_fops)) + if (!proc_symlink("fs/xfs/stat", NULL, + "/sys/fs/xfs/stats/stats")) + { goto out_remove_xfs_dir; + } + #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, &xqmstat_proc_fops)) -- 2.4.3 From billodo@redhat.com Fri Sep 4 07:55:49 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id C4F007FB1 for ; Fri, 4 Sep 2015 07:55:49 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id A4F368F8059 for ; Fri, 4 Sep 2015 05:55:46 -0700 (PDT) X-ASG-Debug-ID: 1441371345-04cbb06acb856c0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id I0YFlIhak6fpEw5H (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 05:55:46 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 1E57991DAC for ; Fri, 4 Sep 2015 12:55:45 +0000 (UTC) Received: from localhost.localdomain.com (vpn-58-74.rdu2.redhat.com [10.10.58.74]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84Cti6p001002 for ; Fri, 4 Sep 2015 08:55:44 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 0/3 V2] xfs: new global stats in sysfs Date: Fri, 4 Sep 2015 07:55:16 -0500 X-ASG-Orig-Subj: [PATCH 0/3 V2] xfs: new global stats in sysfs Message-Id: <1441371319-31625-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441371345 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi all- Here is the second pass at a series to add new global stats to sysfs. As a part of that, the /proc/fs/xfs/stat file becomes a symlink to the sysfs stats entry. The series provides the beginnings of the infrastructure for per-fs stats (in addition to global accumulative stats). We already have per-fs information in /sys, so it makes sense to have per-fs stats there too. As a first step, moving existing global stats infrastructure to /sys will allow us to re-use that sysfs code for per-fs stats as well. Patch 1 handles the bring-up and tear down of xfs/stats directory structure in sysfs when an fs is mounted. The directory contains the stats file and the stats_clear file. The stats file contents mimic those of /proc/fs/xfs/stat. The stats_clear file is empty, and much like the current stat_clear command, handles the zeroing of the stats file when a "1" is echoed to the stats_clear file. Patch 2 creates the symlink for stats from procfs to sysfs. Patch 3 removes the now unused portions of procfs for stat. Again, comments and questions are welcome. Thanks- Bill From billodo@redhat.com Fri Sep 4 07:55:52 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id CFCE07FBA for ; Fri, 4 Sep 2015 07:55:51 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 57CBCAC001 for ; Fri, 4 Sep 2015 05:55:48 -0700 (PDT) X-ASG-Debug-ID: 1441371346-04cbb06acc856e0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id qN5nnT2PyVldIwAk (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 05:55:47 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id AA9C01BE372 for ; Fri, 4 Sep 2015 12:55:46 +0000 (UTC) Received: from localhost.localdomain.com (vpn-58-74.rdu2.redhat.com [10.10.58.74]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84Cti6s001002 for ; Fri, 4 Sep 2015 08:55:46 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 3/3] xfs: remove unused procfs code Date: Fri, 4 Sep 2015 07:55:19 -0500 X-ASG-Orig-Subj: [PATCH 3/3] xfs: remove unused procfs code Message-Id: <1441371319-31625-4-git-send-email-billodo@redhat.com> In-Reply-To: <1441371319-31625-1-git-send-email-billodo@redhat.com> References: <1441371319-31625-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441371347 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch removes the now unused procfs code that was xfs stat specific. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 74 ------------------------------------------------------ 1 file changed, 74 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 734b867..4bcac05 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -112,80 +112,6 @@ void xfs_stats_clearall(void) } } -static int xfs_stat_proc_show(struct seq_file *m, void *v) -{ - int i, j; - __uint64_t xs_xstrat_bytes = 0; - __uint64_t xs_write_bytes = 0; - __uint64_t xs_read_bytes = 0; - - static const struct xstats_entry { - char *desc; - int endpoint; - } xstats[] = { - { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, - { "abt", XFSSTAT_END_ALLOC_BTREE }, - { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, - { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, - { "dir", XFSSTAT_END_DIRECTORY_OPS }, - { "trans", XFSSTAT_END_TRANSACTIONS }, - { "ig", XFSSTAT_END_INODE_OPS }, - { "log", XFSSTAT_END_LOG_OPS }, - { "push_ail", XFSSTAT_END_TAIL_PUSHING }, - { "xstrat", XFSSTAT_END_WRITE_CONVERT }, - { "rw", XFSSTAT_END_READ_WRITE_OPS }, - { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, - { "icluster", XFSSTAT_END_INODE_CLUSTER }, - { "vnodes", XFSSTAT_END_VNODE_OPS }, - { "buf", XFSSTAT_END_BUF }, - { "abtb2", XFSSTAT_END_ABTB_V2 }, - { "abtc2", XFSSTAT_END_ABTC_V2 }, - { "bmbt2", XFSSTAT_END_BMBT_V2 }, - { "ibt2", XFSSTAT_END_IBT_V2 }, - { "fibt2", XFSSTAT_END_FIBT_V2 }, - /* we print both series of quota information together */ - { "qm", XFSSTAT_END_QM }, - }; - - /* Loop over all stats groups */ - for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { - seq_printf(m, "%s", xstats[i].desc); - /* inner loop does each group */ - for (; j < xstats[i].endpoint; j++) - seq_printf(m, " %u", counter_val(j)); - seq_putc(m, '\n'); - } - /* extra precision counters */ - for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; - } - - seq_printf(m, "xpc %Lu %Lu %Lu\n", - xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); - seq_printf(m, "debug %u\n", -#if defined(DEBUG) - 1); -#else - 0); -#endif - return 0; -} - -static int xfs_stat_proc_open(struct inode *inode, struct file *file) -{ - return single_open(file, xfs_stat_proc_show, NULL); -} - -static const struct file_operations xfs_stat_proc_fops = { - .owner = THIS_MODULE, - .open = xfs_stat_proc_open, - .read = seq_read, - .llseek = seq_lseek, - .release = single_release, -}; - /* legacy quota interfaces */ #ifdef CONFIG_XFS_QUOTA static int xqm_proc_show(struct seq_file *m, void *v) -- 2.4.3 From cmaiolino@redhat.com Fri Sep 4 07:59:44 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 421CA7F3F for ; Fri, 4 Sep 2015 07:59:44 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id CC41BAC001 for ; Fri, 4 Sep 2015 05:59:43 -0700 (PDT) X-ASG-Debug-ID: 1441371582-04cbb06aca85870001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id A8XCVwj5Xqq1EN5g (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 05:59:42 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 1DC1E550D2; Fri, 4 Sep 2015 12:59:42 +0000 (UTC) Received: from zion.maiolino (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84CxciO011347 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 4 Sep 2015 08:59:40 -0400 Date: Fri, 4 Sep 2015 14:59:38 +0200 From: Carlos Maiolino To: "Darrick J. Wong" Cc: david@fromorbit.com, sandeen@sandeen.net, xfs@oss.sgi.com Subject: Re: [PATCH] xfs_repair: release corrupt directory node buffer Message-ID: <20150904125938.GA2821@zion.maiolino> X-ASG-Orig-Subj: Re: [PATCH] xfs_repair: release corrupt directory node buffer Mail-Followup-To: "Darrick J. Wong" , david@fromorbit.com, sandeen@sandeen.net, xfs@oss.sgi.com References: <20150904042104.GD10397@birch.djwong.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150904042104.GD10397@birch.djwong.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1441371582 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 03, 2015 at 09:21:04PM -0700, Darrick J. Wong wrote: > If repair encounters a dir node block that fails checksum or > verification, free the buffer before the directory gets rebuilt. > > Reported-by: Eric Sandeen > Signed-off-by: Darrick J. Wong > --- > repair/dir2.c | 1 + > 1 file changed, 1 insertion(+) > Makes sense. Reviewed-by: Carlos Maiolino > diff --git a/repair/dir2.c b/repair/dir2.c > index a5646f8..54c49eb 100644 > --- a/repair/dir2.c > +++ b/repair/dir2.c > @@ -200,6 +200,7 @@ _("bad dir magic number 0x%x in inode %" PRIu64 " bno = %u\n"), > } > /* corrupt node; rebuild the dir. */ > if (bp->b_error == -EFSBADCRC || bp->b_error == -EFSCORRUPTED) { > + libxfs_putbuf(bp); > do_warn( > _("corrupt tree block %u for directory inode %" PRIu64 "\n"), > bno, da_cursor->ino); > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- Carlos From contact@caudalie12.eu Fri Sep 4 10:55:06 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=5.0 tests=HTML_IMAGE_RATIO_02, HTML_MESSAGE,T_DKIM_INVALID,T_KHOP_FOREIGN_CLICK autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 7C51A7FB3 for ; Fri, 4 Sep 2015 10:55:06 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3B95B8F8078 for ; Fri, 4 Sep 2015 08:55:02 -0700 (PDT) X-ASG-Debug-ID: 1441382098-04bdf06dd8879a0001-NocioJ Received: from vps.hay293.eu (vps.hay293.eu [93.115.96.82]) by cuda.sgi.com with ESMTP id lr4cEK5KFsECRz04 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 08:55:00 -0700 (PDT) X-Barracuda-Envelope-From: contact@caudalie12.eu X-Barracuda-Apparent-Source-IP: 93.115.96.82 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=caudalie12.eu; s=itek; t=1441382098; bh=4wGwT+9bEi6SLkt4Pj0V0KaetOYZcy1cdhotoNx4LL4=; h=Date:From:To:Reply-to:Subject:From; b=HEV/+t4J8RfJ8ogemeRrYjIUqsiYLsVRkIEFM625hK98B2f1bhjP4UZlfVfemsZ1J L92dzF7MS6RFLb9m4CFoFxfbBkiwpUCKKpwCf9lL1i35LpHu/8waii83i7+J2+FOSe oJ+okTeQcbbThIj+M5h94Aqunv9qvCglsb9tyKOQ= Date: Fri, 04 Sep 2015 17:54:48 +0000 From: Armee de Terre To: xfs@oss.sgi.com Reply-To: Armee de Terre User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/6.0; Microsoft Outlook 15.0.4420) MIME-Version: 1.0 Subject: Armee de Terre : 10 000 postes a pourvoir Content-Type: multipart/alternative; boundary="------------090601090809080806020402" X-ASG-Orig-Subj: Armee de Terre : 10 000 postes a pourvoir X-Barracuda-Connect: vps.hay293.eu[93.115.96.82] X-Barracuda-Start-Time: 1441382100 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.49 X-Barracuda-Spam-Status: No, SCORE=1.49 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC7_SA_HREF_WWW_MISMATCH, DKIM_SIGNED, DKIM_VERIFIED, HTML_IMAGE_RATIO_02, HTML_MESSAGE, MISSING_MID X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22230 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.80 BSF_SC7_SA_HREF_WWW_MISMATCH BODY: Custom Phishing Mismatch 0.14 MISSING_MID Missing Message-Id: header -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.55 HTML_IMAGE_RATIO_02 BODY: HTML has a low ratio of text to image area 0.00 HTML_MESSAGE BODY: HTML included in message Message-Id: <20150904155502.AE99BA4217F@cuda.sgi.com> This is a multi-part message in MIME format. --------------090601090809080806020402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pour consulter la verssion en ligne,cliquez ici Pour moi, pour les autres, sengager.fr L'Armée de Terre L'Armée de Terre L'Armée de Terre De CAP à BAC +5, l'Armée de Terre recrute + DE 10 000 POSTES À POURVOIR L'Armée de Terre L'Armée de Terre L'Armée de Terre Pour une expérience professionnelle hors du commun Pour acquérir des savoir-faire et un savoir-être pour la vie Pour exercer un métier utile pour vous et pour les autres L'Armée de Terre L'Armée de Terre L'Armée de Terre Découvrez nos offres L'Armée de Terre L'Armée de Terre Tous nos emplois sur www.sengager.fr Pour retirer votre adresse email,c'est la --------------090601090809080806020402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Pour consulter la verssion en ligne,cliquez ici
Pour moi, pour les autres, sengager.fr L'Armée de Terre
L'Armée de Terre
L'Armée de Terre De CAP à BAC +5,
l'Armée de Terre recrute
+ DE 10 000 POSTES À POURVOIR
L'Armée de Terre
L'Armée de Terre L'Armée de Terre Pour une expérience professionnelle
hors du commun

Pour acquérir des savoir-faire et un
savoir-être pour la vie

Pour exercer un métier utile
pour vous et pour les autres 		L'Armée de Terre
L'Armée de Terre
L'Armée de Terre Découvrez nos offres L'Armée de Terre
L'Armée de Terre
Tous nos emplois sur www.sengager.fr
Pour retirer votre adresse email,c'est la
--------------090601090809080806020402-- From sandeen@sandeen.net Fri Sep 4 13:32:59 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2177B7FB5 for ; Fri, 4 Sep 2015 13:32:59 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 01C28304039 for ; Fri, 4 Sep 2015 11:32:58 -0700 (PDT) X-ASG-Debug-ID: 1441391574-04cb6c0e0f83c50001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id Pwa1j5fADX4xeEdf for ; Fri, 04 Sep 2015 11:32:54 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id D226C6864C6A; Fri, 4 Sep 2015 13:32:53 -0500 (CDT) Subject: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats To: Bill O'Donnell , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats References: <1441371319-31625-1-git-send-email-billodo@redhat.com> <1441371319-31625-3-git-send-email-billodo@redhat.com> From: Eric Sandeen Message-ID: <55E9E3D4.5090509@sandeen.net> Date: Fri, 4 Sep 2015 13:32:52 -0500 MIME-Version: 1.0 In-Reply-To: <1441371319-31625-3-git-send-email-billodo@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441391574 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22236 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/4/15 7:55 AM, Bill O'Donnell wrote: > As a part of the work to move xfs global stats from procfs to sysfs, > this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. > > Signed-off-by: Bill O'Donnell > --- > fs/xfs/xfs_stats.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > index 6008e25..734b867 100644 > --- a/fs/xfs/xfs_stats.c > +++ b/fs/xfs/xfs_stats.c > @@ -244,9 +244,12 @@ xfs_init_procfs(void) > if (!proc_mkdir("fs/xfs", NULL)) > goto out; > > - if (!proc_create("fs/xfs/stat", 0, NULL, > - &xfs_stat_proc_fops)) > + if (!proc_symlink("fs/xfs/stat", NULL, > + "/sys/fs/xfs/stats/stats")) > + { > goto out_remove_xfs_dir; > + } Ok, without the printk, now there's no need for the braces :) Also, as an aside, the kernel/xfs style is: if (foo) { ... } not: if (foo) { ... } just FYI... Thanks, -Eric > + > #ifdef CONFIG_XFS_QUOTA > if (!proc_create("fs/xfs/xqmstat", 0, NULL, > &xqmstat_proc_fops)) > From sandeen@sandeen.net Fri Sep 4 15:13:55 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 66FD47F6A for ; Fri, 4 Sep 2015 15:13:55 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 4731930404E for ; Fri, 4 Sep 2015 13:13:51 -0700 (PDT) X-ASG-Debug-ID: 1441397629-04bdf06dd78d110001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id bP57yRup6S4YWi9E for ; Fri, 04 Sep 2015 13:13:49 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 7A5D56214D22; Fri, 4 Sep 2015 15:13:49 -0500 (CDT) Subject: Re: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs To: Bill O'Donnell , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs References: <1441371319-31625-1-git-send-email-billodo@redhat.com> <1441371319-31625-2-git-send-email-billodo@redhat.com> From: Eric Sandeen Message-ID: <55E9FB7D.2060502@sandeen.net> Date: Fri, 4 Sep 2015 15:13:49 -0500 MIME-Version: 1.0 In-Reply-To: <1441371319-31625-2-git-send-email-billodo@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441397629 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22239 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/4/15 7:55 AM, Bill O'Donnell wrote: > Currently, xfs global stats are in procfs. This patch introduces > (replicates) the global stats in sysfs. Additionally a stats_clear file > is introduced in sysfs. > > Signed-off-by: Bill O'Donnell > +STATIC ssize_t > +xfs_stats_store( > + struct kobject *kobject, > + struct attribute *attr, > + const char *buf, > + size_t count) still have some spaces after the types, before the vars... Otherwise, this looks good to me; it's not the only place we have missing tabs... *shrug* you could resend, or maybe Dave's willing to fix up on commit. Reviewed-by: Eric Sandeen Thanks, -Eric From billodo@redhat.com Fri Sep 4 15:15:58 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id D6C827F77 for ; Fri, 4 Sep 2015 15:15:58 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id B81A68F8040 for ; Fri, 4 Sep 2015 13:15:55 -0700 (PDT) X-ASG-Debug-ID: 1441397754-04cb6c0e0e85950001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id YbvrYusANChQCJxA (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 13:15:54 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 1BAC0C0B2B4A; Fri, 4 Sep 2015 20:15:54 +0000 (UTC) Received: from redhat.com (vpn-56-195.rdu2.redhat.com [10.10.56.195]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84KFpfM006599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Sep 2015 16:15:53 -0400 Date: Fri, 4 Sep 2015 15:15:51 -0500 From: "Bill O'Donnell" To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs Message-ID: <20150904201551.GA20161@redhat.com> X-ASG-Orig-Subj: Re: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs References: <1441371319-31625-1-git-send-email-billodo@redhat.com> <1441371319-31625-2-git-send-email-billodo@redhat.com> <55E9FB7D.2060502@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55E9FB7D.2060502@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441397754 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Fri, Sep 04, 2015 at 03:13:49PM -0500, Eric Sandeen wrote: > On 9/4/15 7:55 AM, Bill O'Donnell wrote: > > Currently, xfs global stats are in procfs. This patch introduces > > (replicates) the global stats in sysfs. Additionally a stats_clear file > > is introduced in sysfs. > > > > Signed-off-by: Bill O'Donnell > > > > +STATIC ssize_t > > +xfs_stats_store( > > + struct kobject *kobject, > > + struct attribute *attr, > > + const char *buf, > > + size_t count) > > still have some spaces after the types, before the vars... > > Otherwise, this looks good to me; it's not the only place we have > missing tabs... *shrug* you could resend, or maybe Dave's willing > to fix up on commit. Nah. I'll fix it and resubmit. Thanks again for the review ;) -Bill > > Reviewed-by: Eric Sandeen > > Thanks, > -Eric From billodo@redhat.com Fri Sep 4 15:42:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id F1EF17FAC for ; Fri, 4 Sep 2015 15:42:20 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id C911C8F8049 for ; Fri, 4 Sep 2015 13:42:20 -0700 (PDT) X-ASG-Debug-ID: 1441399339-04cb6c0e0e86170001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id GTpkiPH1TYK5iXu9 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 13:42:19 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 31BCDA19C4 for ; Fri, 4 Sep 2015 20:42:19 +0000 (UTC) Received: from localhost.localdomain.com (vpn-56-195.rdu2.redhat.com [10.10.56.195]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84KgH5V006999 for ; Fri, 4 Sep 2015 16:42:18 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 3/3] xfs: remove unused procfs code Date: Fri, 4 Sep 2015 15:42:14 -0500 X-ASG-Orig-Subj: [PATCH 3/3] xfs: remove unused procfs code Message-Id: <1441399334-7924-3-git-send-email-billodo@redhat.com> In-Reply-To: <1441399334-7924-2-git-send-email-billodo@redhat.com> References: <1441399334-7924-2-git-send-email-billodo@redhat.com> 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: 1441399339 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch removes the now unused procfs code that was xfs stat specific. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 74 ------------------------------------------------------ 1 file changed, 74 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index a9f05de..05d5227 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -112,80 +112,6 @@ void xfs_stats_clearall(void) } } -static int xfs_stat_proc_show(struct seq_file *m, void *v) -{ - int i, j; - __uint64_t xs_xstrat_bytes = 0; - __uint64_t xs_write_bytes = 0; - __uint64_t xs_read_bytes = 0; - - static const struct xstats_entry { - char *desc; - int endpoint; - } xstats[] = { - { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, - { "abt", XFSSTAT_END_ALLOC_BTREE }, - { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, - { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, - { "dir", XFSSTAT_END_DIRECTORY_OPS }, - { "trans", XFSSTAT_END_TRANSACTIONS }, - { "ig", XFSSTAT_END_INODE_OPS }, - { "log", XFSSTAT_END_LOG_OPS }, - { "push_ail", XFSSTAT_END_TAIL_PUSHING }, - { "xstrat", XFSSTAT_END_WRITE_CONVERT }, - { "rw", XFSSTAT_END_READ_WRITE_OPS }, - { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, - { "icluster", XFSSTAT_END_INODE_CLUSTER }, - { "vnodes", XFSSTAT_END_VNODE_OPS }, - { "buf", XFSSTAT_END_BUF }, - { "abtb2", XFSSTAT_END_ABTB_V2 }, - { "abtc2", XFSSTAT_END_ABTC_V2 }, - { "bmbt2", XFSSTAT_END_BMBT_V2 }, - { "ibt2", XFSSTAT_END_IBT_V2 }, - { "fibt2", XFSSTAT_END_FIBT_V2 }, - /* we print both series of quota information together */ - { "qm", XFSSTAT_END_QM }, - }; - - /* Loop over all stats groups */ - for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { - seq_printf(m, "%s", xstats[i].desc); - /* inner loop does each group */ - for (; j < xstats[i].endpoint; j++) - seq_printf(m, " %u", counter_val(j)); - seq_putc(m, '\n'); - } - /* extra precision counters */ - for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; - } - - seq_printf(m, "xpc %Lu %Lu %Lu\n", - xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); - seq_printf(m, "debug %u\n", -#if defined(DEBUG) - 1); -#else - 0); -#endif - return 0; -} - -static int xfs_stat_proc_open(struct inode *inode, struct file *file) -{ - return single_open(file, xfs_stat_proc_show, NULL); -} - -static const struct file_operations xfs_stat_proc_fops = { - .owner = THIS_MODULE, - .open = xfs_stat_proc_open, - .read = seq_read, - .llseek = seq_lseek, - .release = single_release, -}; - /* legacy quota interfaces */ #ifdef CONFIG_XFS_QUOTA static int xqm_proc_show(struct seq_file *m, void *v) -- 2.4.3 From billodo@redhat.com Fri Sep 4 15:42:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id CB4517FBA for ; Fri, 4 Sep 2015 15:42:22 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id AC2B3304032 for ; Fri, 4 Sep 2015 13:42:19 -0700 (PDT) X-ASG-Debug-ID: 1441399338-04bdf06dd88d9d0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id aBmQ4NiKFmyWJFDU (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 13:42:19 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 7B75F2B81CA for ; Fri, 4 Sep 2015 20:42:18 +0000 (UTC) Received: from localhost.localdomain.com (vpn-56-195.rdu2.redhat.com [10.10.56.195]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84KgH5U006999 for ; Fri, 4 Sep 2015 16:42:18 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Date: Fri, 4 Sep 2015 15:42:13 -0500 X-ASG-Orig-Subj: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-Id: <1441399334-7924-2-git-send-email-billodo@redhat.com> 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: 1441399339 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 6008e25..a9f05de 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -244,9 +244,10 @@ xfs_init_procfs(void) if (!proc_mkdir("fs/xfs", NULL)) goto out; - if (!proc_create("fs/xfs/stat", 0, NULL, - &xfs_stat_proc_fops)) + if (!proc_symlink("fs/xfs/stat", NULL, + "/sys/fs/xfs/stats/stats")) goto out_remove_xfs_dir; + #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, &xqmstat_proc_fops)) -- 2.4.3 From billodo@redhat.com Fri Sep 4 15:54:24 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 39BC47FB7 for ; Fri, 4 Sep 2015 15:54:24 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 268B5304051 for ; Fri, 4 Sep 2015 13:54:24 -0700 (PDT) X-ASG-Debug-ID: 1441400063-04cbb06acb91110001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Cv8rjlSmSdMIT9iJ (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 13:54:23 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 172D791C18 for ; Fri, 4 Sep 2015 20:54:23 +0000 (UTC) Received: from localhost.localdomain.com (vpn-56-195.rdu2.redhat.com [10.10.56.195]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84KsLOA004979 for ; Fri, 4 Sep 2015 16:54:22 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Date: Fri, 4 Sep 2015 15:54:09 -0500 X-ASG-Orig-Subj: [PATCH 2/3] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-Id: <1441400050-8455-3-git-send-email-billodo@redhat.com> In-Reply-To: <1441400050-8455-1-git-send-email-billodo@redhat.com> References: <1441400050-8455-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441400063 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 6008e25..a9f05de 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -244,9 +244,10 @@ xfs_init_procfs(void) if (!proc_mkdir("fs/xfs", NULL)) goto out; - if (!proc_create("fs/xfs/stat", 0, NULL, - &xfs_stat_proc_fops)) + if (!proc_symlink("fs/xfs/stat", NULL, + "/sys/fs/xfs/stats/stats")) goto out_remove_xfs_dir; + #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, &xqmstat_proc_fops)) -- 2.4.3 From billodo@redhat.com Fri Sep 4 15:54:24 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 2061B7FB4 for ; Fri, 4 Sep 2015 15:54:24 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id AF500AC001 for ; Fri, 4 Sep 2015 13:54:23 -0700 (PDT) X-ASG-Debug-ID: 1441400062-04cb6c0e0c86510001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id nmVclSq4ZoA3hz6P (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 13:54:22 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id F19E3A37E6 for ; Fri, 4 Sep 2015 20:54:21 +0000 (UTC) Received: from localhost.localdomain.com (vpn-56-195.rdu2.redhat.com [10.10.56.195]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84KsLO8004979 for ; Fri, 4 Sep 2015 16:54:21 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 0/3 V3] xfs: new global stats in sysfs Date: Fri, 4 Sep 2015 15:54:07 -0500 X-ASG-Orig-Subj: [PATCH 0/3 V3] xfs: new global stats in sysfs Message-Id: <1441400050-8455-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441400062 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi all- Here is the third pass at a series to add new global stats to sysfs. (Minor whitespace and braces fixups.) As a part of that, the /proc/fs/xfs/stat file becomes a symlink to the sysfs stats entry. The series provides the beginnings of the infrastructure for per-fs stats (in addition to global accumulative stats). We already have per-fs information in /sys, so it makes sense to have per-fs stats there too. As a first step, moving existing global stats infrastructure to /sys will allow us to re-use that sysfs code for per-fs stats as well. Patch 1 handles the bring-up and tear down of xfs/stats directory structure in sysfs when an fs is mounted. The directory contains the stats file and the stats_clear file. The stats file contents mimic those of /proc/fs/xfs/stat. The stats_clear file is empty, and much like the current stat_clear command, handles the zeroing of the stats file when a "1" is echoed to the stats_clear file. Patch 2 creates the symlink for stats from procfs to sysfs. Patch 3 removes the now unused portions of procfs for stat. Once again, comments and questions are welcome. Thanks- Bill From billodo@redhat.com Fri Sep 4 15:54:24 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id B35C57FB7 for ; Fri, 4 Sep 2015 15:54:24 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 854468F8049 for ; Fri, 4 Sep 2015 13:54:24 -0700 (PDT) X-ASG-Debug-ID: 1441400063-04bdf06dd88dd80001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id jqSKP1W0qO8WB1Yj (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 13:54:23 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 8F38E341AF6 for ; Fri, 4 Sep 2015 20:54:23 +0000 (UTC) Received: from localhost.localdomain.com (vpn-56-195.rdu2.redhat.com [10.10.56.195]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84KsLOB004979 for ; Fri, 4 Sep 2015 16:54:23 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 3/3] xfs: remove unused procfs code Date: Fri, 4 Sep 2015 15:54:10 -0500 X-ASG-Orig-Subj: [PATCH 3/3] xfs: remove unused procfs code Message-Id: <1441400050-8455-4-git-send-email-billodo@redhat.com> In-Reply-To: <1441400050-8455-1-git-send-email-billodo@redhat.com> References: <1441400050-8455-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441400063 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch removes the now unused procfs code that was xfs stat specific. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 74 ------------------------------------------------------ 1 file changed, 74 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index a9f05de..05d5227 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -112,80 +112,6 @@ void xfs_stats_clearall(void) } } -static int xfs_stat_proc_show(struct seq_file *m, void *v) -{ - int i, j; - __uint64_t xs_xstrat_bytes = 0; - __uint64_t xs_write_bytes = 0; - __uint64_t xs_read_bytes = 0; - - static const struct xstats_entry { - char *desc; - int endpoint; - } xstats[] = { - { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, - { "abt", XFSSTAT_END_ALLOC_BTREE }, - { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, - { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, - { "dir", XFSSTAT_END_DIRECTORY_OPS }, - { "trans", XFSSTAT_END_TRANSACTIONS }, - { "ig", XFSSTAT_END_INODE_OPS }, - { "log", XFSSTAT_END_LOG_OPS }, - { "push_ail", XFSSTAT_END_TAIL_PUSHING }, - { "xstrat", XFSSTAT_END_WRITE_CONVERT }, - { "rw", XFSSTAT_END_READ_WRITE_OPS }, - { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, - { "icluster", XFSSTAT_END_INODE_CLUSTER }, - { "vnodes", XFSSTAT_END_VNODE_OPS }, - { "buf", XFSSTAT_END_BUF }, - { "abtb2", XFSSTAT_END_ABTB_V2 }, - { "abtc2", XFSSTAT_END_ABTC_V2 }, - { "bmbt2", XFSSTAT_END_BMBT_V2 }, - { "ibt2", XFSSTAT_END_IBT_V2 }, - { "fibt2", XFSSTAT_END_FIBT_V2 }, - /* we print both series of quota information together */ - { "qm", XFSSTAT_END_QM }, - }; - - /* Loop over all stats groups */ - for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { - seq_printf(m, "%s", xstats[i].desc); - /* inner loop does each group */ - for (; j < xstats[i].endpoint; j++) - seq_printf(m, " %u", counter_val(j)); - seq_putc(m, '\n'); - } - /* extra precision counters */ - for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; - } - - seq_printf(m, "xpc %Lu %Lu %Lu\n", - xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); - seq_printf(m, "debug %u\n", -#if defined(DEBUG) - 1); -#else - 0); -#endif - return 0; -} - -static int xfs_stat_proc_open(struct inode *inode, struct file *file) -{ - return single_open(file, xfs_stat_proc_show, NULL); -} - -static const struct file_operations xfs_stat_proc_fops = { - .owner = THIS_MODULE, - .open = xfs_stat_proc_open, - .read = seq_read, - .llseek = seq_lseek, - .release = single_release, -}; - /* legacy quota interfaces */ #ifdef CONFIG_XFS_QUOTA static int xqm_proc_show(struct seq_file *m, void *v) -- 2.4.3 From billodo@redhat.com Fri Sep 4 15:54:24 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 3A5667FBA for ; Fri, 4 Sep 2015 15:54:24 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 18B6630404E for ; Fri, 4 Sep 2015 13:54:23 -0700 (PDT) X-ASG-Debug-ID: 1441400062-04cbb06acc91110001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id JXnMhcMBweTEYPLS (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 04 Sep 2015 13:54:23 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 83BAF341AF5 for ; Fri, 4 Sep 2015 20:54:22 +0000 (UTC) Received: from localhost.localdomain.com (vpn-56-195.rdu2.redhat.com [10.10.56.195]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t84KsLO9004979 for ; Fri, 4 Sep 2015 16:54:22 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs Date: Fri, 4 Sep 2015 15:54:08 -0500 X-ASG-Orig-Subj: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs Message-Id: <1441400050-8455-2-git-send-email-billodo@redhat.com> In-Reply-To: <1441400050-8455-1-git-send-email-billodo@redhat.com> References: <1441400050-8455-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441400063 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Currently, xfs global stats are in procfs. This patch introduces (replicates) the global stats in sysfs. Additionally a stats_clear file is introduced in sysfs. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_stats.h | 2 ++ fs/xfs/xfs_super.c | 20 +++++++++---- fs/xfs/xfs_sysctl.c | 15 ++-------- fs/xfs/xfs_sysfs.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_sysfs.h | 1 + 6 files changed, 179 insertions(+), 17 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index f224038..6008e25 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -29,6 +29,89 @@ static int counter_val(int idx) return val; } +int xfs_stats_format(char *buf) +{ + int i, j; + int len = 0; + __uint64_t xs_xstrat_bytes = 0; + __uint64_t xs_write_bytes = 0; + __uint64_t xs_read_bytes = 0; + + static const struct xstats_entry { + char *desc; + int endpoint; + } xstats[] = { + { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, + { "abt", XFSSTAT_END_ALLOC_BTREE }, + { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, + { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, + { "dir", XFSSTAT_END_DIRECTORY_OPS }, + { "trans", XFSSTAT_END_TRANSACTIONS }, + { "ig", XFSSTAT_END_INODE_OPS }, + { "log", XFSSTAT_END_LOG_OPS }, + { "push_ail", XFSSTAT_END_TAIL_PUSHING }, + { "xstrat", XFSSTAT_END_WRITE_CONVERT }, + { "rw", XFSSTAT_END_READ_WRITE_OPS }, + { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, + { "icluster", XFSSTAT_END_INODE_CLUSTER }, + { "vnodes", XFSSTAT_END_VNODE_OPS }, + { "buf", XFSSTAT_END_BUF }, + { "abtb2", XFSSTAT_END_ABTB_V2 }, + { "abtc2", XFSSTAT_END_ABTC_V2 }, + { "bmbt2", XFSSTAT_END_BMBT_V2 }, + { "ibt2", XFSSTAT_END_IBT_V2 }, + { "fibt2", XFSSTAT_END_FIBT_V2 }, + /* we print both series of quota information together */ + { "qm", XFSSTAT_END_QM }, + }; + + /* Loop over all stats groups */ + + for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { + len += snprintf(buf + len, PATH_MAX - len, "%s", + xstats[i].desc); + /* inner loop does each group */ + for (; j < xstats[i].endpoint; j++) + len += snprintf(buf + len, PATH_MAX - len, " %u", + counter_val(j)); + len += snprintf(buf + len, PATH_MAX - len, "\n"); + } + /* extra precision counters */ + for_each_possible_cpu(i) { + xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; + xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; + xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; + } + + len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", + xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); + len += snprintf(buf+len, PATH_MAX-len, "debug %u\n", +#if defined(DEBUG) + 1); +#else + 0); +#endif + +return len; +} + +void xfs_stats_clearall(void) +{ + int c; + __uint32_t vn_active; + + xfs_notice(NULL, "Clearing xfsstats"); + for_each_possible_cpu(c) { + preempt_disable(); + /* save vn_active, it's a universal truth! */ + vn_active = per_cpu(xfsstats, c).vn_active; + memset(&per_cpu(xfsstats, c), 0, + sizeof(struct xfsstats)); + per_cpu(xfsstats, c).vn_active = vn_active; + preempt_enable(); + } +} + static int xfs_stat_proc_show(struct seq_file *m, void *v) { int i, j; diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index c8f238b..18807b5 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -18,6 +18,8 @@ #ifndef __XFS_STATS_H__ #define __XFS_STATS_H__ +int xfs_stats_format(char *buf); +void xfs_stats_clearall(void); #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 3bf503a..31ad281 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -61,6 +61,7 @@ static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; static struct kset *xfs_kset; /* top-level xfs sysfs dir */ +static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ #ifdef DEBUG static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ #endif @@ -1838,19 +1839,25 @@ init_xfs_fs(void) xfs_kset = kset_create_and_add("xfs", NULL, fs_kobj); if (!xfs_kset) { error = -ENOMEM; - goto out_sysctl_unregister;; + goto out_sysctl_unregister; } + xfs_stats_kobj.kobject.kset = xfs_kset; + error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, + "stats"); + if (error) + goto out_kset_unregister; + #ifdef DEBUG xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_kset_unregister; + goto out_remove_stats_kobj; #endif error = xfs_qm_init(); if (error) - goto out_remove_kobj; + goto out_remove_dbg_kobj; error = register_filesystem(&xfs_fs_type); if (error) @@ -1859,11 +1866,13 @@ init_xfs_fs(void) out_qm_exit: xfs_qm_exit(); - out_remove_kobj: + out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_kset_unregister: + out_remove_stats_kobj: #endif + xfs_sysfs_del(&xfs_stats_kobj); + out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: xfs_sysctl_unregister(); @@ -1889,6 +1898,7 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif + xfs_sysfs_del(&xfs_stats_kobj); kset_unregister(xfs_kset); xfs_sysctl_unregister(); xfs_cleanup_procfs(); diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c index a0c8067..5defabb 100644 --- a/fs/xfs/xfs_sysctl.c +++ b/fs/xfs/xfs_sysctl.c @@ -19,6 +19,7 @@ #include #include #include "xfs_error.h" +#include "xfs_stats.h" static struct ctl_table_header *xfs_table_header; @@ -31,22 +32,12 @@ xfs_stats_clear_proc_handler( size_t *lenp, loff_t *ppos) { - int c, ret, *valp = ctl->data; - __uint32_t vn_active; + int ret, *valp = ctl->data; ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); if (!ret && write && *valp) { - xfs_notice(NULL, "Clearing xfsstats"); - for_each_possible_cpu(c) { - preempt_disable(); - /* save vn_active, it's a universal truth! */ - vn_active = per_cpu(xfsstats, c).vn_active; - memset(&per_cpu(xfsstats, c), 0, - sizeof(struct xfsstats)); - per_cpu(xfsstats, c).vn_active = vn_active; - preempt_enable(); - } + xfs_stats_clearall(); xfs_stats_clear = 0; } diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index aa03670..a094e20 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -21,6 +21,7 @@ #include "xfs_log_format.h" #include "xfs_log.h" #include "xfs_log_priv.h" +#include "xfs_stats.h" struct xfs_sysfs_attr { struct attribute attr; @@ -38,6 +39,8 @@ to_attr(struct attribute *attr) static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RW(name) #define XFS_SYSFS_ATTR_RO(name) \ static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RO(name) +#define XFS_SYSFS_ATTR_WO(name) \ + static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_WO(name) #define ATTR_LIST(name) &xfs_sysfs_attr_##name.attr @@ -125,6 +128,78 @@ struct kobj_type xfs_dbg_ktype = { #endif /* DEBUG */ + +/* stats */ + +STATIC ssize_t +stats_show( + char *buf, + void *data) +{ + return xfs_stats_format(buf); +} +XFS_SYSFS_ATTR_RO(stats); + +STATIC ssize_t +stats_clear_store( + const char *buf, + size_t count, + void *data) +{ + int ret; + int val; + + ret = kstrtoint(buf, 0, &val); + if (ret) + return ret; + + if (val != 1) + return -EINVAL; + xfs_stats_clearall(); + return count; +} +XFS_SYSFS_ATTR_WO(stats_clear); + +static struct attribute *xfs_stats_attrs[] = { + ATTR_LIST(stats), + ATTR_LIST(stats_clear), + NULL, +}; + +STATIC ssize_t +xfs_stats_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; +} + +STATIC ssize_t +xfs_stats_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; +} + +static struct sysfs_ops xfs_stats_ops = { + .show = xfs_stats_show, + .store = xfs_stats_store, +}; + +struct kobj_type xfs_stats_ktype = { + .release = xfs_sysfs_release, + .sysfs_ops = &xfs_stats_ops, + .default_attrs = xfs_stats_attrs, +}; + /* xlog */ STATIC ssize_t diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h index 240eee3..be692e5 100644 --- a/fs/xfs/xfs_sysfs.h +++ b/fs/xfs/xfs_sysfs.h @@ -22,6 +22,7 @@ extern struct kobj_type xfs_mp_ktype; /* xfs_mount */ extern struct kobj_type xfs_dbg_ktype; /* debug */ extern struct kobj_type xfs_log_ktype; /* xlog */ +extern struct kobj_type xfs_stats_ktype; /* stats */ static inline struct xfs_kobj * to_kobj(struct kobject *kobject) -- 2.4.3 From sandeen@sandeen.net Fri Sep 4 16:34:55 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id E19C07FBF for ; Fri, 4 Sep 2015 16:34:55 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id D0DFD304032 for ; Fri, 4 Sep 2015 14:34:52 -0700 (PDT) X-ASG-Debug-ID: 1441402491-04cb6c0e0f86fd0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id HaPdgzA8DaMetMAd for ; Fri, 04 Sep 2015 14:34:51 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 1E3536214D2D; Fri, 4 Sep 2015 16:34:51 -0500 (CDT) Subject: Re: [PATCH 0/3 V3] xfs: new global stats in sysfs To: Bill O'Donnell , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/3 V3] xfs: new global stats in sysfs References: <1441400050-8455-1-git-send-email-billodo@redhat.com> From: Eric Sandeen Message-ID: <55EA0E7A.9070501@sandeen.net> Date: Fri, 4 Sep 2015 16:34:50 -0500 MIME-Version: 1.0 In-Reply-To: <1441400050-8455-1-git-send-email-billodo@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441402491 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22242 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/4/15 3:54 PM, Bill O'Donnell wrote: > > Hi all- > > Here is the third pass at a series to add new global stats to sysfs. > (Minor whitespace and braces fixups.) Thanks - For the series, Reviewed-by: Eric Sandeen From david@fromorbit.com Fri Sep 4 22:31:28 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id E14E47FAC for ; Fri, 4 Sep 2015 22:31:28 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id D045C8F804B for ; Fri, 4 Sep 2015 20:31:25 -0700 (PDT) X-ASG-Debug-ID: 1441423882-04cbb06acd97770001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id BgUjqbI9tn6XGThM for ; Fri, 04 Sep 2015 20:31:23 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BICABfYepVPOV8LHldgyGBPYZSoxAGil6REAQCAoEzTQEBAQEBAQcBAQEBQT+EJAEBBCcTHCMQCAMYCSUPBSUDBxoTiC3KJAEBCAIgGYYThUKFCweELAWSMYMgjHSOdIt/hDgsM4lLAQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 05 Sep 2015 13:01:21 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZY4CH-0002Q6-44; Sat, 05 Sep 2015 13:31:21 +1000 Date: Sat, 5 Sep 2015 13:31:21 +1000 From: Dave Chinner To: Bill O'Donnell Cc: xfs@oss.sgi.com Subject: Re: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs Message-ID: <20150905033121.GN26895@dastard> X-ASG-Orig-Subj: Re: [PATCH 1/3] xfs: create global stats and stats_clear in sysfs References: <1441400050-8455-1-git-send-email-billodo@redhat.com> <1441400050-8455-2-git-send-email-billodo@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441400050-8455-2-git-send-email-billodo@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1441423882 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22251 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Fri, Sep 04, 2015 at 03:54:08PM -0500, Bill O'Donnell wrote: > Currently, xfs global stats are in procfs. This patch introduces > (replicates) the global stats in sysfs. Additionally a stats_clear file > is introduced in sysfs. > .... > > +int xfs_stats_format(char *buf) > +{ > + int i, j; > + int len = 0; > + __uint64_t xs_xstrat_bytes = 0; > + __uint64_t xs_write_bytes = 0; > + __uint64_t xs_read_bytes = 0; .... > + len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", > + xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); > + len += snprintf(buf+len, PATH_MAX-len, "debug %u\n", > +#if defined(DEBUG) > + 1); > +#else > + 0); > +#endif > + > +return len; > +} missing tab on return. .... > +STATIC ssize_t > +xfs_stats_show( > + struct kobject *kobject, > + struct attribute *attr, > + char *buf) > +{ > + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); > + > + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; > +} > + > +STATIC ssize_t > +xfs_stats_store( > + struct kobject *kobject, > + struct attribute *attr, > + const char *buf, > + size_t count) > +{ > + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); > + > + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; > +} > + > +static struct sysfs_ops xfs_stats_ops = { > + .show = xfs_stats_show, > + .store = xfs_stats_store, > +}; Hmmm, I'm wondering if we can reduce this boiler plate code here. It's basically indentical to xfs_log_show/store and xfs_dbg_show/store. TO make them indentical, all we need to do is pass the kobject through as the data object, and have the show/store function decode it if necessary (i.e. call to_xlog() for the xfs log attributes). This them means that all the sysfs entries attributes use the same sysfs_ops structure. That can be done as a patch on top of this, though (i.e. patch #4). Cheers, Dave. -- Dave Chinner david@fromorbit.com From 3Z8XrVQUPA1Y6B3OU44FL.HI4G21.LMNL3GCGG.G46.0CA@photos-server.bounces.google.com Sat Sep 5 23:47:45 2015 Return-Path: <3Z8XrVQUPA1Y6B3OU44FL.HI4G21.LMNL3GCGG.G46.0CA@photos-server.bounces.google.com> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=5.0 tests=DEAR_SOMETHING,HTML_MESSAGE autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 8C5B67F66 for ; Sat, 5 Sep 2015 23:47:45 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 2453CAC003 for ; Sat, 5 Sep 2015 21:47:42 -0700 (PDT) X-ASG-Debug-ID: 1441514856-04bdf06dd7aa790001-NocioJ Received: from mail-pa0-f73.google.com (mail-pa0-f73.google.com [209.85.220.73]) by cuda.sgi.com with ESMTP id 0oIOYtjCi3IVnLKL (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Sat, 05 Sep 2015 21:47:36 -0700 (PDT) X-Barracuda-Envelope-From: 3Z8XrVQUPA1Y6B3OU44FL.HI4G21.LMNL3GCGG.G46.0CA@photos-server.bounces.google.com X-Barracuda-Apparent-Source-IP: 209.85.220.73 X-Barracuda-IPDD: Level1 [photos-server.bounces.google.com/209.85.220.73] Received: by pary6 with SMTP id y6so5169472par.0 for ; Sat, 05 Sep 2015 21:47:36 -0700 (PDT) X-Barracuda-IPDD: Level1 [photos-server.bounces.google.com/209.85.220.73] X-Barracuda-IPDD: Level1 [photos-server.bounces.google.com/209.85.220.73] X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:reply-to:message-id:date:subject:from:to:content-type; bh=u18anxDDKv363q5pnfCwwkzG5RUb0cCOgL7EbBkkMXs=; b=WwW6MCBSCP09aUkGE8KjbZ4u35RcR7reicR6On8EVUaAkIg1Tx8vMYEXQa8PW0oo0c CC0fFf2J7TlWgzTlTYTjWgaLj+sbgWf2OLd5mChg13cgMf3v1ooaT3t/F6/t7dvmX/63 bJii9A4dtbaQy1KdGQmFVk3lE5ryPvRGeZ72PXs+VSGNUpaWn8UhwKEcLLDmLo5qSs3Y /g2GEUpWNnaf94CNWHJzekhLes5usaiRbwDD3bdghcXQgq3v+S23c5NgzBoLaprichlN qFvAAQSjF+AEJjuTCrrTWHqSWsfpjmV2D8Nvkwbj0/Uy7tQjhPxaP8bq9HtrpEYzDVew E/tg== MIME-Version: 1.0 X-Received: by 10.68.206.106 with SMTP id ln10mr11563150pbc.5.1441514855972; Sat, 05 Sep 2015 21:47:35 -0700 (PDT) Reply-To: "Mould making/ Die-casting/ Precision stamping/ Machining parts/CNC Precision Parts Manufacturing" Message-ID: <089e0158c2d4edbf20051f0cd4f5@google.com> Date: Sun, 06 Sep 2015 04:47:35 +0000 Subject: =?GB2312?B?TW91bGQgbWFraW5nLyBEaWUtY2FzdGluZy8gUHJlY2lzaW9uIHN0YW1waW5nLyBNYWNoaQ==?= =?GB2312?B?bmluZyBwYXJ0cy9DTkMgUHJlY2lzaW9uIFBhcnRzIE1hbnVmYWN0dXJpbmfT68T6ubLP7cHL?= =?GB2312?B?z+Cy4aGj?= From: "Mould making/ Die-casting/ Precision stamping/ Machining parts/CNC Precision Parts Manufacturing" X-ASG-Orig-Subj: =?GB2312?B?TW91bGQgbWFraW5nLyBEaWUtY2FzdGluZy8gUHJlY2lzaW9uIHN0YW1waW5nLyBNYWNoaQ==?= =?GB2312?B?bmluZyBwYXJ0cy9DTkMgUHJlY2lzaW9uIFBhcnRzIE1hbnVmYWN0dXJpbmfT68T6ubLP7cHL?= =?GB2312?B?z+Cy4aGj?= To: xfs@oss.sgi.com Content-Type: multipart/related; boundary=089e0158c2d4edbef8051f0cd4f3 X-Barracuda-Connect: mail-pa0-f73.google.com[209.85.220.73] X-Barracuda-Start-Time: 1441514856 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22276 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --089e0158c2d4edbef8051f0cd4f3 Content-Type: multipart/alternative; boundary=089e0158c2d4edbef3051f0cd4f2 --089e0158c2d4edbef3051f0cd4f2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Dear Sir/Ms, Good day! As an ISO certified factory, we specialized manufacture Mould making/ Sheet metal process/ Die-casting/ Precision stamping/ Machining parts, with strong competitive price and excellent quality, for more than 20 years. Any questions and enquiries will be highly regarded. Just email us the drawing and detailed requirement, you will get a complete quotation with technical analysis within 24 hours. Your prompt reply is highly appreciated. Best regards sincerely! Michael ________________________________________ Shenzhen, China https://picasaweb.google.com/lh/sredir?uname=105423401121001619213&target=ALBUM&id=6112196526568809473&authkey=Gv1sRgCLO8v46ttN3rLg&invite=CNyNzsEB&feat=email --089e0158c2d4edbef3051f0cd4f2 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
=D1=FB=C7=EB=C4=FA=B9=DB=BF=B4 Mould making/ Die-casting/ Precis= ion stamping/ Machining parts/CNC Precision Parts Manufacturing =B5=C4=CF= =E0=B2=E1=A3=BA Precision stamping Machini= ng parts
Precision stamping Machining parts
2015=C4=EA2=D4=C24=C8=D5
=CC=E1=B9=A9=D5=DF=A3=BAMould making/ Die-casting/ Precision stamping/ M= achining parts/CNC Precision Parts Manufacturing
=D2=AA=B7=D6=CF=ED=C4=FA=B5=C4=D5=D5=C6=AC=BB=F2=D4=DA=C5=F3=D3=D1= =D3=EB=C4=FA=B7=D6=CF=ED=D5=D5=C6=AC=CA=B1=CA=D5=B5=BD=CD=A8=D6=AA=A3=AC=C7= =EB=BB=F1=C8=A1=CA=F4=D3=DA=C4=FA= =D7=D4=BC=BA=B5=C4=C3=E2=B7=D1 Picasa =CD=F8=C2=E7=CF=E0=B2=E1=D5=CA=BB=A7<= /a>=A1=A3
--089e0158c2d4edbef3051f0cd4f2-- --089e0158c2d4edbef8051f0cd4f3 Content-Type: image/gif; name="picasaweblogo-zh_CN.gif" Content-Disposition: attachment; filename="picasaweblogo-zh_CN.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhzQAfAOYAALu9v93e37C7wQClUJ99rtjd4OySN4mZovb3+Jmcn/f392uAi+ZXVcTM0eLm 6Kqtr9XW1+7v7wB6tObn53WIk+zu8LrEyaazubO1t3+RmsTGx/bJm87V2ZOiqpyqspGUl8De7MzO z9vP4fOrqkC8fKWFs+ff62Cs0P719aKkp4DSqO3n8OhiYPn3+vvr2sOuzLDjyet3dfPv9bGVvaDd vvbAwPnV1dXG3CCwZvrg4PGhoP758+yBgNDu34C92vCnXZDF3reewsDp1P3y5xCCufD69fD3+/TC j+6gUHd7f/O7gjCTwu2ZRJDYs4iMj72mxxCrW6uNuPS2tffQqICDh9Dm8eTn8OD06vGtaWF3g/// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5 BAAAAAAALAAAAADNAB8AAAf/gFqCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6iKKDo8DK4sPFIoqbS1tpcyTyI6rr2uIy47t8PExYQiJQQEIjW+vxs/LocVAtXWAg0VxtvclSLK 4DfNviMbBkzShQVZ7O3tHghaDgcc3fb3hSvg+y82LL3lDBj4IYzQuiwHEibMwK6DFgFZBOCbaC/K PnAzWuT4xyCgwCPq2BlqwM4BggbxihWg0GCBFpcUt327SCBIC0E5YnQ0J9DAEIMiDTG0MK8AoQYe DnSwkHJQBQsJLxi10CHl0w5Kmaq7kJBphQ4NBB3QQqFDhpjbZtB8UQhFDI8C/6cAzXLoQESIEuUx dLegnqCW7rJcWJDFqAPCfB0IQmDXHQULCMVqGZwX7bAWaw+hsMFTIJa5hyhkaYBXCwLCCy5wECC6 sBYO7Chg8+DOKGGWBSwQPqtlr4cGFlpHlqelgvFJCghNSG5oQoRFzLUoiB69mImLNxR1FgiaEALa WahF1EJ7geLFDA+czlJ10GF2BQ42dVCS5GhC4Mcm0gCgv///CQQwyAfRPRDCIf1JB0AADAaQwHNa aABBABqkEAAGDH4wwTbXgSPCItsZMJdCB+w1Hl4IsBMWIRUcgE0WCzQlCESF0ReRNoJcUBVDHhSC gGj6IbJgIgkMMuEgCnzQX/8CEBAypBZFDjgIAII0SKUWVxrTYQki+ACCdj1xN8hBgWXx2IwRHZQI RA75CJ8WjbFzgFSCvFnIBcMJKaAWATwwyAMODnIgBE1ioIEgfgoy4QMaBBilII9eaaUgWVpHQAkr nCDBl4mEOFd8oOKIpgDr8HZIaYa8iQBrgfUYVCEQBYkgBMmFAMGGWvgZpXO5KsBgBCEAgKsWEwSQ hAYBRPBBg4FSWiWDV1ZKjAyYaropmD0h0R0ieKnJLXuGVAAfAgXEQ24DjcHm2p15zqpBBA9Mp4EC GEApyAcYYKhAk1hKOwEVVy7bYKTPBhBtdcRYsYQEDHOKyHZKbHvqeIRZUMj/YaqxIyqahUF0QSF2 CcCjj4TJasiQ+QqiQID2SqfAgUaGgEGlGDwAQb2P2jsBAAn098DPPfOM7zZAMNwwJd5+KxGeCxiF HriiZdCUfYVBZt4gP2ZhgX0rmtaYyYUMGcIHEP7cshYHKhBBBE8G8EGTCvRncLOQTllwtN0YQYTR IJAwwN+ABw44CSHRteZ4COzVgQAeoKaYuqkJEGdh60XO6gLafC3ABaKVrMiCccPLJwQLRqnBAwDc urN/GPA775NOAGg3n9A6203RDfst+O4D9BASTEovNrmZ572GWDuAGSYcOwus+F1gGZAEtpMQHMrn ztI1qvIgG2Y5ZATd75kzy8G0G2x7N9b2zbvgNBiyql+IOCBA8fJYAz/WpAlggTYcWDzIatVAycWs EZb3fY5fgrBe3VTGn+R4b0+UEh8hyDcpLOFDU+pb39/aZxlKPOkQUUrBAyBkwQg6SYKDoGDtSngP H1RBd7zDAQw6WIkPIulmKRAECQWBIQYB6oT3YtajchiCABlsAjWLiQqgsDscNKEINKxEBBA2iB0W goRWDABzhkUs7ulQOs+ZjmV6AAMVqEAIV4iiGtfIxja68Y1wjKMc50jHOtpRFIEAADs= --089e0158c2d4edbef8051f0cd4f3 Content-Type: image/jpeg; name="email.jpg" Content-Disposition: attachment; filename="email.jpg" Content-Transfer-Encoding: base64 Content-ID: <6112196526568809473> /9j/4AAQSkZJRgABAQAAAQABAAD/4QB+RXhpZgAASUkqAAgAAAACADEBAgAHAAAAJgAAAGmHBAAB AAAALgAAAAAAAABHb29nbGUAAAMAAJAHAAQAAAAwMjIwAaADAAEAAAABAAAABaAEAAEAAABYAAAA AAAAAAIAAQACAAQAAABSOTgAAgAHAAQAAAAwMTAwAAAAAP/bAIQAAwICCAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICggICAgLCQkICAsYCggNCAgJCAEDBAQGBQYKBgYK DA0MDA0MDA0NDA0NDAwNDQwMDQwMDAwNDA0MDQwNDAwMDA0MDAwMDAwMDAwMDAwNDAwMDAwM/8AA EQgAkAB7AwERAAIRAQMRAf/EAB0AAQABBQEBAQAAAAAAAAAAAAAIAgQFBgcJAwH/xAA9EAACAQMC AwcBBgMHBAMAAAABAgMABBEFEgYhMQcIEyJBUXFhCRQjMkKBUpGhM2JygrHR8ENFc8EVFiT/xAAZ AQEAAwEBAAAAAAAAAAAAAAAAAQIDBAX/xAAkEQEBAAICAgIDAAMBAAAAAAAAAQIRITEDEkFRBBNh cZHBFP/aAAwDAQACEQMRAD8A9GIeg+BXO9tXQKBQKBQKBQKBQKBQKBQKBQUQ9B8CgroFAoFAoFAo FAoFAoFAoFAoKIeg+BQV0CgUCgUCgUCgUCgUCgUCgUFEPQfAoK6BQKBQKBQKBQKBQKBQKBQKCiHo PgUFdAoFAoFAoKXcAEkgAdSTgD5J5CpFSjIyOYPMEcwR9DUHBip0GKgKBQKBQKCiHoPgUFdAoFAo FBY63rcNtDJPcSJDDEpeSSRgqqqjJJJ+g6DJPsaItk5qGvDXeJXiXVryFFYWdrEDYwsVHiAS+HNc yISVaV90WwHPhRkgc2kLTLt5vl8ly/w+fZR2hQam90lrFfWNxZymC6geP7u8UgJAO+3k5htm4bir Y/RjBMySsbllj8uqaXrupRHy38xA9Jgsw+D4yO56ejir+n1tOPnyjaLHteu0A8VLeYY6qHt2/wBZ h8jYP93o2x/KvzGetu2mEkB7e4HTnGYXX19WkiY9B0X1p6VrPysb2vI+2bTuQeWWEnl+Nbzoo5Z5 yCNoxjpnfjPr61S42Np58L8tu0/UI5kWWJ0kjcZV0YMrD3BGR/sahtLL0uKhJQUQ9B8CgroFAoFB iOIuI0twoILyynbFEDguw6knoqLkFnPTIGGZlUyzzzmM5Qw782p3j2gd3YKrMpiXlHHuBVsKCQTt IHiMWJDdcHAzz24v2XK8ovd0HVTBrNmSVCTs1q+/8n4yFE3ewE3h/BAqMLzGec4r0j1VIrWOW4ch EihaaaSKX9MSluaggnCqcDp6da69acm7XDLHtN1W6Y3CC2tbVhmGO4tmuZmX0aRxPCBkekfTpk9a pPI09GI1ft+uraN3mtbKUKwX8KW5tXcYyWVJFu4xj/GOtW9kTFps3fd0g+W4tb2Bv4vCtbpF984k icj4XpVsc5C+Otz7P+8Jo2ouYLbUIvFOMRzrdWTN6bVMytASPZZD9Kt7RT1rq3ZPxZe22ozw3EZ+ 5FojBNHMjxMkqbJI5o9wkFxbzrv8QJseGVR+ZXzXKbdPh8nrZz2kua53rlBRF0HwP9KDHcS8T29n C9xdTR28EYy8kjBVHsB6sx9FUEk8sGnXaLZjN1FXtB+0g0y3YpY2014VODLKfusR/wAIdWkPyyp8 Vnc58Mb5vqOc2n2nV2XJbS7IxZ6LeShwOeAXMbJn/Lz+no91f25fTtXZ1389NvI5GuLa4s3jA2qW jnjmc8ljjkjwyl2wgMkarkjmKmZ4/K08v3GVHed0SHVI9NvrwLqsqxAh4XW2gNxiSCETlPDRmV0A JbmHQkgvk6zThzyuV2te9RwkbnTbvI8w68v7pCtj3OxMn1JPvUZTe2curHmLwJqrW8wZfzwyrKn/ AJImWRP5OuK5nQ9Vu1TTjqOhX3hNG33vS5JYiuA5V4BOFABzlkypC56mu6848fTik1lyh/2Hce26 QT2yPJKFaNxJK5kJV1KhUD7xHGNm5UUKPOTgkknlw5dNmmgd4biZWISLkoBJxnmT8YH9KvSIwXVq 0jHJOKjay6s9M2kEEjB6jqD9D6H61XadJqd1PtskuQNMvW8SRVJs52QNIwjBYwOww7FFG5GJJ2qV 54Wt/Hn8Vz+TH5j0a4M1n7xaxS5y23a+AR508rcjz5kZ/cUymnqeHP2xlZmqNmucc8c22m2U19dv sgt49zEc2Y8gkaL+qSRiEVfUkUvCLl6zbyO7yXebvtZuHklfw4lZhb2ysTHboc4VcYEku3lJOcb2 zjYvlrn5yu64sst81H62gMjb5HYn2ydo/YY/56VPtJxGe2y2epPGjxq58OT88eAY39PMuMH/ANVa VL5XXEPhpKIh4LSkKRFvCwKBzMW95GDSHDA5wnXJACisxRtNLsP0bQOOZrd9SkurPiGyjtxdQWk0 SR6zBaEeFOizxyneowlwkMkciJs8zoIivTJwpeE7uL+HDNa3cZ84aFtpI57o8OAefXCsBn096tpj Zw8c+LdKNpqdxD02zSAfs+R/MNXJXTLvl6l9z7WfvvD1kScvaGWycEblAgkJh3e3/wCaSH/ma6fH eGGc5aHw33CVguNVaCVVgu7wXVpGScxRNEC8HXmsM5l8Pl/YtGOqtVpjFcrWhdrvcouEidwyuADz BBOcH061Nx+ke1naNHFvdavbbTY9RMZ8GWSQbx7I5TH0yQcZxmufPG4unHKVxFsLyI6en+9RFrGT 4G4vkgv7OWIkPHcwlQp6neARy58wSP3qf6pZw9luyLVQHlt8YDfip59wzyDADrzHM/4c+tdWc3yt +Llzca6ZisHpID/aN9p7PdaZoMJ/NE1/c8+jOfAtAQOu1Bdvg4G7wz1UYzzvDn8t50gDxzCqzuiE FI/Kp9+Q559QccvpjrmsvZzVh7SGokRF/tfy7F3ZYDmcdfXOCMAcyTU26TX5o2pRJHKrx+JLLlhK WJ2xgkDAxgDALNy8ysvNduDSZ23SMbGOhM9rJFcQu8EqMs0EsbbZI2Una6MOasOYH0yOYJB6Zkix 6c9zfv8AtvqrJputMlpqDYSK58qWd8WXwyDkAWt0xYsYyxjlP5SrExjWX7UyxRj76HBZstakO0qH KvzB+sZOT7nB/lWHk4yWw6Sk+zG43BTU7AkklYLyNcjJODby7c+pxAPk1p4r3EZx2bu294r/AOyD UIZLCWwutOm2TwGUuMF3UKW2rtmGwh05EE+wydccuWWWOo2LjLsruJTmK8v4UY+aP8GdAPTazmNh /mZ8VvthZHJtb7vF28bQPql9JAzFvBns4Jokds5KL96XaffAzmss8Pbtpjn69OC8TfZ3F2Zk1GZc 5/7chAyfULeD1Ppms54tNP3MV2fdwSKxvFur28uLtYj4kMUdh4K+IhBUyt96m3hTzCgAH1zWkwUv lSX4T7V7e31eysJpHS5uIWmjWSDw1lTe0LrHJuwZVw0hjUE7AW6A4vlZ0eK2ZTL+6ScK1zvbeefa pw7HqPaPFbThlQ2tnb5TBZgtuZlI3AgHfKV6Y/rWVm7quPy3VQR4z01oryeJlKmOZ0KnqNrEEH6j GKy9WK1hgyQP3/ar9NGU1BmSGQjqI2x8leX9TWVVq34DtQZ5TkZSPaoI9iqY/kprll5Vxk2s+L4M TOkKnGxCy9dpPNgvsMY5fPsMd2NTXw4e4fe53GJN6g7D0wWxzHP3/frVrddojpnFet6lPbRRXkjX AgTw4HnYyTRxjpEZSWd0jP5Q5YoAFBVQAMrlL8rSaWPYN2wapomrwX9rgGIsssUpbwZoHGHjcrny MOalQdrBW5lVxtLMeVby9J+HftDNPKtKNDvklmKtO0J08CRwNuTK9xBLLgclaSMMB6Vpj5MbyysW 2p9/+x550jVcDmdlzY8h7lV1A8x68qt+zHHtnZWran9ovpi7c6VrJzkjbPZdB1J233ryx1z9Mco/ fj/UWVrzd/Szugxg0bWjtAz+JbsOfLnsuHOcZ5HmcfQ1X/04TjlT1t+L/p+6X3rhc58LRdaVhhdj iEEn+7lyScZ/50vPPjftaePKts4etb/UZIJxw5qSPGS8E949nA1uXwrMrzyJKm4DmIlbcADhvKav 7TLlrj4c/hMXTJHMcfigLJsXxFDbgHwNwDYG4Zzg4GfYVR6+M45QI+0IsH0vVdC4htyULn7nM6kg ia3/AB7b06vEbgcz/wBFRjrWOUvcYeWfKNPei4A23SavblXsdY3XUTodwjuG81zbSEKoSRJGLBcD KMpGR0rN1yuL2rYcZ+KirstfrmGT2CEn4Xmf6CsMrwXprfDd3suJsnHNsY5k4foAObE5wAOprLFT HtuUF14UoZwDIZBK6AjIZQFjiJ6ZQYU8yPEkP8Jxv206Sv7j3Y3Fr1jqcN5AIorW4QWd9CgiuVuJ /EluUbK7biI5ikCS7/D3bQVBwNccZlOV/Fj7bW3bL3ONa07xJoV/+UtVJbMClpgo9Xtf7QYHUwGU DryFY5eKxNwsRQ1zVSkxSdPDIU4jIYPnqMq2PcHn6VEsnbluXOq7V2EifVpEgTh0aqOhntkSwjiX pumu/AawJHUgrvOP1HFbYZ36JjbeN/8AE5+D+5TooSKS80yASg7mtxKs8ef4ZJVtrUyj3QIE9POM 56O3Vh+PrnKpBWulRRqqJFGiIoVERFVVVRgKqqAFUDkAAABR16n0uI4wOgA+ABUmo+gkqDUfhap2 PyoHO+3DsSs+INMk029DiN9kkUsZxLb3EYPhTx58paMk+VwVdSykYNSrlj7TVeWnFb6lwtPcaBrM KXVnLl4C4b7vcxgkJd2cmd0Uq/rQHfC+VO5dpfm8mFl3HJrXFcf1OBCzGE5jJJRWYM6r6KWAUMR/ FtGfaq7+1dPtayEoythQVIJbPQjB9h0PvVbpOqtoNVtrcgQL4ly3LxT533HkfAiX9WM8xuI5nK+j HCq6k7Y6O5kllWK3U3F1KyxIkXnO+QhVhjIJV5nY7WZSVXcVDHMjVt6q9vbju5dkg0PRrLTyQ06R iS7dej3coDTkdfIr/hpzPkRa1k1Hfhj6x0sGpXY3WOGra4AFxbW84HTxoY5cfHiI2KWS9o1F9bwK ihEVURRhVQBVAHQBQAAB7AVO08R9KgKBQKBQKCiLoPgf6UGJ4s4NtL+Bra9toLu3f80NxEksZPvt cEBh6MMEe4oal7R2l+zw0KN5ns3urPxs7oibe8gAJyFRL2Cd0VTuK7JlIyBnCqBFxjP9c+Ee+0v7 KO6WOR9N1VbpxlltriH7mzjl5RcrJcxgjzbQYEBBUb1wWMeuulMvFftEHtO7IL3RzJaXVnPp8hRe UibvvY3edRdglZU25cLG5Q7Su0ZrPLKzty5YWM92M93PV57Vtdt4pYbWzlQw3SHDi5jYMs0SdZIb eRQJX/IGITJxJtm25Y8EwutvZTsk47fULGKaaPwLtfwb23yD4N3HgTICOqMfxI2/VG6mtMeZu9/L vwu43KpWKBQKBQKBQKBQUQ9B8CgroFAobYziLhm3vIWt7uCG5gf88NxEk0Te2UkDKce+Kd9i6tdN jSMQpGiRKnhrEqKsax4xsCKAoTHLaBjFBhODuzy0sA33aIRl1iSR8sWkWBPDi3knBKJ5QcAke9ES SdNkokoFAoFAoFAoFBRD0HwKCugUCgUCgUCgUCgUCgUCgUCgoh6D4FBXQKBQKBQKBQKBQKBQKBQK BQUQ9B8CgroFAoFAoFAoFAoFAoFAoFAoP//Z --089e0158c2d4edbef8051f0cd4f3-- From alex@zadarastorage.com Sun Sep 6 05:19:59 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.9 required=5.0 tests=STOX_REPLY_TYPE,TVD_FINGER_02 autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 011297F66 for ; Sun, 6 Sep 2015 05:19:59 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id E4B7030405F for ; Sun, 6 Sep 2015 03:19:58 -0700 (PDT) X-ASG-Debug-ID: 1441534793-04cbb06acab51a0001-NocioJ Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by cuda.sgi.com with ESMTP id BjPh5xyFs0EshKrH (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 06 Sep 2015 03:19:53 -0700 (PDT) X-Barracuda-Envelope-From: alex@zadarastorage.com X-Barracuda-Apparent-Source-IP: 209.85.212.176 Received: by wiclk2 with SMTP id lk2so60663860wic.0 for ; Sun, 06 Sep 2015 03:19:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-type:content-transfer-encoding :importance; bh=PkWdFVQVpow6sT92x7cthw7FKRBhSFGa5FuBXrLl4+4=; b=SadyA33HvEmAv1qnxV+LB4bfKXaAssEcZeV0YbPNvo6srplTwYoC+oIMJOj3Tza/Z+ PU7s1EXRXplrqD+EoZE0e0l4taUPXcJUBv7aqEDJnUaPI3HqpLe/WIzA6ei1HvTeCaFz H+k4k44Kg4/HTco5ieX6o1L0LNSW+gkrIbgecxVMNrJmSKRePmWZnMqbGbHeFfY5aPr+ AbwiIqy7PiYBZN+LsUYsKHPegRoSp5S7kUrGufUzVkR71TRQ8c919dDcznhRzMfnb4QU KSnAAuoks6X4hlxTMl7nGZrgAy7xE2dtVqxqi5P6F679XJ+NjATvmMorkf/UsXq/dDix XO0g== X-Gm-Message-State: ALoCoQncq2OIlruDJIEJtMF3RWUZsR99/EqwPMQoKWKrvNoMp30HcEJZNIbWl7l2XbJyU1OkN8BA X-Received: by 10.194.203.74 with SMTP id ko10mr14711875wjc.72.1441534792563; Sun, 06 Sep 2015 03:19:52 -0700 (PDT) Received: from alyakaslap (bzq-169-168-31-234.red.bezeqint.net. [31.168.169.234]) by smtp.gmail.com with ESMTPSA id cx3sm13389916wjc.27.2015.09.06.03.19.50 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 06 Sep 2015 03:19:51 -0700 (PDT) Message-ID: <42D7AA163AD247998B82E3C75D289FC2@alyakaslap> From: "Alex Lyakas" To: "Danny Shavit" , "Eric Sandeen" Cc: References: <55E8498F.8090508@sandeen.net> <55E85F5F.6010005@sandeen.net> <55E871EF.4040603@sandeen.net> In-Reply-To: <55E871EF.4040603@sandeen.net> Subject: Re: xfs corruption Date: Sun, 6 Sep 2015 12:19:49 +0200 X-ASG-Orig-Subj: Re: xfs corruption MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Barracuda-Connect: mail-wi0-f176.google.com[209.85.212.176] X-Barracuda-Start-Time: 1441534793 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, STOX_REPLY_TYPE, TVD_FINGER_02 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22282 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 STOX_REPLY_TYPE STOX_REPLY_TYPE 0.00 TVD_FINGER_02 TVD_FINGER_02 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hi Eric, Thank you for your comments. Yes, we made the ACL limit change, being fully aware that this breaks compatibility with the mainline kernel and future mainline kernels. We mount our XFS filesystems with our kernel only. We are also aware that this change needs to be carefully forward-ported, when we move to a newer kernel. I have an additional question regarding the latest XFS corruption report: kernel: [3507105.314446] Pid: 25231, comm: kworker/0:0H Tainted: GF W O 3.8.13-030813-generic #201305111843 kernel: [3507105.314449] Call Trace: kernel: [3507105.314487] [] xfs_error_report+0x3f/0x50 [xfs] kernel: [3507105.314502] [] ? xfs_allocbt_read_verify+0xe/0x10 [xfs] kernel: [3507105.314514] [] xfs_corruption_error+0x5e/0x90 [xfs] kernel: [3507105.314528] [] xfs_allocbt_verify+0x92/0x1e0 [xfs] kernel: [3507105.314540] [] ? xfs_allocbt_read_verify+0xe/0x10 [xfs] kernel: [3507105.314547] [] ? __switch_to+0x12a/0x4a0 kernel: [3507105.314551] [] ? set_next_entity+0xa8/0xc0 kernel: [3507105.314566] [] xfs_allocbt_read_verify+0xe/0x10 [xfs] kernel: [3507105.315251] [] xfs_buf_iodone_work+0x3f/0xa0 [xfs] kernel: [3507105.315255] [] process_one_work+0x141/0x490 kernel: [3507105.315257] [] worker_thread+0x168/0x400 kernel: [3507105.315259] [] ? manage_workers+0x120/0x120 kernel: [3507105.315262] [] kthread+0xc0/0xd0 kernel: [3507105.315265] [] ? flush_kthread_worker+0xb0/0xb0 kernel: [3507105.315270] [] ret_from_fork+0x7c/0xb0 kernel: [3507105.315273] [] ? flush_kthread_worker+0xb0/0xb0 kernel: [3507105.315275] XFS (dm-39): Corruption detected. Unmount and run xfs_repair kernel: [3507105.316706] XFS (dm-39): metadata I/O error: block 0x41a6eff8 ("xfs_trans_read_buf_map") error 117 numblks 8 >From looking at XFS code, it appears that XFS read metadata block from disk, and discovered that it was corrupted. At this point, the system was rebooted, and after reboot we prevented this particular XFS from mounting. Then we ran xfs-metadump and xfs-repair. The latter found absolutely no issues, and XFS was able to successfully mount and continue operation. Can you think of a way to explain this? Can you confirm that the above trace really means that XFS was reading its metadata from disk? >From XFS code, I see that XFS does not use Linux page cache for its metadata (unlike btrfs, for example). Is my understanding correct? (Otherwise, I could assume that somebody wrongly touched a page in the page-cache and messed up its in-memory content). Thanks, Alex. -----Original Message----- From: Eric Sandeen Sent: 03 September, 2015 6:14 PM To: Danny Shavit Cc: Alex Lyakas ; xfs@oss.sgi.com Subject: Re: xfs corruption On 9/3/15 9:55 AM, Eric Sandeen wrote: > On 9/3/15 9:26 AM, Danny Shavit wrote: ... >> We are using modified xfs. Mainly, added some reporting features and >> changed discard operation to be aligned with chunk sizes used in our >> systems. The modified code resides at https://github.com/zadarastora >> ge/zadara-xfs-pushback >> . > > Interesting, thanks for the pointer. I guess at this point I have to > ask, do you see these same problems without your modifications? Have you ever mounted this filesystem on non-zadara kernels? looking at https://github.com/zadarastorage/zadara-xfs-pushback/commit/094df949fd080ede546bb7518405ab873a444823 you've changed the disk format w/o adding a feature flag, which is pretty dangerous. -Eric From debt.recovery@eim.ae Sun Sep 6 07:45:31 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_FONT_SIZE_LARGE, HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 1F02A7F6D for ; Sun, 6 Sep 2015 07:45:31 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 0DCE530405F for ; Sun, 6 Sep 2015 05:45:30 -0700 (PDT) X-ASG-Debug-ID: 1441543523-04cbb06accb83e0001-NocioJ Received: from acmomail1.d.emirates.net.ae (acmomail1.d.emirates.net.ae [86.96.131.224]) by cuda.sgi.com with ESMTP id JaCd3UN0eNOpL3lH for ; Sun, 06 Sep 2015 05:45:24 -0700 (PDT) X-Barracuda-Envelope-From: debt.recovery@eim.ae X-Barracuda-Apparent-Source-IP: 86.96.131.224 Received: from 708-PC ([86.97.225.199]) by acmomail1.emirates.net.ae with Server id DolN1r0044JlA8N01olN3l; Sun, 06 Sep 2015 16:45:23 +0400 X-EIM-Analysis: v=2.1 cv=H8xVwooi c=1 sm=1 tr=0 p=8zZS6Qw1AAAA:20 p=1lk_4vSsAAAA:20 p=ujdPjMyDH9sA:10 p=PaLkhUv4Yt4A:10 a=AA6i17bL+IXEbFuffePXlw==:117 a=AA6i17bL+IXEbFuffePXlw==:17 a=vBMKzl_6AAAA:8 a=r77TgQKjGQsHNAKrUKIA:9 a=P7KtetdqZ7l6l091HBoA:9 a=32WQKK-l0BJZNrwm:21 a=GUnnfsr0Fw4E6-YM:21 a=pILNOxqGKmIA:10 a=2gB_jVR22FMeOnJwYDcA:9 a=K0fxSGSTak8wkG78:21 a=CYvXF57MzE9KH_AA:21 a=6qcMrhyvOAi3GN7e:21 a=_W_S_7VecoQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 Organization: P M Message-ID: <7cb169896e24500e4f060256001a87b1@eim.ae> From: "Internet marketing" To: "=?windows-1252?Q?CFO_/_CEO?=" Subject: Recover Unpaid Invoices Date: Sun, 6 Sep 2015 16:45:59 +0400 X-ASG-Orig-Subj: Recover Unpaid Invoices MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=SPLITOR00A_001_-934981882D" X-Barracuda-Connect: acmomail1.d.emirates.net.ae[86.96.131.224] X-Barracuda-Start-Time: 1441543523 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_FONT_SIZE_LARGE, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22284 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_FONT_SIZE_LARGE BODY: HTML font size is large 0.00 HTML_MESSAGE BODY: HTML included in message This is a multi-part message in MIME format. ------=SPLITOR00A_001_-934981882D Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Control Panel Global Debt Collector Worldwide Debt Collection Associates Recover Outstanding Payments (Bounced Cheques, Invoices) We would like to offer our services to our customers in=A0 credit administration to recover their outstanding Balances Recover=A0Bounced Cheque=92s=A0 Recover Unpaid Invoices=A0 Resolve Real Estate Disputes Our service charges are Result oriented.=A0 Contact us=A0 Global Debt Collector =A0 Submitt your Claim Now Submitt Inquiry In-case you don't want to receive any more E-mails from us : then = Unsubscribe from this list =A0 ------=SPLITOR00A_001_-934981882D Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable

Worldwide Debt = Collection=20 Associate
Recover = Outstanding=20 Payments
(Bounced Cheques, Invoices)

 

We would like to offer = our services=20 to our customers in 
credit administration to recover their = outstanding=20 Balances

 

Recover Bounced=20 Cheque=92s 
Recover Unpaid Invoices 
Resolve Real Estate=20 Disputes
Our service charges are Result oriented. 

 


Contact us 
Global Debt=20 Collector
00971-56-6300520
 

 

Submitt your Claim = Now
Submitt=20 Inquiry

 

In-case you don't want to receive = any more=20 E-mails from us
Kindly Reply With=20  "Unsubscribe" 

------=SPLITOR00A_001_-934981882D-- From sandeen@sandeen.net Sun Sep 6 16:56:17 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 659F97F50 for ; Sun, 6 Sep 2015 16:56:17 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 46F738F8049 for ; Sun, 6 Sep 2015 14:56:13 -0700 (PDT) X-ASG-Debug-ID: 1441576571-04cb6c0e0cb2e20001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id egmY9vv8mkmTVoeq for ; Sun, 06 Sep 2015 14:56:12 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 861DF63D104C; Sun, 6 Sep 2015 16:56:11 -0500 (CDT) Subject: Re: xfs corruption To: Alex Lyakas , Danny Shavit X-ASG-Orig-Subj: Re: xfs corruption References: <55E8498F.8090508@sandeen.net> <55E85F5F.6010005@sandeen.net> <55E871EF.4040603@sandeen.net> <42D7AA163AD247998B82E3C75D289FC2@alyakaslap> Cc: xfs@oss.sgi.com From: Eric Sandeen X-Enigmail-Draft-Status: N1110 Message-ID: <55ECB67A.2070707@sandeen.net> Date: Sun, 6 Sep 2015 16:56:10 -0500 MIME-Version: 1.0 In-Reply-To: <42D7AA163AD247998B82E3C75D289FC2@alyakaslap> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441576571 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22293 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/6/15 5:19 AM, Alex Lyakas wrote: > Hi Eric, > Thank you for your comments. > > Yes, we made the ACL limit change, being fully aware that this breaks > compatibility with the mainline kernel and future mainline kernels. > We mount our XFS filesystems with our kernel only. We are also aware > that this change needs to be carefully forward-ported, when we move > to a newer kernel. Ok, sorry for the lecture... ;) I did want to make sure it hadn't been mounted on an unmodified kernel, though. > I have an additional question regarding the latest XFS corruption report: > kernel: [3507105.314446] Pid: 25231, comm: kworker/0:0H Tainted: GF W O 3.8.13-030813-generic #201305111843 > kernel: [3507105.314449] Call Trace: > kernel: [3507105.314487] [] xfs_error_report+0x3f/0x50 [xfs] > kernel: [3507105.314502] [] ? xfs_allocbt_read_verify+0xe/0x10 [xfs] > kernel: [3507105.314514] [] xfs_corruption_error+0x5e/0x90 [xfs] > kernel: [3507105.314528] [] xfs_allocbt_verify+0x92/0x1e0 [xfs] > kernel: [3507105.314540] [] ? xfs_allocbt_read_verify+0xe/0x10 [xfs] > kernel: [3507105.314547] [] ? __switch_to+0x12a/0x4a0 > kernel: [3507105.314551] [] ? set_next_entity+0xa8/0xc0 > kernel: [3507105.314566] [] xfs_allocbt_read_verify+0xe/0x10 [xfs] > kernel: [3507105.315251] [] xfs_buf_iodone_work+0x3f/0xa0 [xfs] > kernel: [3507105.315255] [] process_one_work+0x141/0x490 > kernel: [3507105.315257] [] worker_thread+0x168/0x400 > kernel: [3507105.315259] [] ? manage_workers+0x120/0x120 > kernel: [3507105.315262] [] kthread+0xc0/0xd0 > kernel: [3507105.315265] [] ? flush_kthread_worker+0xb0/0xb0 > kernel: [3507105.315270] [] ret_from_fork+0x7c/0xb0 > kernel: [3507105.315273] [] ? flush_kthread_worker+0xb0/0xb0 > kernel: [3507105.315275] XFS (dm-39): Corruption detected. Unmount and run xfs_repair > kernel: [3507105.316706] XFS (dm-39): metadata I/O error: block 0x41a6eff8 ("xfs_trans_read_buf_map") error 117 numblks 8 > > From looking at XFS code, it appears that XFS read metadata block > from disk, and discovered that it was corrupted. Yes. Unfortunately the verifier didn't say what it thinks is wrong. I'd have to look to see for sure, but I think that on your kernel version, if you turn up the xfs error level sysctl, you should get a hexdump of the first 64 bytes of the buffer when this happens, and that would hopefully tell us enough to know what was wrong, and - > At this point, the > system was rebooted, and after reboot we prevented this particular > XFS from mounting. Then we ran xfs-metadump and xfs-repair. The > latter found absolutely no issues, and XFS was able to successfully > mount and continue operation. - and why repair found no issue With the buffer dump, and then from that hopefully knowing what the verifier didn't like, we could then check your repair version and be sure it is performing the same checks as the verifier -Eric > Can you think of a way to explain this? > Can you confirm that the above trace really means that XFS was reading its metadata from disk? > From XFS code, I see that XFS does not use Linux page cache for its > metadata (unlike btrfs, for example). Is my understanding correct? > (Otherwise, I could assume that somebody wrongly touched a page in > the page-cache and messed up its in-memory content). > > Thanks, > Alex. > > > > > > -----Original Message----- From: Eric Sandeen > Sent: 03 September, 2015 6:14 PM > To: Danny Shavit > Cc: Alex Lyakas ; xfs@oss.sgi.com > Subject: Re: xfs corruption > > On 9/3/15 9:55 AM, Eric Sandeen wrote: >> On 9/3/15 9:26 AM, Danny Shavit wrote: > > ... > >>> We are using modified xfs. Mainly, added some reporting features and >>> changed discard operation to be aligned with chunk sizes used in our >>> systems. The modified code resides at https://github.com/zadarastora >>> ge/zadara-xfs-pushback >>> . >> >> Interesting, thanks for the pointer. I guess at this point I have to >> ask, do you see these same problems without your modifications? > > Have you ever mounted this filesystem on non-zadara kernels? > > looking at > https://github.com/zadarastorage/zadara-xfs-pushback/commit/094df949fd080ede546bb7518405ab873a444823 > > you've changed the disk format w/o adding a feature flag, > which is pretty dangerous. > > -Eric From david@fromorbit.com Mon Sep 7 00:26:33 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id E66507F4E for ; Mon, 7 Sep 2015 00:26:33 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id D4795304039 for ; Sun, 6 Sep 2015 22:26:30 -0700 (PDT) X-ASG-Debug-ID: 1441603585-04cbb06acdc8630001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id sHPwI6RAL2UMQz0t for ; Sun, 06 Sep 2015 22:26:26 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CGDQDaHu1VPOV8LHlegyMjMWmCVoN8om0MAQEBAQEBBoplixcChXsEgSZNAQEBAQEBBwEBAQFAAT+FABgjJDQFJQMHLYgtpFOkBxmGE4gvhFQMQR2BFAWVVYUKgm2FAIFPRowfhBGINYF8gjwsMwEBAQGIRQEBAQ Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 07 Sep 2015 14:56:24 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZYowh-000655-Mf for xfs@oss.sgi.com; Mon, 07 Sep 2015 15:26:23 +1000 Date: Mon, 7 Sep 2015 15:26:23 +1000 From: Dave Chinner To: xfs@oss.sgi.com Subject: [ANNOUNCE] xfsprogs: v4.2.0 released Message-ID: <20150907052623.GE3902@dastard> X-ASG-Orig-Subj: [ANNOUNCE] xfsprogs: v4.2.0 released MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oPmsXEqKQNHCSXW7" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1441603585 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22301 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- --oPmsXEqKQNHCSXW7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi folks, The xfsprogs repositories have just been updated and tagged with the v4.2.0 release tag. It can be found here: git://oss.sgi.com/xfs/cmds/xfsprogs.git v4.2.0 git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git v4.2.0 A signed gzipped-tar archive of the source code is available here: ftp://oss.sgi.com/projects/xfs/cmd_tars/xfsprogs-4.2.0.tar.gz ftp://oss.sgi.com/projects/xfs/cmd_tars/xfsprogs-4.2.0.tar.gz.sign The archive is signed with my gpg key (the same one that this release announcement is signed with). There has been a large amount of change since v3.2.4: 297 files changed, 12703 insertions(+), 11987 deletions(-) and so many thanks go out to all the contributors to this release (in no particular order): Theodore Ts'o Roger Willcocks Mike Grant Lucas Stach Jan Tulak Jan Kara George Wang Eryu Guan Eric Sandeen Darrick J. Wong Christoph Hellwig Brian Foster The main driver for the all this change has been to get the shared libxfs code up to the same base as the released 4.2 kernel codebase and to put tools and processes in place to easily maintain the shared libxfs code base in future. The numbering of this release should now be obvious - it matches the version of the kernel that shares the same libxfs/ code. In future, the major/minor release numbers for xfsprogs will follow the version of the shared libxfs code. This makes it easy to work out what version of xfsprogs supports the features of a given kernel - if the xfsprogs version is the same or higher than the kernel version, then it will support all the features of the kernel that is running. Problems, issues, questions and general discussion about the release should be directed to the XFS mailing list (xfs@oss.sgi.com). -Dave. The new head of the master branch is commit: 28f55cc xfsprogs: Release v4.2.0 New Commits since 4.2.0-rc3: Brian Foster (1): [350f962] xfs_repair: update btree ptr when attr node level moves to = next buffer Darrick J. Wong (7): [7fc5180] libxfs: verifier should set buffer error when da block has = a bad magic number [1f2ace6] libxfs: fix XFS_WANT_CORRUPTED_* macros to return negative = error codes [e8ecd76] libxfs: clear buffer state flags in libxfs_getbuf and varia= nts [aedb9c1] xfs_repair: ignore "repaired" flag after we decide to clear= xattr block [1c8e2f0] xfs_repair: check v5 filesystem attr block header sanity [43ba186] xfs_repair: force not-so-bad bmbt blocks back through the v= erifier [f625305] xfs_repair: release corrupt directory node buffer Dave Chinner (1): [28f55cc] xfsprogs: Release v4.2.0 Eric Sandeen (2): [fe0591e] xfs_repair: set args.geo in dir2_kill_block [a545950] xfs_repair: set args.geo in longform_dir2_entry_check_data Lucas Stach (1): [f4a2ea0] progs: use CURDIR instead of relative paths for header syml= inks Code Diffstat: VERSION | 2 +- configure.ac | 2 +- debian/changelog | 6 +++++ doc/CHANGES | 9 ++++++++ include/Makefile | 2 +- libxfs/Makefile | 2 +- libxfs/libxfs_priv.h | 7 +++--- libxfs/rdwr.c | 47 +++++++++++++++++++++++++++++++++----- libxfs/xfs_da_btree.c | 1 + repair/attr_repair.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++= ++-- repair/dir2.c | 1 + repair/phase6.c | 2 ++ repair/prefetch.c | 12 ++++++++++ 13 files changed, 139 insertions(+), 16 deletions(-) --=20 Dave Chinner david@fromorbit.com --oPmsXEqKQNHCSXW7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJV7R//AAoJEK3oKUf0dfodRXAQAMBHwR6kaImDGqHfFFoO9eWH RQtTyjT4tvFZWkqZ/LiwcDFuNk1nfG/1cSgvzJ0OdVfzcMgVH0sQCS/LQCMZn/Lo a80bGiP1m40gjVjj+BpbGEj7aDlPEPrG6MOT0xBo2MUqg3HONB6EpqmbtfmYZVGL dDtmeryUe+QuZzOcQ0ys92DLsf1VoMhn9wB8PnWqtCfCIe+lCNjNdeyxVkpciVij 9GrwufKQSUSTf7vsdzVwWHzwG37PNk13pBKlfoohe8aPGaSuPjsh3gHOF6VBDsQh Wzci/m2SVrFLVjc/K3tOuH3mookmlqsrTL3sHESCA5Wsiqmdn8tn/PVNkPGRWj7r lQGYJ6tzU+Q+Zjv41WmGVZ/0Us0uerMlTt2drbxsdnwAOWHlXK4lBMIqvKa3p5H7 p7LThhpbrgwrp+I2CROaOaBR3aRiVtiOLzNYEiDrg3ZT0WwUpfrhxeqBgVZg30KB zokiXhyoL4YE67zJAlnJZB+hpAHO54uyt74Pa+P8eVQCd3xp662t7hEnKHi8q3Pn I0ywVawM1g7/RN/lxbJ0Up0TLalJ9PeNh6msKKK9fjx+SLyaLJbdnMO6Z96joxZI 3OiSaRAZ+uxbYFEv/BKneSR1A1XV9wHpZC/qpd+JQgkAuQ8GupkmbOuJVSe8o1Qj PmEDH3ChLVMMnGTSiinF =m3JI -----END PGP SIGNATURE----- --oPmsXEqKQNHCSXW7-- From alex@zadarastorage.com Mon Sep 7 03:30:42 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.9 required=5.0 tests=STOX_REPLY_TYPE,TVD_FINGER_02 autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id CBAAA7F51 for ; Mon, 7 Sep 2015 03:30:42 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id BB29F304048 for ; Mon, 7 Sep 2015 01:30:39 -0700 (PDT) X-ASG-Debug-ID: 1441614636-04cb6c0e0cbcfe0001-NocioJ Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by cuda.sgi.com with ESMTP id vL3Mva7CwiL1sm23 (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 07 Sep 2015 01:30:36 -0700 (PDT) X-Barracuda-Envelope-From: alex@zadarastorage.com X-Barracuda-Apparent-Source-IP: 209.85.212.170 Received: by wicfx3 with SMTP id fx3so75271919wic.0 for ; Mon, 07 Sep 2015 01:30:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-type:content-transfer-encoding :importance; bh=xdCWvLdjTzJIdyXg0s4BRnd47ikMdpaf4lusnElqwhA=; b=QzDffvA35unPs53Qf1R/wf3AKDdSYHEiPjV3v7ekEKAFONoU1iMF4r8grglm9mD2h4 Jm5K4ZmX/u7xL3COwAR4TMedLNk3orTFsrH7dSjkdDnMLlCFx6i92rT1daeBZq1Bp/+O 02vr36h8UU4/PdNy+FuPJgxpTMPgl+wpPj0PwoP522S9vbgaPo8trLUFUQBlcM9OKp6P ttfTsSMATKClpy3YeW3KUsElo59svYWGsyMA15uoZK3Fifu/+h/mNtv3Rj0KvnKv6i4B mradqIPZibVU4DZx+KTj4Q/BNzU5Jpr1BlSQQjMu/U2yUjIucr2inah/+VoTA1uyWNlL jUBA== X-Gm-Message-State: ALoCoQnUsO2uJ5xEMkmky7I5Mk5ikobb1WuGTarVj5Ucdaw3F89d0rWRDXPdyV/fKUz/7G2AAmue X-Received: by 10.194.78.194 with SMTP id d2mr23255939wjx.95.1441614635649; Mon, 07 Sep 2015 01:30:35 -0700 (PDT) Received: from alyakaslap (bzq-169-168-31-234.red.bezeqint.net. [31.168.169.234]) by smtp.gmail.com with ESMTPSA id s9sm18714902wjy.16.2015.09.07.01.30.34 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Sep 2015 01:30:34 -0700 (PDT) Message-ID: <6E5CB37CB1824062A3642A760C72DAE4@alyakaslap> From: "Alex Lyakas" To: "Eric Sandeen" Cc: , "Danny Shavit" References: <55E8498F.8090508@sandeen.net> <55E85F5F.6010005@sandeen.net> <55E871EF.4040603@sandeen.net> <42D7AA163AD247998B82E3C75D289FC2@alyakaslap> <55ECB67A.2070707@sandeen.net> In-Reply-To: <55ECB67A.2070707@sandeen.net> Subject: Re: xfs corruption Date: Mon, 7 Sep 2015 10:30:34 +0200 X-ASG-Orig-Subj: Re: xfs corruption MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Barracuda-Connect: mail-wi0-f170.google.com[209.85.212.170] X-Barracuda-Start-Time: 1441614636 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.00 X-Barracuda-Spam-Status: No, SCORE=1.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_TG232, STOX_REPLY_TYPE, TVD_FINGER_02 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22304 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 STOX_REPLY_TYPE STOX_REPLY_TYPE 0.00 TVD_FINGER_02 TVD_FINGER_02 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 1.00 BSF_SC0_TG232 BODY: Custom Rule TG232 Hi Eric, This is what the verifier said, sorry for not posting it fully: Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.306317] ffff88000617d000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.307743] XFS (dm-39): Internal error xfs_allocbt_verify at line 330 of file /mnt/share/builds/14.11--3.8.13-030813-generic/2015-04-29_10-45-42--14.11-1601-124/src/zadara-btrfs/fs/xfs/xfs_alloc_btree.c. Caller 0xffffffffa064e9ce Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.307743] Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.314446] Pid: 25231, comm: kworker/0:0H Tainted: GF W O 3.8.13-030813-generic #201305111843 Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.314449] Call Trace: Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.314487] [] xfs_error_report+0x3f/0x50 [xfs] Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.314502] [] ? xfs_allocbt_read_verify+0xe/0x10 [xfs] Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.314514] [] xfs_corruption_error+0x5e/0x90 [xfs] Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.314528] [] xfs_allocbt_verify+0x92/0x1e0 [xfs] Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.314540] [] ? xfs_allocbt_read_verify+0xe/0x10 [xfs] Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.314547] [] ? __switch_to+0x12a/0x4a0 Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.314551] [] ? set_next_entity+0xa8/0xc0 Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.314566] [] xfs_allocbt_read_verify+0xe/0x10 [xfs] Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.315251] [] xfs_buf_iodone_work+0x3f/0xa0 [xfs] Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.315255] [] process_one_work+0x141/0x490 Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.315257] [] worker_thread+0x168/0x400 Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.315259] [] ? manage_workers+0x120/0x120 Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.315262] [] kthread+0xc0/0xd0 Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.315265] [] ? flush_kthread_worker+0xb0/0xb0 Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.315270] [] ret_from_fork+0x7c/0xb0 Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.315273] [] ? flush_kthread_worker+0xb0/0xb0 Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.315275] XFS (dm-39): Corruption detected. Unmount and run xfs_repair Aug 27 01:01:34 vsa-0000014e-vc-0 kernel: [3507105.316706] XFS (dm-39): metadata I/O error: block 0x41a6eff8 ("xfs_trans_read_buf_map") error 117 numblks 8 The verifier function is [1], line 330 is where is goes "XFS_CORRUPTION_ERROR". xfs_repair version: root@vsa-0000003f-vc-0:~# xfs_repair -V xfs_repair version 3.1.7 xfs_progs are stock what's coming in ubuntu 12.04 distribution (we didn't mess with that;). Thanks for your help, Alex. [1] static void xfs_allocbt_verify( struct xfs_buf *bp) { struct xfs_mount *mp = bp->b_target->bt_mount; struct xfs_btree_block *block = XFS_BUF_TO_BLOCK(bp); struct xfs_perag *pag = bp->b_pag; unsigned int level; int sblock_ok; /* block passes checks */ /* * magic number and level verification * * During growfs operations, we can't verify the exact level as the * perag is not fully initialised and hence not attached to the buffer. * In this case, check against the maximum tree depth. */ level = be16_to_cpu(block->bb_level); switch (block->bb_magic) { case cpu_to_be32(XFS_ABTB_MAGIC): if (pag) sblock_ok = level < pag->pagf_levels[XFS_BTNUM_BNOi]; else sblock_ok = level < mp->m_ag_maxlevels; break; case cpu_to_be32(XFS_ABTC_MAGIC): if (pag) sblock_ok = level < pag->pagf_levels[XFS_BTNUM_CNTi]; else sblock_ok = level < mp->m_ag_maxlevels; break; default: sblock_ok = 0; break; } /* numrecs verification */ sblock_ok = sblock_ok && be16_to_cpu(block->bb_numrecs) <= mp->m_alloc_mxr[level != 0]; /* sibling pointer verification */ sblock_ok = sblock_ok && (block->bb_u.s.bb_leftsib == cpu_to_be32(NULLAGBLOCK) || be32_to_cpu(block->bb_u.s.bb_leftsib) < mp->m_sb.sb_agblocks) && block->bb_u.s.bb_leftsib && (block->bb_u.s.bb_rightsib == cpu_to_be32(NULLAGBLOCK) || be32_to_cpu(block->bb_u.s.bb_rightsib) < mp->m_sb.sb_agblocks) && block->bb_u.s.bb_rightsib; if (!sblock_ok) { trace_xfs_btree_corrupt(bp, _RET_IP_); XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp, block); xfs_buf_ioerror(bp, EFSCORRUPTED); } } -----Original Message----- From: Eric Sandeen Sent: 06 September, 2015 11:56 PM To: Alex Lyakas ; Danny Shavit Cc: xfs@oss.sgi.com Subject: Re: xfs corruption On 9/6/15 5:19 AM, Alex Lyakas wrote: > Hi Eric, > Thank you for your comments. > > Yes, we made the ACL limit change, being fully aware that this breaks > compatibility with the mainline kernel and future mainline kernels. > We mount our XFS filesystems with our kernel only. We are also aware > that this change needs to be carefully forward-ported, when we move > to a newer kernel. Ok, sorry for the lecture... ;) I did want to make sure it hadn't been mounted on an unmodified kernel, though. > I have an additional question regarding the latest XFS corruption report: > kernel: [3507105.314446] Pid: 25231, comm: kworker/0:0H Tainted: GF > W O 3.8.13-030813-generic #201305111843 > kernel: [3507105.314449] Call Trace: > kernel: [3507105.314487] [] xfs_error_report+0x3f/0x50 > [xfs] > kernel: [3507105.314502] [] ? > xfs_allocbt_read_verify+0xe/0x10 [xfs] > kernel: [3507105.314514] [] > xfs_corruption_error+0x5e/0x90 [xfs] > kernel: [3507105.314528] [] > xfs_allocbt_verify+0x92/0x1e0 [xfs] > kernel: [3507105.314540] [] ? > xfs_allocbt_read_verify+0xe/0x10 [xfs] > kernel: [3507105.314547] [] ? __switch_to+0x12a/0x4a0 > kernel: [3507105.314551] [] ? set_next_entity+0xa8/0xc0 > kernel: [3507105.314566] [] > xfs_allocbt_read_verify+0xe/0x10 [xfs] > kernel: [3507105.315251] [] > xfs_buf_iodone_work+0x3f/0xa0 [xfs] > kernel: [3507105.315255] [] > process_one_work+0x141/0x490 > kernel: [3507105.315257] [] worker_thread+0x168/0x400 > kernel: [3507105.315259] [] ? > manage_workers+0x120/0x120 > kernel: [3507105.315262] [] kthread+0xc0/0xd0 > kernel: [3507105.315265] [] ? > flush_kthread_worker+0xb0/0xb0 > kernel: [3507105.315270] [] ret_from_fork+0x7c/0xb0 > kernel: [3507105.315273] [] ? > flush_kthread_worker+0xb0/0xb0 > kernel: [3507105.315275] XFS (dm-39): Corruption detected. Unmount and run > xfs_repair > kernel: [3507105.316706] XFS (dm-39): metadata I/O error: block 0x41a6eff8 > ("xfs_trans_read_buf_map") error 117 numblks 8 > > From looking at XFS code, it appears that XFS read metadata block > from disk, and discovered that it was corrupted. Yes. Unfortunately the verifier didn't say what it thinks is wrong. I'd have to look to see for sure, but I think that on your kernel version, if you turn up the xfs error level sysctl, you should get a hexdump of the first 64 bytes of the buffer when this happens, and that would hopefully tell us enough to know what was wrong, and - > At this point, the > system was rebooted, and after reboot we prevented this particular > XFS from mounting. Then we ran xfs-metadump and xfs-repair. The > latter found absolutely no issues, and XFS was able to successfully > mount and continue operation. - and why repair found no issue With the buffer dump, and then from that hopefully knowing what the verifier didn't like, we could then check your repair version and be sure it is performing the same checks as the verifier -Eric > Can you think of a way to explain this? > Can you confirm that the above trace really means that XFS was reading its > metadata from disk? > From XFS code, I see that XFS does not use Linux page cache for its > metadata (unlike btrfs, for example). Is my understanding correct? > (Otherwise, I could assume that somebody wrongly touched a page in > the page-cache and messed up its in-memory content). > > Thanks, > Alex. > > > > > > -----Original Message----- From: Eric Sandeen > Sent: 03 September, 2015 6:14 PM > To: Danny Shavit > Cc: Alex Lyakas ; xfs@oss.sgi.com > Subject: Re: xfs corruption > > On 9/3/15 9:55 AM, Eric Sandeen wrote: >> On 9/3/15 9:26 AM, Danny Shavit wrote: > > ... > >>> We are using modified xfs. Mainly, added some reporting features and >>> changed discard operation to be aligned with chunk sizes used in our >>> systems. The modified code resides at https://github.com/zadarastora >>> ge/zadara-xfs-pushback >>> . >> >> Interesting, thanks for the pointer. I guess at this point I have to >> ask, do you see these same problems without your modifications? > > Have you ever mounted this filesystem on non-zadara kernels? > > looking at > https://github.com/zadarastorage/zadara-xfs-pushback/commit/094df949fd080ede546bb7518405ab873a444823 > > you've changed the disk format w/o adding a feature flag, > which is pretty dangerous. > > -Eric From david@fromorbit.com Mon Sep 7 04:42:41 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 63EF97F55 for ; Mon, 7 Sep 2015 04:42:41 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 0C637AC004 for ; Mon, 7 Sep 2015 02:42:37 -0700 (PDT) X-ASG-Debug-ID: 1441618953-04bdf06dd6c86c0001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id VL6UrA5nUSR9MSyC for ; Mon, 07 Sep 2015 02:42:34 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2C/DAAJW+1VPOV8LHlegyNUaYJWg3yicA0BAQEBAQaVfoV7BAKBKk0BAQEBAQEHAQEBAUABP4RRExwjGCQ0BSUDBy2ILchrAQsgGYYTik6DH4EUBYcxjiSFCodtgU+EM4MfhROEEYRJg2yCNhyBZiwzhwECAhwHgSEBAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 07 Sep 2015 19:12:32 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZYswa-0006Uz-2R; Mon, 07 Sep 2015 19:42:32 +1000 Date: Mon, 7 Sep 2015 19:42:32 +1000 From: Dave Chinner To: torvalds@linux-foundation.org Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: [GIT PULL] xfs: updates for 4.3 Message-ID: <20150907094232.GF3902@dastard> X-ASG-Orig-Subj: [GIT PULL] xfs: updates for 4.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1441618953 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22305 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Hi Linus, Can you please pull the XFS updates from the tag below? There isn't a whole lot to this update - it's mostly bug fixes and they are spread pretty much all over XFS. There are some corruption fixes, some fixes for log recovery, some fixes that prevent unount from hanging, a lockdep annotation rework for inode locking to prevent false positives and the usual random bunch of cleanups and minor improvements. There is a merge conflict with your current tree in fs/xfs/xfs_aops.c. The merge diff in my tree is this: --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@@ -353,7 -356,8 +353,8 @@@ xfs_end_bio { xfs_ioend_t *ioend = bio->bi_private; - ioend->io_error = bio->bi_error; - if (!ioend->io_error && !test_bit(BIO_UPTODATE, &bio->bi_flags)) - ioend->io_error = error; ++ if (!ioend->io_error) ++ ioend->io_error = bio->bi_error; /* Toss bio and pass work off to an xfsdatad thread */ bio->bi_private = NULL; -Dave. The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git tags/xfs-for-linus-4.3 for you to fetch changes up to 5d54b8cdeaf4679c51a510dea3f8921992d0b064: Merge branch 'xfs-misc-fixes-for-4.3-4' into for-next (2015-09-01 10:30:11 +1000) ---------------------------------------------------------------- xfs: updates for 4.3-rc1 This update contains: o large rework of EFI/EFD lifecycle handling to fix log recovery corruption issues, crashes and unmount hangs o separate metadata UUID on disk to enable changing boot label UUID for v5 filesystems o fixes for gcc miscompilation on certain platforms and optimisation levels o remote attribute allocation and recovery corruption fixes o inode lockdep annotation rework to fix bugs with too many subclasses o directory inode locking changes to prevent lockdep false positives o a handful of minor corruption fixes o various other small cleanups and bug fixes ---------------------------------------------------------------- Brian Foster (18): xfs: close xc_cil list_empty() races with cil commit sequence xfs: validate transaction header length on log recovery xfs: disentagle EFI release from the extent count xfs: return committed status from xfs_trans_roll() xfs: fix efi/efd error handling to avoid fs shutdown hangs xfs: ensure EFD trans aborts on log recovery extent free failure xfs: use EFI refcount consistently in log recovery xfs: don't leave EFIs on AIL on mount failure xfs: icreate log item recovery and cancellation tracepoints xfs: fix broken icreate log item cancellation xfs: checksum log record ext headers based on record size xfs: clean up root inode properly on mount failure xfs: fix btree cursor error cleanups xfs: add helper to conditionally remove items from the AIL xfs: add missing bmap cancel calls in error paths xfs: relocate sparse inode mount warning xfs: swap leaf buffer into path struct atomically during path shift xfs: flush entire file on dio read/write to cached file Darrick J. Wong (2): libxfs: readahead of dir3 data blocks should use the read verifier libxfs: bad magic number should set da block buffer error Dave Chinner (20): xfs: call dax_fault on read page faults for DAX xfs: remote attribute headers contain an invalid LSN xfs: remote attributes need to be considered data xfs: xfs_bunmapi() does not need XFS_BMAPI_METADATA flag libxfs: add xfs_bit.c Merge branch 'xfs-misc-fixes-for-4.3' into for-next Merge branch 'xfs-meta-uuid' into for-next Merge branch 'xfs-efi-rework' into for-next xfs: fix sb_meta_uuid usage xfs: growfs not aware of sb_meta_uuid xfs: log recovery needs to validate against sb_meta_uuid xfs: dquots should be stamped with sb_meta_uuid xfs: clean up inode lockdep annotations xfs: stop holding ILOCK over filldir callbacks xfs: inode lockdep annotations broke non-lockdep build Merge branch 'xfs-misc-fixes-for-4.3-2' into for-next xfs: lockdep annotations throw warnings on non-debug builds xfs: fix non-debug build warnings Merge branch 'xfs-misc-fixes-for-4.3-3' into for-next Merge branch 'xfs-misc-fixes-for-4.3-4' into for-next David Jeffery (1): xfs: return errors from partial I/O failures to files Eric Sandeen (4): xfs: create new metadata UUID field and incompat flag xfs: set XFS_DA_OP_OKNOENT in xfs_attr_get xfs: collapse allocsize and biosize mount option handling xfs: fix error gotos in xfs_setattr_nonsize Jan Kara (4): xfs: Remove duplicate jumps to the same label xfs: Fix xfs_attr_leafblock definition xfs: Fix uninitialized return value in xfs_alloc_fix_freelist() xfs: Fix file type directory corruption for btree directories Joe Perches (1): xfs: Use consistent logging message prefixes Lucas Stach (1): xfs: add mssing inode cache attempts counter increment fs/dax.c | 14 ++- fs/xfs/Makefile | 2 +- fs/xfs/libxfs/xfs_alloc.c | 6 +- fs/xfs/libxfs/xfs_alloc_btree.c | 4 +- fs/xfs/libxfs/xfs_attr.c | 2 + fs/xfs/libxfs/xfs_attr_leaf.c | 4 +- fs/xfs/libxfs/xfs_attr_remote.c | 53 ++++++--- fs/xfs/{ => libxfs}/xfs_bit.c | 0 fs/xfs/libxfs/xfs_bmap.c | 1 + fs/xfs/libxfs/xfs_bmap_btree.c | 5 +- fs/xfs/libxfs/xfs_btree.c | 10 +- fs/xfs/libxfs/xfs_da_btree.c | 32 ++--- fs/xfs/libxfs/xfs_da_format.h | 11 +- fs/xfs/libxfs/xfs_dir2.c | 36 +++--- fs/xfs/libxfs/xfs_dir2_block.c | 4 +- fs/xfs/libxfs/xfs_dir2_data.c | 7 +- fs/xfs/libxfs/xfs_dir2_leaf.c | 4 +- fs/xfs/libxfs/xfs_dir2_node.c | 17 ++- fs/xfs/libxfs/xfs_dquot_buf.c | 4 +- fs/xfs/libxfs/xfs_format.h | 22 +++- fs/xfs/libxfs/xfs_ialloc.c | 7 +- fs/xfs/libxfs/xfs_ialloc_btree.c | 2 +- fs/xfs/libxfs/xfs_inode_buf.c | 4 +- fs/xfs/libxfs/xfs_sb.c | 27 +++-- fs/xfs/libxfs/xfs_symlink_remote.c | 4 +- fs/xfs/xfs_aops.c | 3 +- fs/xfs/xfs_bmap_util.c | 87 +++++++------- fs/xfs/xfs_buf.c | 9 +- fs/xfs/xfs_buf_item.c | 26 +++-- fs/xfs/xfs_buf_item.h | 2 +- fs/xfs/xfs_dir2_readdir.c | 11 +- fs/xfs/xfs_dquot.c | 10 +- fs/xfs/xfs_extfree_item.c | 105 +++++++---------- fs/xfs/xfs_extfree_item.h | 26 ++++- fs/xfs/xfs_file.c | 72 +++++++----- fs/xfs/xfs_fsops.c | 6 +- fs/xfs/xfs_icache.c | 2 + fs/xfs/xfs_inode.c | 141 +++++++++++++++------- fs/xfs/xfs_inode.h | 85 +++++++++----- fs/xfs/xfs_inode_item.c | 11 +- fs/xfs/xfs_iops.c | 8 +- fs/xfs/xfs_itable.c | 3 +- fs/xfs/xfs_log.c | 87 +++++++++----- fs/xfs/xfs_log.h | 1 + fs/xfs/xfs_log_cil.c | 8 +- fs/xfs/xfs_log_priv.h | 2 + fs/xfs/xfs_log_recover.c | 227 ++++++++++++++++++++++++++++-------- fs/xfs/xfs_mount.c | 28 +++-- fs/xfs/xfs_rtalloc.c | 57 ++++----- fs/xfs/xfs_super.c | 16 +-- fs/xfs/xfs_symlink.c | 9 +- fs/xfs/xfs_trace.h | 34 ++++++ fs/xfs/xfs_trans.c | 15 ++- fs/xfs/xfs_trans.h | 9 +- fs/xfs/xfs_trans_extfree.c | 32 +++-- fs/xfs/xfs_trans_priv.h | 15 +++ 56 files changed, 930 insertions(+), 499 deletions(-) rename fs/xfs/{ => libxfs}/xfs_bit.c (100%) -- Dave Chinner david@fromorbit.com From 509dcbf0.1dw1.1gPf.dQ.1xoEPZcFPk+xfs=oss.sgi.com@bnc3.mailjet.com Mon Sep 7 09:45:56 2015 Return-Path: <509dcbf0.1dw1.1gPf.dQ.1xoEPZcFPk+xfs=oss.sgi.com@bnc3.mailjet.com> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 15CE67CBF for ; Mon, 7 Sep 2015 09:45:56 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id E92018F8035 for ; Mon, 7 Sep 2015 07:45:55 -0700 (PDT) X-ASG-Debug-ID: 1441637152-04cbb06acbd50c0001-NocioJ Received: from o206.p8.mailjet.com (o206.p8.mailjet.com [87.253.233.206]) by cuda.sgi.com with ESMTP id Aeuihr7jtGasHZPv (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 07 Sep 2015 07:45:53 -0700 (PDT) X-Barracuda-Envelope-From: 509dcbf0.1dw1.1gPf.dQ.1xoEPZcFPk+xfs=oss.sgi.com@bnc3.mailjet.com X-Barracuda-Apparent-Source-IP: 87.253.233.206 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; q=dns/txt; d=bnc3.mailjet.com; i=indongo=3Dministryofmagicdev.com@bnc3.mailjet.com; s=mailjet; h=message-id:mime-version:from:reply-to:to:subject:date:list-id:list-unsubscribe: precedence:x-csa-complaints:content-type; bh=uce5IFvU0rPYizAxmJfOJ20wgQ0=; b= LzGMtWf2YNfyCvmVwAWbDu0AtWE+eiTxNXm5BZlglsmfqgEmF8oaoFaedRBM B5HKO1Ge95hL+4Bq/4tRbO5W3PafK9oq6/jt4qmrjDNS1RwmW1cCmUuFU8GV Qx7j1QKPOOYnmUa1Ypgys8qSglirwU7ybfS0kLqEu6Z7MV+zrMU= Message-Id: <509dcbf0.1dw1.1gPf.dQ.1xoEPZcFPk@mailjet.com> MIME-Version: 1.0 From: Indongo Reply-To: henri@ministryofmagicnam.com To: xfs@oss.sgi.com Subject: Indongo Toyota Date: Mon, 7 Sep 2015 14:45:52 +0000 X-ASG-Orig-Subj: Indongo Toyota List-Id: List-Unsubscribe: Precedence: bulk X-CSA-Complaints: whitelist-complaints@eco.de Content-Type: multipart/alternative; boundary="=-y8z6lAY8RsOviv4dRX1I" X-Barracuda-Connect: o206.p8.mailjet.com[87.253.233.206] X-Barracuda-Start-Time: 1441637153 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22310 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 --=-y8z6lAY8RsOviv4dRX1I Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Special offer from Indongo Toyota View online version [http://omi3.mjt.lu/nl2/omi3/14320.html?a=3D1xoEPZcFPk&= b=3D509dcbf0&c=3Domi3&d=3Def69449b&e=3Dbc025ff5&email=3Dxfs@oss.sgi.com][ht= tp://omi3.mjt.lu/img/omi3/b/k/x7.jpeg] Drive the Hilux of your Choice! Doub= le Cab, Single Cab or Extra Cab - pick one and SAVE! This e-mail has been sent to xfs@oss.sgi.com, click here to unsubscribe [[[= UNSUB_LINK_EN]]] .= --=-y8z6lAY8RsOviv4dRX1I Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Indongo Toyota
Special offer from Indongo Toyot= a
View online version
=
= =C2=A0
3D""
=C2=A0
=C2=A0
Drive the Hilux of your Choice!
=C2=A0
= =C2=A0
Double Cab, Single Cab or Ext= ra Cab - pick one and SAVE!
=C2=A0
<= /table>

This e-mail has been sent to xfs@oss.sg= i.com, click here to = unsubscribe.

=


3D"" = --=-y8z6lAY8RsOviv4dRX1I-- From mariaelena.garcia@mecd.es Mon Sep 7 17:05:38 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.2 required=5.0 tests=HTML_MESSAGE,MISSING_HEADERS, MPART_ALT_DIFF autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 308EB7CBF for ; Mon, 7 Sep 2015 17:05:38 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 1FA05304032 for ; Mon, 7 Sep 2015 15:05:34 -0700 (PDT) X-ASG-Debug-ID: 1441663530-04cb6c0e0ecb970001-NocioJ Received: from beta.mec.es (beta.educacion.es [193.147.0.23]) by cuda.sgi.com with ESMTP id B6kwvL5EUBMH5bvA for ; Mon, 07 Sep 2015 15:05:30 -0700 (PDT) X-Barracuda-Envelope-From: mariaelena.garcia@mecd.es X-Barracuda-Apparent-Source-IP: 193.147.0.23 Received: from x-men.mec.es (X-MEN [172.30.12.37]) by beta.mec.es (Postfix) with ESMTP id A5C96E603; Tue, 8 Sep 2015 00:01:17 +0200 (CEST) Received: from HUB-CAS-2.MCU.ES (intra-Flotante-interna.mec.es [172.30.12.1]) by x-men.mec.es (Postfix) with ESMTP id 4E3A414C00A; Tue, 8 Sep 2015 00:01:10 +0200 (CEST) Received: from CORREO-EXC.MCU.ES ([169.254.1.76]) by HUB-CAS-2.MCU.ES ([::1]) with mapi; Tue, 8 Sep 2015 00:01:16 +0200 From: CC: Date: Tue, 8 Sep 2015 00:01:15 +0200 Subject: =?koi8-r?Q?=D0=D2=CF=C5=CB=D4?= Thread-Topic: =?koi8-r?Q?=D0=D2=CF=C5=CB=D4?= X-ASG-Orig-Subj: =?koi8-r?Q?=D0=D2=CF=C5=CB=D4?= Thread-Index: AQHQ6bi3z7hQq8NAGEKm3UziX9mtHA== Message-ID: Accept-Language: es-ES, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: es-ES, en-US Content-Type: multipart/alternative; boundary="_000_BF46A0C2D1694B49871034FFB7D21B4972E69EF618CORREOEXCMCUE_" MIME-Version: 1.0 X-Barracuda-Connect: beta.educacion.es[193.147.0.23] X-Barracuda-Start-Time: 1441663530 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.57 X-Barracuda-Spam-Status: No, SCORE=1.57 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC7_SA298e, HTML_MESSAGE, MISSING_HEADERS, MPART_ALT_DIFF, NO_REAL_NAME, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22318 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.00 NO_REAL_NAME From: does not include a real name 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 1.21 MISSING_HEADERS Missing To: header 0.00 HTML_MESSAGE BODY: HTML included in message 0.14 MPART_ALT_DIFF BODY: HTML and text parts are different 0.20 BSF_SC7_SA298e Custom Rule SA298e --_000_BF46A0C2D1694B49871034FFB7D21B4972E69EF618CORREOEXCMCUE_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable =F5 =CD=C5=CE=D1 =C5=D3=D4=D8 =D0=D2=CF=C5=CB=D4 =C4=CC=D1 =D7=C1=D3... =FC= =CC=C5=CB=D4=D2=CF=CE=CE=C1=D1 =D0=CF=DE=D4=C1 ( fldelln_pigkan@outlook.com= ) =C4=CC=D1 =C2=CF=CC=C5=C5 =C9=CE=C6= =CF=D2=CD=C1=C3=C9=C9. --_000_BF46A0C2D1694B49871034FFB7D21B4972E69EF618CORREOEXCMCUE_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
=F5 =CD=C5=CE=D1 =C5=D3=D4=D8 =D0=D2=CF=C5=CB=D4 =C4=CC=D1= =D7=C1=D3... =FC=CC=C5=CB=D4=D2=CF=CE=CE=C1=D1 =D0=CF=DE=D4=C1 ( fldelln_pigkan= @outlook.com ) =C4=CC=D1 =C2=CF=CC=C5=C5 = =C9=CE=C6=CF=D2=CD=C1=C3=C9=C9.
--_000_BF46A0C2D1694B49871034FFB7D21B4972E69EF618CORREOEXCMCUE_-- From modestya05@yahoo.com Tue Sep 8 01:43:04 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=FORGED_YAHOO_RCVD, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_FONT_SIZE_HUGE,HTML_MESSAGE autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 8BF677F37 for ; Tue, 8 Sep 2015 01:43:04 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 5E544304048 for ; Mon, 7 Sep 2015 23:43:01 -0700 (PDT) X-ASG-Debug-ID: 1441694575-04bdf06dd6e21a0001-NocioJ Received: from [61.3.19.89] ([61.3.19.89]) by cuda.sgi.com with ESMTP id kIRq5Hbqb9Fjhboy for ; Mon, 07 Sep 2015 23:42:56 -0700 (PDT) X-Barracuda-Envelope-From: modestya05@yahoo.com X-Barracuda-Apparent-Source-IP: 61.3.19.89 Message-ID: <20150908120900.D2TKX9G94GR@www.yahoo.com> Content-Disposition: inline Content-Type: multipart/alternative; boundary="6826633240" X-Mailer: MyBB mailer MIME-Version: 1.0 From: =?koi8-r?B?58XOzsHEycog7cHNz87Uz9c=?= Date: Tue, 8 Sep 2015 12:09:00 +0530 To: Subject: =?koi8-r?B?98/a19LB1CDEz8zHz9cgKMvPzMzFy9TP0tPLycUg1dPM1cfJKQ==?= X-Barracuda-Connect: UNKNOWN[61.3.19.89] X-Barracuda-Start-Time: 1441694575 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-ASG-Orig-Subj: =?koi8-r?B?98/a19LB1CDEz8zHz9cgKMvPzMzFy9TP0tPLycUg1dPM1cfJKQ==?= X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 2.40 X-Barracuda-Spam-Status: No, SCORE=2.40 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_TG035a, BSF_SC5_MJ1963, FORGED_YAHOO_RCVD, FORGED_YAHOO_RCVD_2, HTML_FONT_SIZE_HUGE, HTML_MESSAGE, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22327 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers 0.39 HTML_FONT_SIZE_HUGE BODY: HTML font size is huge 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SC0_TG035a Message contains invalid style definition 1.41 FORGED_YAHOO_RCVD_2 'From' yahoo.com does not match 'Received' headers 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 --6826633240 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable =EB=F5=F0=E9=ED =F7=FA=F9=FD=E5=ED __=E4=EF=EC=E7=E9__= =E9=FA=E2=E1=F7=E9=ED =F5=ED=E5=EE=F8=FB=E9=ED =F7 =D5=D3= =CC=CF=D7=C9=D1=C8 =D2=C1=DA=D7=C9=D7=C1=C0=DD=C5=C7=CF=D3=D1 =CB=D2=C9= =DA=C9=D3=C1, =CB=CF=C7=C4=C1 =CE=C5=CF=D0=CC=C1=D4=D9 =D1=D7=CC=D1=C0=D4= =D3=D1 =CF=C2=D9=C4=C5=CE=CE=D9=CD =D1=D7=CC=C5=CE=C9=C5=CD =DC=CB=CF=CE= =CF=CD=C9=DE=C5=D3=CB=CF=CA =D6=C9=DA=CE=C9, =C2=D9=D3=D4=D2=CF =C9 = =CE=C1=C4=C5=D6=CE=CF =D2=C5=DB=C9=CD =F7=C1=DB=C9 =D0=D2=CF=C2=CC=C5=CD= =D9. =F2=C1=C2=CF=D4=C1=C5=CD =D3 =D0=D2=CF=D3=D2=CF=DE=C5=CE=CE= =D9=CD=C9 =C4=CF=CC=C7=C1=CD=C9 =C9 =D7 =D3=CC=CF=D6=CE=D9=C8 =D3=C9=D4= =D5=C1=C3=C9=D1=C8. =F7=DA=D9=D3=CB= =C1=CE=C9=D1 =C4=CF=CC=C7=CF=D7 =F5=C8=CF= =C4 =CF=D4 =C4=CF=CC=C7=CF=D7 =E4=CF=D3=D5=C4=C5=C2=CE=C1=D1 =D2=C1=C2=CF= =D4=C1 =D3 =C4=CF=CC=D6=CE=C9=CB=CF=CD =F0=D2=C5=D4=C5=CE=DA=C9= =CF=CE=CE=CF-=C9=D3=CB=CF=D7=C1=D1 =D2=C1=C2=CF=D4=C1 =D3 =C4=CF=CC=D6=CE= =C9=CB=CF=CD =F7=DA=D9=D3=CB=C1=CE=C9=C5 =C4=CF=CC=C7=CF=D7 =D7 = =D0=CF=D2=D1=C4=CB=C5 =CE=CF=D4=C1=D2=C9=C1=CC=D8=CE=D9=C8 =C4=C5=CA=D3= =D4=D7=C9=CA =F0=D2=C5=D4=C5=CE=DA=C9=CF=CE=CE=C1=D1 =D7=CE=C5=D3= =D5=C4=C5=C2=CE=C1=D1 =D2=C1=C2=CF=D4=C1 =F0=CF=C9=D3=CB =C4=CF= =CC=D6=CE=C9=CB=C1 =F0=CF=C9=D3=CB =C9=CD=D5=DD=C5=D3=D4=D7=C1 = =C4=CF=CC=D6=CE=C9=CB=C1 =F0=CF=C9=D3=CB =D3=CB=D2=D9=D4=CF=C7=CF= =C9=CD=D5=DD=C5=D3=D4=D7=C1 (=C9=CD=D5=DD=C5=D3=D4=D7=CF =D0=C5= =D2=C5=C4=C1=CE=CE=CF=C5 =D2=CF=C4=D3=D4=D7=C5=CE=CE=C9=CB=C1=CD, =C4=D2= =D5=DA=D8=D1=CD, =DA=CE=C1=CB=CF=CD=D9=CD) =F7=CF=DA=D7=D2=C1=D4 = =C4=CF=CC=C7=C1 =D0=D5=D4=C5=CD =CE=C1=CC=CF=D6=C5=CE=C9=D1 =D7=DA=D9=D3= =CB=C1=CE=C9=D1 =CE=C1 =D3=CB=D2=D9=D4=CF=C5 =C9=CD=D5=DD=C5=D3=D4=D7=CF = =F7=CF=DA=D7=D2=C1=D4 =C4=CF=CC=C7=CF=D7 =D3 =D0=D2=CF=D0=D5=DD= =C5=CE=CE=D9=CD =D3=D2=CF=CB=CF=CD =F2=C1=C2=CF=D4=C1 =D3 =D3=D5= =C4=C5=C2=CE=D9=CD=C9 =D0=D2=C9=D3=D4=C1=D7=C1=CD=C9 =C9=D3=D0=CF=CC=CE= =C9=D4=C5=CC=D1=CD=C9 =EF=D0=D4=C9=CD=C9=DA= =C1=C3=C9=D1 =C4=CF=CC=C7=CF=D7=D9=C8 =CF=C2=D1=DA=C1=D4=C5=CC=D8=D3=D4= =D7 =F3=C5=CC=C5=CB=C3=C9=D1 =C4=CF=CC=C7=CF=D7=D9=C8 =CF=C2=D1= =DA=C1=D4=C5=CC=D8=D3=D4=D7 =F7=D9=D1=D7=CC=C5=CE=C9=C5 =CF=D3=CE= =CF=D7=C1=CE=C9=CA =CF=D4=D3=D2=CF=DE=CB=C9 =C9 =D2=C1=D3=D3=D2=CF=DE=CB= =C9 =D7=D9=D0=CC=C1=D4=D9 =F0=C5=D2=C5=D3=CD=CF=D4=D2 =C2=C5=D3= =D3=D0=CF=D2=CE=D9=C8 =C4=CF=CC=C7=CF=D7=D9=C8 =CF=C2=D1=DA=C1=D4=C5=CC= =D8=D3=D4=D7 =EF=D0=D4=C9=CD=C9=DA=C1=C3=C9=D1 =C9=CD=D5=DD=C5=D3= =D4=D7=C5=CE=CE=CF=CA =C2=C1=DA=D9 =CE=C1 =CB=CF=D4=CF=D2=D5=C0 =D7=CF=DA= =CD=CF=D6=CE=CF =CE=C1=CC=CF=D6=C5=CE=C9=C5 =D7=DA=D9=D3=CB=C1=CE=C9=D1 = =F0=C5=D2=C5=D7=CF=C4 =C9=CD=D5=DD=C5=D3=D4=D7=C1 =CE=C1 =D2=CF=C4= =D3=D4=D7=C5=CE=CE=C9=CB=CF=D7 =F7=D9=CB=D5=D0 =C4=CF=CC=C7=CF=D7= =F2=C1=C2=CF=D4=C1 =D3 =D2=C5=C7=C9=CF=CE=C1=CD=C9 =F2= =C1=C2=CF=D4=C1 =D3 =D3=D5=C4=C5=C2=CE=D9=CD=C9 =D0=D2=C9=D3=D4=C1=D7=C1= =CD=C9 =C9=D3=D0=CF=CC=CE=C9=D4=C5=CC=D1=CD =ED=D9 =D5=D3=D0=C5=DB=CE=CF =D2=C1=C2=CF=D4=C1=C5=CD = =CE=C1 =D2=D9=CE=CB=C5 =C4=CF=CC=C7=CF=D7=D9=C8 =CF=C2=D1=DA=C1=D4=C5=CC= =D8=D3=D4=D7 =F4=C5=CC: 8 (915) 206 5373; 8 495 968 73 53 --6826633240 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

=EB=F5=F0=E9= =ED
=F7=FA=F9=FD=E5=ED __=E4=EF=EC=E7=E9__= =E9=FA=E2=E1=F7=E9=ED
=F5=ED=E5=EE=F8=FB=E9=ED

=F7 =D5=D3= =CC=CF=D7=C9=D1=C8 =D2=C1=DA=D7=C9=D7=C1=C0=DD=C5=C7=CF=D3=D1 =CB=D2=C9= =DA=C9=D3=C1, =CB=CF=C7=C4=C1 =CE=C5=CF=D0=CC=C1=D4=D9 =D1=D7=CC=D1=C0=D4= =D3=D1 =CF=C2=D9=C4=C5=CE=CE=D9=CD =D1=D7=CC=C5=CE=C9=C5=CD =DC=CB=CF=CE= =CF=CD=C9=DE=C5=D3=CB=CF=CA =D6=C9=DA=CE=C9,
=C2=D9=D3=D4=D2=CF =C9 =CE=C1=C4=C5=D6=CE=CF =D2=C5=DB=C9=CD =F7=C1= =DB=C9 =D0=D2=CF=C2=CC=C5=CD=D9.

=F2=C1=C2=CF=D4=C1=C5=CD =D3 =D0=D2=CF=D3=D2=CF=DE=C5=CE=CE=D9=CD= =C9 =C4=CF=CC=C7=C1=CD=C9 =C9 =D7 =D3=CC=CF=D6=CE=D9=C8 =D3=C9=D4=D5=C1= =C3=C9=D1=C8.

= =F7=DA=D9=D3=CB=C1=CE=C9=D1 =C4=CF=CC=C7=CF=D7
=F5=C8=CF=C4 =CF=D4 =C4=CF=CC=C7=CF=D7<= /div>
=E4=CF=D3=D5=C4=C5=C2=CE=C1=D1 =D2=C1=C2=CF=D4=C1 =D3 =C4=CF=CC=D6=CE= =C9=CB=CF=CD
=F0=D2=C5=D4=C5=CE=DA=C9=CF=CE=CE=CF-=C9=D3=CB=CF=D7=C1=D1 =D2= =C1=C2=CF=D4=C1 =D3 =C4=CF=CC=D6=CE=C9=CB=CF=CD
=F7=DA=D9=D3=CB=C1=CE=C9=C5 =C4=CF=CC=C7=CF=D7 =D7 =D0=CF=D2=D1= =C4=CB=C5 =CE=CF=D4=C1=D2=C9=C1=CC=D8=CE=D9=C8 =C4=C5=CA=D3=D4=D7=C9=CA =F0=D2=C5=D4=C5=CE=DA=C9=CF=CE=CE=C1=D1 =D7=CE=C5=D3=D5=C4=C5=C2= =CE=C1=D1 =D2=C1=C2=CF=D4=C1
=F0=CF=C9=D3=CB =C4=CF=CC=D6=CE=C9=CB=C1
=F0=CF=C9=D3=CB =C9=CD=D5=DD=C5=D3=D4=D7=C1 =C4=CF=CC=D6=CE=C9= =CB=C1
=F0=CF=C9=D3=CB =D3=CB=D2=D9=D4=CF=C7=CF =C9=CD=D5=DD=C5=D3=D4= =D7=C1
(=C9=CD=D5=DD=C5=D3=D4=D7=CF =D0=C5=D2=C5=C4=C1=CE=CE=CF=C5 =D2= =CF=C4=D3=D4=D7=C5=CE=CE=C9=CB=C1=CD, =C4=D2=D5=DA=D8=D1=CD, =DA=CE=C1=CB= =CF=CD=D9=CD)
=F7=CF=DA=D7=D2=C1=D4 =C4=CF=CC=C7=C1 =D0=D5=D4=C5=CD =CE=C1=CC= =CF=D6=C5=CE=C9=D1 =D7=DA=D9=D3=CB=C1=CE=C9=D1 =CE=C1 =D3=CB=D2=D9=D4=CF= =C5 =C9=CD=D5=DD=C5=D3=D4=D7=CF
=F7=CF=DA=D7=D2=C1=D4 =C4=CF=CC=C7=CF=D7 =D3 =D0=D2=CF=D0=D5=DD= =C5=CE=CE=D9=CD =D3=D2=CF=CB=CF=CD
=F2=C1=C2=CF=D4=C1 =D3 =D3=D5=C4=C5=C2=CE=D9=CD=C9 =D0=D2=C9=D3= =D4=C1=D7=C1=CD=C9 =C9=D3=D0=CF=CC=CE=C9=D4=C5=CC=D1=CD=C9
=EF=D0=D4=C9=CD=C9=DA=C1=C3=C9=D1 =C4=CF=CC=C7=CF=D7=D9=C8 =CF= =C2=D1=DA=C1=D4=C5=CC=D8=D3=D4=D7
=F3=C5=CC=C5=CB=C3=C9=D1 =C4=CF=CC=C7=CF=D7=D9=C8 =CF=C2=D1=DA= =C1=D4=C5=CC=D8=D3=D4=D7
=F7=D9=D1=D7=CC=C5=CE=C9=C5 =CF=D3=CE=CF=D7=C1=CE=C9=CA =CF=D4= =D3=D2=CF=DE=CB=C9 =C9 =D2=C1=D3=D3=D2=CF=DE=CB=C9 =D7=D9=D0=CC=C1=D4=D9<= br /> =F0=C5=D2=C5=D3=CD=CF=D4=D2 =C2=C5=D3=D3=D0=CF=D2=CE=D9=C8 =C4= =CF=CC=C7=CF=D7=D9=C8 =CF=C2=D1=DA=C1=D4=C5=CC=D8=D3=D4=D7
=EF=D0=D4=C9=CD=C9=DA=C1=C3=C9=D1 =C9=CD=D5=DD=C5=D3=D4=D7=C5=CE= =CE=CF=CA =C2=C1=DA=D9 =CE=C1 =CB=CF=D4=CF=D2=D5=C0 =D7=CF=DA=CD=CF=D6=CE= =CF =CE=C1=CC=CF=D6=C5=CE=C9=C5 =D7=DA=D9=D3=CB=C1=CE=C9=D1
=F0=C5=D2=C5=D7=CF=C4 =C9=CD=D5=DD=C5=D3=D4=D7=C1 =CE=C1 =D2=CF= =C4=D3=D4=D7=C5=CE=CE=C9=CB=CF=D7
=F7=D9=CB=D5=D0 =C4=CF=CC=C7=CF=D7
=F2=C1=C2=CF=D4=C1 =D3 =D2=C5=C7=C9=CF=CE=C1=CD=C9
=F2=C1=C2=CF=D4=C1 =D3 =D3=D5=C4=C5=C2=CE=D9=CD=C9 =D0=D2=C9=D3= =D4=C1=D7=C1=CD=C9 =C9=D3=D0=CF=CC=CE=C9=D4=C5=CC=D1=CD

=ED=D9 =D5= =D3=D0=C5=DB=CE=CF =D2=C1=C2=CF=D4=C1=C5=CD =CE=C1 =D2=D9=CE=CB=C5 =C4=CF= =CC=C7=CF=D7=D9=C8 =CF=C2=D1=DA=C1=D4=C5=CC=D8=D3=D4=D7
=F4=C5=CC: <= strong>8 (915) 206 5373; = 8 495 968 73 53
--6826633240-- From bfoster@redhat.com Tue Sep 8 07:47:34 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id D42677F37 for ; Tue, 8 Sep 2015 07:47:33 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 6FAEFAC003 for ; Tue, 8 Sep 2015 05:47:30 -0700 (PDT) X-ASG-Debug-ID: 1441716448-04bdf06dd6ea400001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id rFzFb6Sl0Rtbt42Q (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 08 Sep 2015 05:47:28 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 4D2F8461C3; Tue, 8 Sep 2015 12:47:28 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-237.bos.redhat.com [10.18.41.237]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88ClREF000456; Tue, 8 Sep 2015 08:47:28 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id EA39E123FB0; Tue, 8 Sep 2015 08:47:26 -0400 (EDT) Date: Tue, 8 Sep 2015 08:47:26 -0400 From: Brian Foster To: Rich Johnston Cc: xfs@oss.sgi.com Subject: Re: [PATCH V3] xfsrestore: fix fs uuid order check for incremental restores Message-ID: <20150908124726.GA5305@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH V3] xfsrestore: fix fs uuid order check for incremental restores References: <20150826213133.GB3902@dastard> <55D5FB95.1280108@sgi.com> <20150902132112.GB23587@bfoster.bfoster> <20150903234346.2473A600006AF@gulag1.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150903234346.2473A600006AF@gulag1.americas.sgi.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441716448 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 03, 2015 at 06:43:46PM -0500, Rich Johnston wrote: > Restoring an incremental level 1 dump will fail with the following error > if the fs uuid of the most recent level 0 dump in the inventory does not > match level 1 dump we are restoring. > > xfsrestore: ERROR: selected dump not based on previously applied dump > > This can happen when you have multiple filesystems and you are restoring > a level 1 or greater dump of filesystem FS1 but the most recent level 0 > dump in the inventory was filesystem FS2 > > The fix is to ensure the fs uuid of the inventory entry and the dump to > be restored match. > > Signed-off-by: Rich Johnston > --- > > Changelog > V2 wrong file sent > > V3 > Address review comments from Brian: > > fix invmgr_query_all_sessions() returning true if these error cases > persist throughout the loop > > make if check more readable and less overloaded in search_inv() and > return an error if GET_REC_NOLOCK() fails > > use NULL instead of (uuid_t *)0 in Inv_validate_cmdline() > > remove any spaces around braces of code that was changed > > dump/content.c | 16 +++--- > inventory/inv_api.c | 130 +++++++++++++++++++++++++++++--------------------- > inventory/inv_mgr.c | 55 ++++++++++++++------- > inventory/inv_priv.h | 7 +- > inventory/inventory.h | 21 +++++--- > restore/content.c | 23 +++++--- > 6 files changed, 152 insertions(+), 100 deletions(-) > > Index: b/dump/content.c > =================================================================== > --- a/dump/content.c > +++ b/dump/content.c > @@ -872,7 +872,7 @@ content_init( intgen_t argc, > sameinterruptedpr = BOOL_FALSE; > interruptedpr = BOOL_FALSE; > > - ok = inv_get_session_byuuid( &baseuuid, &sessp ); > + ok = inv_get_session_byuuid(&fsid, &baseuuid, &sessp); > if ( ! ok ) { > mlog( MLOG_NORMAL | MLOG_ERROR, _( > "could not find specified base dump (%s) " > @@ -983,9 +983,10 @@ content_init( intgen_t argc, > "online inventory not available\n") ); > return BOOL_FALSE; > } > - ok = inv_lastsession_level_lessthan( inv_idbt, > - ( u_char_t )sc_level, > - &sessp ); > + ok = inv_lastsession_level_lessthan(&fsid, > + inv_idbt, > + (u_char_t)sc_level, > + &sessp); > if ( ! ok ) { > sessp = 0; > } > @@ -1022,9 +1023,10 @@ content_init( intgen_t argc, > if ( inv_idbt != INV_TOKEN_NULL ) { > /* REFERENCED */ > bool_t ok1; > - ok = inv_lastsession_level_equalto( inv_idbt, > - ( u_char_t )sc_level, > - &sessp ); > + ok = inv_lastsession_level_equalto(&fsid, > + inv_idbt, > + (u_char_t)sc_level, > + &sessp); > ok1 = inv_close( inv_idbt ); > ASSERT( ok1 ); > if ( ! ok ) { > Index: b/inventory/inv_api.c > =================================================================== > --- a/inventory/inv_api.c > +++ b/inventory/inv_api.c > @@ -596,69 +596,78 @@ inv_free_session( > > > /*----------------------------------------------------------------------*/ > -/* inventory_lasttime_level_lessthan */ > -/* */ > -/* Given a token that refers to a file system, and a level, this returns*/ > -/* the last time when a session of a lesser level was done. */ > -/* */ > -/* returns -1 on error. */ > +/* inv_lasttime_level_lessthan */ > +/* */ > +/* Given a file system uuid, token that refers to a file system, and a */ > +/* level, tm is populated with last time when a session of a lesser */ > +/* level was done. */ > +/* */ > +/* Returns TRUE on success. */ > /*----------------------------------------------------------------------*/ > > bool_t > inv_lasttime_level_lessthan( > - inv_idbtoken_t tok, > - u_char level, > - time32_t **tm ) > + uuid_t *fsidp, > + inv_idbtoken_t tok, > + u_char level, > + time32_t **tm) > { > int rval; > if ( tok != INV_TOKEN_NULL ) { > - rval = search_invt( tok->d_invindex_fd, &level, (void **) tm, > - (search_callback_t) tm_level_lessthan ); > + rval = search_invt(fsidp, tok->d_invindex_fd, &level, > + (void **)tm, > + (search_callback_t)tm_level_lessthan); > > return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; > } > > - return invmgr_query_all_sessions((void *) &level, /* in */ > - (void **) tm, /* out */ > - (search_callback_t) tm_level_lessthan); > + return invmgr_query_all_sessions(fsidp, /* fs uuid ptr */ > + (void *)&level, /* in */ > + (void **)tm, /* out */ > + (search_callback_t)tm_level_lessthan); > } > > - > - > - > - > /*----------------------------------------------------------------------*/ > -/* */ > -/* */ > -/* */ > +/* inv_lastsession_level_lessthan */ > +/* */ > +/* Given a file system uuid, token that refers to a file system, and a */ > +/* level, ses is populated with a session of lesser than the level */ > +/* passed in. */ > +/* */ > +/* Returns FALSE on an error, TRUE if not. If (*ses) is NULL, then the */ > +/* search failed. */ > /*----------------------------------------------------------------------*/ > > bool_t > inv_lastsession_level_lessthan( > - inv_idbtoken_t tok, > + uuid_t *fsidp, > + inv_idbtoken_t tok, > u_char level, > - inv_session_t **ses ) > + inv_session_t **ses) > { > int rval; > if ( tok != INV_TOKEN_NULL ) { > - rval = search_invt( tok->d_invindex_fd, &level, (void **) ses, > - (search_callback_t) lastsess_level_lessthan ); > + rval = search_invt(fsidp, tok->d_invindex_fd, &level, > + (void **)ses, > + (search_callback_t)lastsess_level_lessthan); > > return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; > } > > - return invmgr_query_all_sessions((void *) &level, /* in */ > - (void **) ses, /* out */ > - (search_callback_t) lastsess_level_lessthan); > + return invmgr_query_all_sessions(fsidp /* fs uuid */ This doesn't compile because of a missing comma after fsidp above. > + (void *)&level, /* in */ > + (void **)ses, /* out */ > + (search_callback_t)lastsess_level_lessthan); > > } > > - > - > - > /*----------------------------------------------------------------------*/ > -/* */ > -/* */ > +/* inv_lastsession_level_equalto */ > +/* */ > +/* Given a file system uuid, token that refers to a file system, and a */ > +/* level, this populates ses with last time when a session of a lesser */ > +/* level was done. */ > +/* */ > /* Return FALSE on an error, TRUE if not. If (*ses) is NULL, then the */ > /* search failed. */ > /*----------------------------------------------------------------------*/ > @@ -666,21 +675,24 @@ inv_lastsession_level_lessthan( > > bool_t > inv_lastsession_level_equalto( > - inv_idbtoken_t tok, > + uuid_t *fsidp, > + inv_idbtoken_t tok, > u_char level, > inv_session_t **ses ) > { > int rval; > if ( tok != INV_TOKEN_NULL ) { > - rval = search_invt( tok->d_invindex_fd, &level, (void **) ses, > - (search_callback_t) lastsess_level_equalto ); > + rval = search_invt(fsidp, tok->d_invindex_fd, &level, > + (void **)ses, > + (search_callback_t)lastsess_level_equalto); > > return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; > } > > - return invmgr_query_all_sessions((void *) &level, /* in */ > - (void **) ses, /* out */ > - (search_callback_t) lastsess_level_equalto); > + return invmgr_query_all_sessions(fsidp, /* fs uuid */ > + (void *)&level, /* in */ > + (void **)ses, /* out */ > + (search_callback_t)lastsess_level_equalto); > > } > > @@ -688,35 +700,45 @@ inv_lastsession_level_equalto( > /*----------------------------------------------------------------------*/ > /* inv_getsession_byuuid */ > /* */ > +/* Given a file system uuid and a session uuid , ses is populated with */ > +/* the session that contains the matching system uuid. */ > +/* */ > +/* Returns FALSE on an error, TRUE if the session was found. */ > /*----------------------------------------------------------------------*/ > > bool_t > inv_get_session_byuuid( > - uuid_t *sesid, > - inv_session_t **ses) > + uuid_t *fsidp, > + uuid_t *sesid, > + inv_session_t **ses) > { > > - return (invmgr_query_all_sessions((void *)sesid, /* in */ > - (void **) ses, /* out */ > - (search_callback_t) stobj_getsession_byuuid)); > + return invmgr_query_all_sessions(fsidp, /* fs uuid */ > + (void *)sesid, /* in */ > + (void **)ses, /* out */ > + (search_callback_t)stobj_getsession_byuuid); > } > > - > - > /*----------------------------------------------------------------------*/ > -/* inv_getsession_byuuid */ > +/* inv_getsession_bylabel */ > /* */ > +/* Given a file system uuid and a session uuid, ses is populated with */ > +/* the session that contains the matching system label. */ > +/* */ > +/* Returns FALSE on an error, TRUE if the session was found. */ > /*----------------------------------------------------------------------*/ > > bool_t > inv_get_session_bylabel( > - char *session_label, > - inv_session_t **ses) > + uuid_t *fsidp, > + char *session_label, > + inv_session_t **ses) > { > > - return (invmgr_query_all_sessions((void *)session_label, /* in */ > - (void **) ses, /* out */ > - (search_callback_t) stobj_getsession_bylabel)); > + return invmgr_query_all_sessions(fsidp, /* fs uuid */ > + (void *)session_label, /* in */ > + (void **)ses, /* out */ > + (search_callback_t)stobj_getsession_bylabel); > } > > > @@ -786,8 +808,8 @@ inv_delete_mediaobj( uuid_t *moid ) > return BOOL_FALSE; > } > > - if ( search_invt( invfd, NULL, (void **)&moid, > - (search_callback_t) stobj_delete_mobj ) > + if (search_invt(&arr[i].ft_uuid, invfd, NULL, (void **)&moid, > + (search_callback_t)stobj_delete_mobj) > < 0 ) > return BOOL_FALSE; > /* we have to delete the session, etc */ > Index: b/inventory/inv_mgr.c > =================================================================== > --- a/inventory/inv_mgr.c > +++ b/inventory/inv_mgr.c > @@ -134,8 +134,9 @@ get_sesstoken( inv_idbtoken_t tok ) > /*---------------------------------------------------------------------------*/ > bool_t > invmgr_query_all_sessions ( > - void *inarg, > - void **outarg, > + uuid_t *fsidp, > + void *inarg, > + void **outarg, > search_callback_t func) > { > invt_counter_t *cnt; > @@ -145,6 +146,7 @@ invmgr_query_all_sessions ( > int result; > inv_oflag_t forwhat = INV_SEARCH_ONLY; > void *objectfound; > + bool_t ret = BOOL_FALSE; > > /* if on return, this is still null, the search failed */ > *outarg = NULL; > @@ -157,7 +159,7 @@ invmgr_query_all_sessions ( > } > if ( fd < 0 || numfs <= 0 ) { > mlog( MLOG_NORMAL | MLOG_INV, _("INV: Error in fstab\n") ); > - return BOOL_FALSE; > + return ret; > } > > close( fd ); > @@ -169,7 +171,7 @@ invmgr_query_all_sessions ( > mlog( MLOG_NORMAL | MLOG_INV, _( > "INV: Cant get inv-name for uuid\n") > ); > - return BOOL_FALSE; > + continue; > } > strcat( fname, INV_INVINDEX_PREFIX ); > invfd = open( fname, INV_OFLAG(forwhat) ); > @@ -178,26 +180,27 @@ invmgr_query_all_sessions ( > "INV: Open failed on %s\n"), > fname > ); > - return BOOL_FALSE; > + continue; > } > - result = search_invt( invfd, inarg, &objectfound, func ); > + result = search_invt(fsidp, invfd, inarg, &objectfound, func); > close(invfd); > > /* if error return BOOL_FALSE */ > if (result < 0) { > - return BOOL_FALSE; > + return ret; Should this always return false? It's now possible to return true if an error occurs after we've found one object. The rest seems Ok to me. Brian > } else if ((result == 1) && *outarg) { > /* multiple entries found, more info needed */ > *outarg = NULL; > return BOOL_TRUE; > } else if (result == 1) { > *outarg = objectfound; > + ret = BOOL_TRUE; > } > } > > /* return val indicates if there was an error or not. *buf > says whether the search was successful */ > - return BOOL_TRUE; > + return ret; > } > > > @@ -213,10 +216,11 @@ invmgr_query_all_sessions ( > > intgen_t > search_invt( > - int invfd, > - void *arg, > - void **buf, > - search_callback_t do_chkcriteria ) > + uuid_t *fsidp, > + int invfd, > + void *arg, > + void **buf, > + search_callback_t do_chkcriteria) > { > > int fd, i; > @@ -247,7 +251,7 @@ search_invt( > /* we need to get all the invindex headers and seshdrs in reverse > order */ > for (i = nindices - 1; i >= 0; i--) { > - int nsess; > + int nsess, j; > invt_sescounter_t *scnt = NULL; > invt_seshdr_t *harr = NULL; > bool_t found; > @@ -272,19 +276,34 @@ search_invt( > } > free ( scnt ); > > - while ( nsess ) { > + for (j = nsess - 1; j >= 0; j--) { > + invt_session_t ses; > + > /* fd is kept locked until we return from the > callback routine */ > > /* Check to see if this session has been pruned > * by xfsinvutil before checking it. > */ > - if ( harr[nsess - 1].sh_pruned ) { > - --nsess; > + if (harr[j].sh_pruned) { > continue; > } > - found = (* do_chkcriteria ) ( fd, &harr[ --nsess ], > - arg, buf ); > + > + /* if we need to check the fs uuid's and they don't > + * match or we fail to get the session record, > + * then keep looking > + */ > + if (fsidp) { > + int ret = GET_REC_NOLOCK(fd, &ses, > + sizeof(invt_session_t), > + harr[j].sh_sess_off); > + if (ret < 0) > + return ret; > + if (uuid_compare(ses.s_fsid, *fsidp)) > + continue; > + } > + > + found = (* do_chkcriteria)(fd, &harr[j], arg, buf); > if (! found ) continue; > > /* we found what we need; just return */ > Index: b/inventory/inv_priv.h > =================================================================== > --- a/inventory/inv_priv.h > +++ b/inventory/inv_priv.h > @@ -548,11 +548,12 @@ get_headerinfo( int fd, void **hdrs, voi > size_t hdrsz, size_t cntsz, bool_t doblock ); > > bool_t > -invmgr_query_all_sessions (void *inarg, void **outarg, search_callback_t func); > +invmgr_query_all_sessions(uuid_t *fsidp, void *inarg, void **outarg, > + search_callback_t func); > > intgen_t > -search_invt( int invfd, void *arg, void **buf, > - search_callback_t do_chkcriteria ); > +search_invt(uuid_t *fsidp, int invfd, void *arg, void **buf, > + search_callback_t do_chkcriteria); > intgen_t > invmgr_inv_print( int invfd, invt_pr_ctx_t *prctx); > > Index: b/inventory/inventory.h > =================================================================== > --- a/inventory/inventory.h > +++ b/inventory/inventory.h > @@ -247,32 +247,37 @@ inv_put_mediafile( > */ > extern bool_t > inv_lasttime_level_lessthan( > + uuid_t *fsidp, > inv_idbtoken_t tok, > - u_char level, > - time32_t **time );/* out */ > + u_char level, > + time32_t **time); /* out */ > > extern bool_t > inv_lastsession_level_lessthan( > + uuid_t *fsidp, > inv_idbtoken_t tok, > u_char level, > - inv_session_t **ses );/* out */ > + inv_session_t **ses); /* out */ > > extern bool_t > inv_lastsession_level_equalto( > + uuid_t *fsidp, > inv_idbtoken_t tok, > u_char level, > - inv_session_t **ses );/* out */ > + inv_session_t **ses); /* out */ > > /* Given a uuid of a session, return the session structure.*/ > extern bool_t > inv_get_session_byuuid( > - uuid_t *sesid, > - inv_session_t **ses); > + uuid_t *fsidp, > + uuid_t *sesid, > + inv_session_t **ses); > > extern bool_t > inv_get_session_bylabel( > - char *session_label, > - inv_session_t **ses); > + uuid_t *fsidp, > + char *session_label, > + inv_session_t **ses); > > > /* on return, *ses is NULL */ > Index: b/restore/content.c > =================================================================== > --- a/restore/content.c > +++ b/restore/content.c > @@ -2179,8 +2179,9 @@ content_stream_restore( ix_t thrdix ) > if ( ! drivep->d_isnamedpipepr > && > ! drivep->d_isunnamedpipepr ) { > - ok = inv_get_session_byuuid( &grhdrp->gh_dumpid, > - &sessp ); > + ok = inv_get_session_byuuid(NULL, > + &grhdrp->gh_dumpid, > + &sessp); > if ( ok && sessp ) { > mlog( MLOG_VERBOSE, _( > "using online session inventory\n") ); > @@ -3736,9 +3737,9 @@ Inv_validate_cmdline( void ) > ok = BOOL_FALSE; > sessp = 0; > if ( tranp->t_reqdumpidvalpr ) { > - ok = inv_get_session_byuuid( &tranp->t_reqdumpid, &sessp ); > + ok = inv_get_session_byuuid(NULL, &tranp->t_reqdumpid, &sessp); > } else if ( tranp->t_reqdumplabvalpr ) { > - ok = inv_get_session_bylabel( tranp->t_reqdumplab, &sessp ); > + ok = inv_get_session_bylabel(NULL, tranp->t_reqdumplab, &sessp); > } > rok = BOOL_FALSE; > if ( ok && sessp ) { > @@ -6812,13 +6813,15 @@ askinvforbaseof( uuid_t baseid, inv_sess > /* get the base session > */ > if ( resumedpr ) { > - ok = inv_lastsession_level_equalto( invtok, > - ( u_char_t )level, > - &basesessp ); > + ok = inv_lastsession_level_equalto(&sessp->s_fsid, > + invtok, > + (u_char_t)level, > + &basesessp); > } else { > - ok = inv_lastsession_level_lessthan( invtok, > - ( u_char_t )level, > - &basesessp ); > + ok = inv_lastsession_level_lessthan(&sessp->s_fsid, > + invtok, > + (u_char_t)level, > + &basesessp); > } > if ( ! ok ) { > mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_MEDIA, _( > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From Aaliyah@avellacrew.com Tue Sep 8 08:15:56 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=5.0 tests=DEAR_SOMETHING,HTML_MESSAGE autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 5CBFC7F37 for ; Tue, 8 Sep 2015 08:15:56 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id DC2E5AC003 for ; Tue, 8 Sep 2015 06:15:52 -0700 (PDT) X-ASG-Debug-ID: 1441718151-04cbb06accf2790001-NocioJ Received: from smtp.mydomain.com ([198.100.31.161]) by cuda.sgi.com with ESMTP id 8VnFgLpxHjv8PTR4 for ; Tue, 08 Sep 2015 06:15:51 -0700 (PDT) X-Barracuda-Envelope-From: Aaliyah@avellacrew.com X-Barracuda-Apparent-Source-IP: 198.100.31.161 Received: from ratikala (triband-mum-120.60.35.72.mtnl.net.in [120.60.35.72]) by smtp.mydomain.com (Postfix) with ESMTP id 72EF32E5A5D for ; Tue, 8 Sep 2015 18:45:50 +0530 (IST) Message-ID: <411-22015928131924921@ratikala> Return-Receipt-To: Aaliyah@avellacrew.com Disposition-Notification-To: Aaliyah@avellacrew.com From: "Aaliyah" To: xfs@oss.sgi.com Subject: Following Up ! Date: Tue, 8 Sep 2015 18:49:25 +0500 X-ASG-Orig-Subj: Following Up ! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_84815C5ABAF209EF376268C8" X-Barracuda-Connect: UNKNOWN[198.100.31.161] X-Barracuda-Start-Time: 1441718151 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC5_MJ1963, HTML_MESSAGE, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22333 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 ------=_NextPart_84815C5ABAF209EF376268C8 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear Business Leader, Email marketing has proven to produce magical results=2E You can use web-based email marketing software to BOOST your business=2E We will setup on your domain=2E No customization=2E Your Key Benefits:- 1) Free Trial: Start sending email newsletter and email messages to your c= ontacts in just 30 minutes=20=0D without any risk with 2000 emails per day=2EYou get free trial to try the = software and check the=20=0D features=2E 2) Advanced Tracking: You can track the delivery status and click-through = rates of EACH email=20=0D message=2E 3) Keep In Touch: Keep in touch with clients by sending targeted newslette= r and company news=2E 5) Low-Rates: After your free trial, if you are happy with the service, yo= u can start using the=20=0D system=2E Start your FREE trial NOW by responding to this email=2E Email Marketing is the BEST decision you can take for your business=2E Regards, Rati singh=2E ------=_NextPart_84815C5ABAF209EF376268C8 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Dear Sir/Madam,
 
Hurry!!! We are providing various web an= d=20 marketing solutions at very competitive prices=2E
 
Please let me know if you are interested in any = of below=20 services:
 
a) Google apps - Corporate email solutions
b) Mobile website design and SEO
c) Responsive website design and SEO
d) Internet Marketing - Listing website at bette= r=20 position in Google Yahoo and Bing with power of social media like Youtube,= =20 Twitter and Facebook=2E
e) Domain name registration and web hosting
 
There are many other services from which your bu= siness=20 can explore further=2E
 
Send us an email and contact details tod= ay with=20 your Website Name=2E
 
Regards
Aaliyah=2E
=
8652522293
Direct Line= :=20 91-22-28859041
------=_NextPart_84815C5ABAF209EF376268C8-- From vski@kayd.com Tue Sep 8 08:44:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A85CB7F37 for ; Tue, 8 Sep 2015 08:44:40 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 3BF39AC005 for ; Tue, 8 Sep 2015 06:44:39 -0700 (PDT) X-ASG-Debug-ID: 1441719875-04cb6c0e0dde510001-NocioJ Received: from kayd.com (3.82.73.124.broad.dynamic.hf.ah.cndata.com [124.73.82.3]) by cuda.sgi.com with ESMTP id LN5R2bXe4XJqyKhK for ; Tue, 08 Sep 2015 06:44:36 -0700 (PDT) X-Barracuda-Envelope-From: vski@kayd.com X-Barracuda-Apparent-Source-IP: 124.73.82.3 Received: from SKY-20150201SFT ([127.0.0.1]) by localhost via TCP with ESMTPA; Tue, 08 Sep 2015 21:44:22 +0800 MIME-Version: 1.0 From: "Hao Kang" Sender: "Hao Kang" To: xfs@oss.sgi.com Reply-To: "Hao Kang" Date: 8 Sep 2015 21:44:22 +0800 Subject: =?utf-8?B?dmFsdmUgYW5kIHZhbHZlIGFjdWF0b3IvIHBuZXVtYXRpYyBhY3R1YXRvciBhbmQgZWxlY3Ryby10eWRyYXVsaWMgYWN0dWF0b3I=?= Content-Type: text/html; charset=utf-8 X-ASG-Orig-Subj: =?utf-8?B?dmFsdmUgYW5kIHZhbHZlIGFjdWF0b3IvIHBuZXVtYXRpYyBhY3R1YXRvciBhbmQgZWxlY3Ryby10eWRyYXVsaWMgYWN0dWF0b3I=?= Content-Transfer-Encoding: base64 X-Barracuda-Connect: 3.82.73.124.broad.dynamic.hf.ah.cndata.com[124.73.82.3] X-Barracuda-Start-Time: 1441719876 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.74 X-Barracuda-Spam-Status: No, SCORE=0.74 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC5_MJ1963, HTML_MESSAGE, MIME_HTML_ONLY, MISSING_MID, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22334 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 MISSING_MID Missing Message-Id: header 0.00 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 Message-Id: <20150908134439.AC3A012961A2@cuda.sgi.com> PGh0bWw+PGJvZHk+PFA+SGVsbG8sPC9QPg0KPFA+V2UgYXJlIGEgbWFudWZhY3R1cmVyIG9m IHNjb3RjaCB5b2tlIHBuZXVtYXRpYyBhY3R1YXRvcnMgKFNJTDMgY2xhc3NpZmljYXRpb24s IE1heGltdW0gdG9ycXVlOiA0MCwwMDBOTSksIHNwcmluZyByZXR1cm4gZWxlY3Ryby1oeWRy YXVsaWMgYWN0dWF0b3IoMyBzZWNvbmRzIHNodXQgb2ZmKSwgYmFsbCB2YWx2ZXMsIGFuZCB0 cmlwbGUgb2Zmc2V0IGJ1dHRlcmZseSB2YWx2ZXMgKExlYWthZ2UgcmF0ZTogQU5TSSBWSSku PC9QPg0KPFA+V2UgaGF2ZSBiZWVuIHNvbHZpbmcgZmllbGQgcHJvYmxlbXMgZm9yIG51bWVy b3VzIGNvbXBhbmllcyBlc3BlY2lhbGx5IGluIHRoZSBPaWwgUHJvY2Vzc2luZyBhbmQgR2Fz IGluZHVzdHJ5LCBzdWNoIGFzIFVPUCBEZWh5ZHJvZ2VuYXRpb24gUHJvamVjdHMsIFBESC9C REgsIElzb2J1dGVuZSBEZWh5ZHJvZ2VuYXRpb24sIFBTQSB1bml0LCBDaGxvcmluZS1BbGth bGkgaW5kdXN0cnkgYW5kIHNvIG9uLjwvUD4NCjxQPkxpbmRlciwgQkFTRiwgQWlyIExpcXVp ZCwgU0lOT1BFQyBoYXZlIHdpZGVseSB1c2VkIG91ciBwcm9kdWN0cy48L1A+DQo8UD5Zb3Ug YXJlIGFsd2F5cyB3ZWxjb21lIHRvIHZpc2l0IG91ciBmYWN0b3J5IHRvIGtub3cgb3VyIGNh cGFiaWxpdGllcyBhbmQgc2VydmljZXMuIFdlIGxvb2sgZm9yd2FyZCB0byB3b3JraW5nIHdp dGggeW91IGFuZCBJIHdpbGwgd2FpdCBmb3IgeW91ciByZXBseS4gVGhhbmtzLjwvUD4NCjxQ PkJlc3QgcmVnYXJkcyw8L1A+DQo8UD5IYW8gS2FuZzxCUj48L1A+PC9ib2R5PjwvaHRtbD4= From jtulak@redhat.com Tue Sep 8 09:23:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 2334A7F37 for ; Tue, 8 Sep 2015 09:23:43 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 10BF28F8050 for ; Tue, 8 Sep 2015 07:23:43 -0700 (PDT) X-ASG-Debug-ID: 1441722221-04cb6c18c800170001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id wBpJHigMxvGZ8LaS (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 07:23:41 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id F059DA2C12; Tue, 8 Sep 2015 14:23:40 +0000 (UTC) Received: from localhost.localdomain (vpn1-5-113.ams2.redhat.com [10.36.5.113]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88ENdIB028516; Tue, 8 Sep 2015 10:23:39 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: hch@infradead.org, Jan Tulak Subject: [PATCH 10/11 v2] xfsprogs: make fsr use mntinfo when there is no mntent Date: Tue, 8 Sep 2015 16:23:27 +0200 X-ASG-Orig-Subj: [PATCH 10/11 v2] xfsprogs: make fsr use mntinfo when there is no mntent Message-Id: <1441722207-9141-1-git-send-email-jtulak@redhat.com> In-Reply-To: <1440590555-20463-10-git-send-email-jtulak@redhat.com> References: <1440590555-20463-10-git-send-email-jtulak@redhat.com> 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: 1441722221 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 For what fsr needs, mntinfo can be used instead of mntent. Custom mntent struct is used to avoid too big ifdefs: We only change few lines and the rest of the code can still use mntent as before. CHANGE - subject was: "add dummy mntent for OS X" - reduced the stuby code. Signed-off-by: Jan Tulak --- fsr/Makefile | 8 +++++++ fsr/xfs_fsr.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++-------- include/darwin.h | 20 ++++++++++++++++ 3 files changed, 87 insertions(+), 10 deletions(-) diff --git a/fsr/Makefile b/fsr/Makefile index a9d1bf6..d3521b2 100644 --- a/fsr/Makefile +++ b/fsr/Makefile @@ -9,6 +9,14 @@ LTCOMMAND = xfs_fsr CFILES = xfs_fsr.c LLDLIBS = $(LIBHANDLE) +ifeq ($(HAVE_GETMNTENT),yes) +LCFLAGS += -DHAVE_GETMNTENT +endif + +ifeq ($(HAVE_GETMNTINFO),yes) +LCFLAGS += -DHAVE_GETMNTINFO +endif + default: depend $(LTCOMMAND) include $(BUILDRULES) diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c index 5f95cdc..ff791d3 100644 --- a/fsr/xfs_fsr.c +++ b/fsr/xfs_fsr.c @@ -32,8 +32,10 @@ #include #include -#ifdef HAVE_MNTENT +#if defined(HAVE_GETMNTENT) # include +#elif defined(HAVE_GETMNTINFO) +# include #endif #ifdef __APPLE__ @@ -191,9 +193,10 @@ find_mountpoint(char *mtab, char *argname, struct stat64 *sb) { struct mntent *t; struct stat64 ms; - FILE *mtabp; char *mntp = NULL; +#if defined(HAVE_GETMNTENT) + FILE *mtabp; mtabp = setmntent(mtab, "r"); if (!mtabp) { fprintf(stderr, _("%s: cannot read %s\n"), @@ -202,6 +205,27 @@ find_mountpoint(char *mtab, char *argname, struct stat64 *sb) } while ((t = getmntent(mtabp))) { +#elif defined(HAVE_GETMNTINFO) + struct statfs *stats; + int error, i, count; + // because "t" is a pointer, but we don't need to use + // malloc for this usage + struct mntent t_tmp; + t = &t_tmp; + + + error = 0; + if ((count = getmntinfo(&stats, 0)) < 0) { + fprintf(stderr, _("%s: getmntinfo() failed: %s\n"), + progname, strerror(errno)); + return 0; + } + + for (i = 0; i < count; i++) { + mntinfo2mntent(&stats[i], t); +#else +# error "How do I extract info about mounted filesystems on this platform?" +#endif if (S_ISDIR(sb->st_mode)) { /* mount point */ if (stat64(t->mnt_dir, &ms) < 0) continue; @@ -233,10 +257,11 @@ find_mountpoint(char *mtab, char *argname, struct stat64 *sb) break; } +#if defined(HAVE_GETMNTENT) endmntent(mtabp); +#endif return mntp; } - int main(int argc, char **argv) { @@ -411,18 +436,11 @@ usage(int ret) static void initallfs(char *mtab) { - FILE *fp; struct mntent *mp; int mi; char *cp; struct stat64 sb; - fp = setmntent(mtab, "r"); - if (fp == NULL) { - fsrprintf(_("could not open mtab file: %s\n"), mtab); - exit(1); - } - /* malloc a number of descriptors, increased later if needed */ if (!(fsbase = (fsdesc_t *)malloc(fsbufsize * sizeof(fsdesc_t)))) { fsrprintf(_("out of memory: %s\n"), strerror(errno)); @@ -433,7 +451,36 @@ initallfs(char *mtab) /* find all rw xfs file systems */ mi = 0; fs = fsbase; + +#if defined(HAVE_GETMNTENT) + FILE *fp; + fp = setmntent(mtab, "r"); + if (fp == NULL) { + fsrprintf(_("could not open mtab file: %s\n"), mtab); + exit(1); + } + while ((mp = getmntent(fp))) { +#elif defined(HAVE_GETMNTINFO) + struct statfs *stats; + int error, i, count; + // because "t" is a pointer, but we don't need to use + // malloc for this usage + struct mntent mp_tmp; + mp = &mp_tmp; + error = 0; + if ((count = getmntinfo(&stats, 0)) < 0) { + fprintf(stderr, _("%s: getmntinfo() failed: %s\n"), + progname, strerror(errno)); + exit(1); + } + + for (i = 0; i < count; i++) { + mntinfo2mntent(&stats[i], mp); +#else +# error "How do I extract info about mounted filesystems on this platform?" +#endif + int rw = 0; if (strcmp(mp->mnt_type, MNTTYPE_XFS ) != 0 || @@ -485,7 +532,9 @@ initallfs(char *mtab) } numfs = mi; fsend = (fsbase + numfs); +#if defined(HAVE_GETMNTENT) endmntent(fp); +#endif if (numfs == 0) { fsrprintf(_("no rw xfs file systems in mtab: %s\n"), mtab); exit(0); diff --git a/include/darwin.h b/include/darwin.h index 288ad1f..0313f46 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -218,7 +218,27 @@ static inline int timer_gettime (timer_t timerid, struct itimerspec *value) /* FSR */ +# include +# include +#include +#include #define statvfs64 statfs #define _PATH_MOUNTED "/etc/mtab" +struct mntent +{ + char *mnt_fsname; + char *mnt_dir; + char *mnt_type; + char *mnt_opts; + int mnt_freq; + int mnt_passno; +}; + +static inline void mntinfo2mntent (struct statfs * stats, struct mntent * mnt) { + mnt->mnt_fsname = stats->f_mntfromname; + mnt->mnt_dir = stats->f_mntonname; + mnt->mnt_type = stats->f_fstypename; +} + #endif /* __XFS_DARWIN_H__ */ -- 2.4.5 From jtulak@redhat.com Tue Sep 8 09:24:34 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 928EF7F37 for ; Tue, 8 Sep 2015 09:24:34 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 7F45D304048 for ; Tue, 8 Sep 2015 07:24:34 -0700 (PDT) X-ASG-Debug-ID: 1441722273-04cbb06acdf4c00001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id tMuh3b2gCMnt1U1O (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 08 Sep 2015 07:24:33 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 4397A2E837D; Tue, 8 Sep 2015 14:24:33 +0000 (UTC) Received: from localhost.localdomain (vpn1-5-113.ams2.redhat.com [10.36.5.113]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88EOVV5016767; Tue, 8 Sep 2015 10:24:32 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: hch@infradead.org, Jan Tulak Subject: [PATCH 09/11 v2] xfsprogs: Add statvfs64 for osx Date: Tue, 8 Sep 2015 16:24:23 +0200 X-ASG-Orig-Subj: [PATCH 09/11 v2] xfsprogs: Add statvfs64 for osx Message-Id: <1441722263-9194-1-git-send-email-jtulak@redhat.com> In-Reply-To: <1440590555-20463-9-git-send-email-jtulak@redhat.com> References: <1440590555-20463-9-git-send-email-jtulak@redhat.com> 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: 1441722273 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Simply rename statvfs64 to statfs with a #define. CHANGE: remove dummy code, add rename Signed-off-by: Jan Tulak --- fsr/xfs_fsr.c | 14 ++++++++++++++ include/builddefs.in | 2 +- include/darwin.h | 5 +++++ 3 files changed, 20 insertions(+), 1 deletion(-) diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c index e1b7bd6..5f95cdc 100644 --- a/fsr/xfs_fsr.c +++ b/fsr/xfs_fsr.c @@ -36,6 +36,12 @@ # include #endif +#ifdef __APPLE__ +//# define statvfs64 statfs; +# include +# include +#endif + #ifndef XFS_XFLAG_NODEFRAG #define XFS_XFLAG_NODEFRAG 0x00002000 /* src dependancy, remove later */ #endif @@ -948,7 +954,11 @@ fsrfile_common( fname, strerror(errno)); return -1; } +#ifndef statvfs64 bsize = vfss.f_frsize ? vfss.f_frsize : vfss.f_bsize; +#else + bsize = vfss.f_bsize; +#endif if (statp->bs_blksize * statp->bs_blocks > vfss.f_bfree * bsize - minimumfree) { fsrprintf(_("insufficient freespace for: %s: " @@ -1728,7 +1738,11 @@ xfs_getrt(int fd, struct statvfs64 *sfbp) close(fd); return -1; } +#ifndef statvfs64 bsize = (sfbp->f_frsize ? sfbp->f_frsize : sfbp->f_bsize); +#else + bsize = sfbp->f_bsize; +#endif factor = fsgeom.blocksize / bsize; /* currently this is == 1 */ sfbp->f_bfree = (cnt.freertx * fsgeom.rtextsize) * factor; return 0; diff --git a/include/builddefs.in b/include/builddefs.in index 25b8816..31e21ba 100644 --- a/include/builddefs.in +++ b/include/builddefs.in @@ -123,7 +123,7 @@ PCFLAGS = -D_GNU_SOURCE $(GCCFLAGS) endif ifeq ($(PKG_PLATFORM),darwin) PCFLAGS = $(GCCFLAGS) -DEPENDFLAGS = -D__APPLE__ +DEPENDFLAGS = -D__APPLE__ -D_DARWIN_FEATURE_64_BIT_INODE endif ifeq ($(PKG_PLATFORM),irix) PLDLIBS = -ldisk -lgen diff --git a/include/darwin.h b/include/darwin.h index 0d2f175..288ad1f 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -216,4 +216,9 @@ static inline int timer_gettime (timer_t timerid, struct itimerspec *value) return getitimer(ITIMER_REAL, value); } +/* FSR */ + +#define statvfs64 statfs +#define _PATH_MOUNTED "/etc/mtab" + #endif /* __XFS_DARWIN_H__ */ -- 2.4.5 From bfoster@redhat.com Tue Sep 8 09:45:35 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 442217F37 for ; Tue, 8 Sep 2015 09:45:35 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 2357F304039 for ; Tue, 8 Sep 2015 07:45:32 -0700 (PDT) X-ASG-Debug-ID: 1441723529-04cb6c18c800ad0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id JDeAzV9e0KtevDHM (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 07:45:29 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 2A3408E68F; Tue, 8 Sep 2015 14:45:29 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-237.bos.redhat.com [10.18.41.237]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88EjSSO027841; Tue, 8 Sep 2015 10:45:28 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 7AFD1123FB0; Tue, 8 Sep 2015 10:45:27 -0400 (EDT) Date: Tue, 8 Sep 2015 10:45:27 -0400 From: Brian Foster To: Dave Chinner Cc: xfs@oss.sgi.com, sage@redhat.com Subject: Re: [PATCH V2] xfs: timestamp updates cause excessive fdatasync log traffic Message-ID: <20150908144527.GB5305@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH V2] xfs: timestamp updates cause excessive fdatasync log traffic References: <1440724990-25073-1-git-send-email-david@fromorbit.com> <20150828043253.GB26895@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150828043253.GB26895@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441723529 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Fri, Aug 28, 2015 at 02:32:53PM +1000, Dave Chinner wrote: > > From: Dave Chinner > > Sage Weil reported that a ceph test workload was writing to the > log on every fdatasync during an overwrite workload. Event tracing > showed that the only metadata modification being made was the > timestamp updates during the write(2) syscall, but fdatasync(2) > is supposed to ignore them. The key observation was that the > transactions in the log all looked like this: > > INODE: #regs: 4 ino: 0x8b flags: 0x45 dsize: 32 > > And contained a flags field of 0x45 or 0x85, and had data and > attribute forks following the inode core. This means that the > timestamp updates were triggering dirty relogging of previously > logged parts of the inode that hadn't yet been flushed back to > disk. > > This is caused by xfs_trans_log_inode(), where it folds the dirty > fields that have previously been logged back into the current > transaction dirty fields from the inode item ili_last_fields. The > issue is that ili_last_fields only contains a non-zero value when > the inode is in the process of being flushed. The typical state > progression is this, using a core field update as the modification > occuring: > > state ili_fields ili_last_fields > clean 0 0 > modified, logged XFS_ILOG_CORE 0 > flushed to buffer 0 XFS_ILOG_CORE > > buffer IO done (clean) 0 0 > > However, if we run a new transaction after it has been flushed to > buffer but before the buffer IO is done, we don't know if the > modifications in the inode buffer (i.e. what is in ili_last_fields) > will reach the disk before the new transaction reaches the log. > Hence to keep transactional ordering correct in recovery, we need to > ensure the new transaction re-logs the modifications that are being > flushed to disk. > > By relogging, we ensure that if the transaction makes it to disk and > the buffer doesn't, then recovery replays all the changes upto that > point correctly. If the transaction does not make it disk, but the > buffer does, then recovery will see that the inode on disk is more > recent than in the log and won't overwrite it with changes that it > already contains. > > The upshot of this is that while the inode buffer sits in memory > with the inode in the "flushed" state, fdatasync is going to see > the relogged state in the ili_fields. i.e: > > What is happening here is this: > > state ili_fields ili_last_fields > clean 0 0 > modified, logged CORE 0 > flushed to buffer 0 CORE > > timestamp update TIMESTAMP CORE > > CORE|TIMESTAMP CORE > > sees field other than TIMESTAMP in ili_fields, > triggers xfs_log_force_lsn to flush inode > > > buffer IO done (clean) CORE|TIMESTAMP 0 > ..... Shouldn't both states be cleared here? If so, I don't see how the problem persists unless the race is perpetual... > > timestamp update CORE|TIMESTAMP 0 > > sees field other than TIMESTAMP in ili_fields, > triggers xfs_log_force_lsn to flush inode > ..... > > timestamp update CORE|TIMESTAMP 0 > > sees field other than TIMESTAMP in ili_fields, > triggers xfs_log_force_lsn to flush inode > > So, essentially, once a race condition on the buffer flush has > occurred, the condition is not cleared until the inode is flushed to > the buffer again and it is written without racing against the inode > being dirtied again. > Ok, so we would have to continuously race between the buffer I/O and inode logging events for this behavior to continue. How likely is that to happen on a constant workload? I ask because I see Sage had pointed out that this might not address his originally reported problem, so I'm wondering whether we still want to pursue this change. > The behaviour we really want here is to capture the timestamp > update transactionally, but not trigger fdatasync because of the > relogged fields that haven't been modified since the inode was > flushed to the buffer. We still need to relog them, but we don't > need to force the log in the fdatasync case. > > To do this, don't fold the ili_last_fields value into ili_fields > when logging the inode. Instead, fold it into the fields that get > logged during formatting of the inode item. This means that we will > stop logging those fields the moment we know that there is a more > recent version of the inode on disk than we have in the log and so > we don't need to log those fields anymore as the next transaction on > disk doesn't need to replay them. > > Doing this separates changes that are in memory but are not being > flushed from those that have been flushed. Hence we can now look at > ili_fields and hence see what fields have been modified since the > last flush, and hence whether fdatasync needs to force the log or > not. If non-timestamp changes have been made since the inode was > flushed to the backing buffer, then fdatasync will do exactly the > right thing (i.e. force the log). > > Reported-by: Sage Weil > Signed-off-by: Dave Chinner > --- > Version 2: > - include the hunk from fs/xfs/xfs_trans_inode.c that I missed > when committing the patch locally the first time. > > fs/xfs/xfs_inode_item.c | 161 +++++++++++++++++++++++++++++++++-------------- > fs/xfs/xfs_inode_item.h | 1 + > fs/xfs/xfs_trans_inode.c | 8 --- > 3 files changed, 115 insertions(+), 55 deletions(-) > > diff --git a/fs/xfs/xfs_inode_item.c b/fs/xfs/xfs_inode_item.c > index 62bd80f..be04eb2 100644 > --- a/fs/xfs/xfs_inode_item.c > +++ b/fs/xfs/xfs_inode_item.c > @@ -29,6 +29,63 @@ > #include "xfs_trans_priv.h" > #include "xfs_log.h" > > +/* > + * Notes on ili_fields, ili_format_fields and ili_last_fields. > + * > + * ili_fields contains the flags that reflect the current changes that are in > + * memory and have been logged, but have not been flushed to the backing buffer > + * for writeback yet. When a transaction is done, the fields that are modified > + * are added to ili_fields and all those fields are logged. This results in > + * repeated transactions correctly relogging all the other changes in memory and > + * allows the inode to be re-ordered (moved forward) in the AIL safely. > + * ili_fields is copied to ili_last_fields when the inode is flushed to the > + * backing buffer and is then cleared, indicating that the inode in memory is > + * now clean from a transactional change point of view and does not need to > + * relog those fields anymore on tranaction commit. > + * > + * ili_last_fields, therefore, is only set while there is an unresolved inode > + * flush being done (i.e. flush lock is held). We need to keep this state > + * available to avoid a transaction recovery vs inode buffer IO completion race > + * if we crash. If the inode is logged again makes it to disk before the inode ^ and > + * buffer IO complete, log recovery will replay the latest inode transaction and completes > + * can lose the changes that were in the inode buffer. Hence we still need to > + * log the changes that have been flushed so that transactions issued during the > + * inode buffer write still contain the modifications being flushed. Once the > + * inode buffer IO completes, we no longer need to log those changes as the > + * inode on disk the same as the inode in memory apart from the changes made ^ is > + * since the inode was flushed (i.e. those recorded in ili_fields). > + * > + * ili_format_fields is only used during transaction commit. It is the > + * aggregation of ili_fields and ili_last_fields, as sampled during the sizing > + * of the inode item to be logged. We need this field definition to be constant > + * between sizing and formatting, but inode buffer IO can complete > + * asynchronously with transaction commit and so we must only read it once so > + * that the different stages of the item formatting work correctly. We don't >From the comment alone, I'm a little confused as to whether this means we must combine and sample ili_format_fields only once, or just ili_last_fields as aggregrated into the former (and ili_format_fields is safe for the remainder of the transaction sizing/format sequence). > + * care about the async completion clearing ili_last_fields after we've sampled > + * it - if we log too much then so be it - we won't log it next time. Once we've > + * formatted the inode item, we need to propagate the ili_format_fields value to > + * the on-disk inode log item format field, and then use it to clear all the > + * fields that we marked for logging but were not dirty from ili_fields. > + * > + * This separation of changes allows us to accurately determine what fields in > + * the inode have changed since it was last flushed to disk. This is important > + * for fdatasync() performance as there are certain fields that, if modified, > + * should not trigger log forces because they contain metadata that fdatasync() > + * does not need to guarantee is safe on disk. This is, currently, just > + * XFS_ILOG_TIMESTAMP, though may be extended in future to cover other metadata. > + * > + * If we simply fold ili_last_fields back into ili_fields when we log the inode > + * in a transaction, then if we have a flush/modification race it results in > + * every timestamp update causing fdatasync to flush the log because ili_fields > + * has fields other than XFS_ILOG_TIMESTAMP set in it. This behaviour will > + * persist until the inode is next flushed to it's backing buffer and that > + * buffer is written and completed without another flush/modification race > + * occuring. Hence we keep the change state separate and only combine them when > + * formatting the inode into the log. > + * Thanks for the big comment. I think the above two paragraphs could probably be a bit more generic/succinct, however: "This separation of changes is necessary because certain codepaths require precise knowledge about what has been dirtied in the inode since the last transaction commit. For example, fdatasync() is allowed to skip log flushes in the event that only XFS_ILOG_TIMESTAMP is specified in ili_fields. Repopulating ili_fields from ili_last_fields at log time, as was previously done, pollutes this information and can defeat the optimization." > + * For more information, there's another big comment in xfs_iflush_int() about > + * this flush/modification race condition. > + */ > > kmem_zone_t *xfs_ili_zone; /* inode log item zone */ > > @@ -40,6 +97,7 @@ static inline struct xfs_inode_log_item *INODE_ITEM(struct xfs_log_item *lip) > STATIC void > xfs_inode_item_data_fork_size( > struct xfs_inode_log_item *iip, > + unsigned int fields, > int *nvecs, > int *nbytes) > { > @@ -47,7 +105,7 @@ xfs_inode_item_data_fork_size( > > switch (ip->i_d.di_format) { > case XFS_DINODE_FMT_EXTENTS: > - if ((iip->ili_fields & XFS_ILOG_DEXT) && > + if ((fields & XFS_ILOG_DEXT) && > ip->i_d.di_nextents > 0 && > ip->i_df.if_bytes > 0) { > /* worst case, doesn't subtract delalloc extents */ > @@ -56,14 +114,14 @@ xfs_inode_item_data_fork_size( > } > break; > case XFS_DINODE_FMT_BTREE: > - if ((iip->ili_fields & XFS_ILOG_DBROOT) && > + if ((fields & XFS_ILOG_DBROOT) && > ip->i_df.if_broot_bytes > 0) { > *nbytes += ip->i_df.if_broot_bytes; > *nvecs += 1; > } > break; > case XFS_DINODE_FMT_LOCAL: > - if ((iip->ili_fields & XFS_ILOG_DDATA) && > + if ((fields & XFS_ILOG_DDATA) && > ip->i_df.if_bytes > 0) { > *nbytes += roundup(ip->i_df.if_bytes, 4); > *nvecs += 1; > @@ -82,6 +140,7 @@ xfs_inode_item_data_fork_size( > STATIC void > xfs_inode_item_attr_fork_size( > struct xfs_inode_log_item *iip, > + unsigned int fields, > int *nvecs, > int *nbytes) > { > @@ -89,7 +148,7 @@ xfs_inode_item_attr_fork_size( > > switch (ip->i_d.di_aformat) { > case XFS_DINODE_FMT_EXTENTS: > - if ((iip->ili_fields & XFS_ILOG_AEXT) && > + if ((fields & XFS_ILOG_AEXT) && > ip->i_d.di_anextents > 0 && > ip->i_afp->if_bytes > 0) { > /* worst case, doesn't subtract unused space */ > @@ -98,14 +157,14 @@ xfs_inode_item_attr_fork_size( > } > break; > case XFS_DINODE_FMT_BTREE: > - if ((iip->ili_fields & XFS_ILOG_ABROOT) && > + if ((fields & XFS_ILOG_ABROOT) && > ip->i_afp->if_broot_bytes > 0) { > *nbytes += ip->i_afp->if_broot_bytes; > *nvecs += 1; > } > break; > case XFS_DINODE_FMT_LOCAL: > - if ((iip->ili_fields & XFS_ILOG_ADATA) && > + if ((fields & XFS_ILOG_ADATA) && > ip->i_afp->if_bytes > 0) { > *nbytes += roundup(ip->i_afp->if_bytes, 4); > *nvecs += 1; > @@ -133,13 +192,17 @@ xfs_inode_item_size( > struct xfs_inode_log_item *iip = INODE_ITEM(lip); > struct xfs_inode *ip = iip->ili_inode; > > + iip->ili_format_fields = iip->ili_fields | iip->ili_last_fields; > + > *nvecs += 2; > *nbytes += sizeof(struct xfs_inode_log_format) + > xfs_icdinode_size(ip->i_d.di_version); > > - xfs_inode_item_data_fork_size(iip, nvecs, nbytes); > + xfs_inode_item_data_fork_size(iip, iip->ili_format_fields, > + nvecs, nbytes); > if (XFS_IFORK_Q(ip)) > - xfs_inode_item_attr_fork_size(iip, nvecs, nbytes); > + xfs_inode_item_attr_fork_size(iip, iip->ili_format_fields, > + nvecs, nbytes); We aggregate ili_format_fields and pass the result as a parameter to the sizing helpers, but we just use ili_format_fields directly from the subsequent formatting helpers. The latter seems more clean to me since we pass iip everywhere already. Could we use that same pattern here as well? I suppose this also answers my question above in that ili_last_fields is sampled once and ili_format_fields used thereafter in the commit sequence. Brian > } > > STATIC void > @@ -151,14 +214,14 @@ xfs_inode_item_format_data_fork( > { > struct xfs_inode *ip = iip->ili_inode; > size_t data_bytes; > + unsigned int fields = iip->ili_format_fields; > > switch (ip->i_d.di_format) { > case XFS_DINODE_FMT_EXTENTS: > - iip->ili_fields &= > - ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | > - XFS_ILOG_DEV | XFS_ILOG_UUID); > + fields &= ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | > + XFS_ILOG_DEV | XFS_ILOG_UUID); > > - if ((iip->ili_fields & XFS_ILOG_DEXT) && > + if ((fields & XFS_ILOG_DEXT) && > ip->i_d.di_nextents > 0 && > ip->i_df.if_bytes > 0) { > struct xfs_bmbt_rec *p; > @@ -175,15 +238,14 @@ xfs_inode_item_format_data_fork( > ilf->ilf_dsize = data_bytes; > ilf->ilf_size++; > } else { > - iip->ili_fields &= ~XFS_ILOG_DEXT; > + fields &= ~XFS_ILOG_DEXT; > } > break; > case XFS_DINODE_FMT_BTREE: > - iip->ili_fields &= > - ~(XFS_ILOG_DDATA | XFS_ILOG_DEXT | > - XFS_ILOG_DEV | XFS_ILOG_UUID); > + fields &= ~(XFS_ILOG_DDATA | XFS_ILOG_DEXT | > + XFS_ILOG_DEV | XFS_ILOG_UUID); > > - if ((iip->ili_fields & XFS_ILOG_DBROOT) && > + if ((fields & XFS_ILOG_DBROOT) && > ip->i_df.if_broot_bytes > 0) { > ASSERT(ip->i_df.if_broot != NULL); > xlog_copy_iovec(lv, vecp, XLOG_REG_TYPE_IBROOT, > @@ -192,16 +254,15 @@ xfs_inode_item_format_data_fork( > ilf->ilf_dsize = ip->i_df.if_broot_bytes; > ilf->ilf_size++; > } else { > - ASSERT(!(iip->ili_fields & > - XFS_ILOG_DBROOT)); > - iip->ili_fields &= ~XFS_ILOG_DBROOT; > + ASSERT(!(fields & XFS_ILOG_DBROOT)); > + fields &= ~XFS_ILOG_DBROOT; > } > break; > case XFS_DINODE_FMT_LOCAL: > - iip->ili_fields &= > - ~(XFS_ILOG_DEXT | XFS_ILOG_DBROOT | > - XFS_ILOG_DEV | XFS_ILOG_UUID); > - if ((iip->ili_fields & XFS_ILOG_DDATA) && > + fields &= ~(XFS_ILOG_DEXT | XFS_ILOG_DBROOT | > + XFS_ILOG_DEV | XFS_ILOG_UUID); > + > + if ((fields & XFS_ILOG_DDATA) && > ip->i_df.if_bytes > 0) { > /* > * Round i_bytes up to a word boundary. > @@ -218,27 +279,28 @@ xfs_inode_item_format_data_fork( > ilf->ilf_dsize = (unsigned)data_bytes; > ilf->ilf_size++; > } else { > - iip->ili_fields &= ~XFS_ILOG_DDATA; > + fields &= ~XFS_ILOG_DDATA; > } > break; > case XFS_DINODE_FMT_DEV: > - iip->ili_fields &= > - ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | > - XFS_ILOG_DEXT | XFS_ILOG_UUID); > - if (iip->ili_fields & XFS_ILOG_DEV) > + fields &= ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | > + XFS_ILOG_DEXT | XFS_ILOG_UUID); > + if (fields & XFS_ILOG_DEV) > ilf->ilf_u.ilfu_rdev = ip->i_df.if_u2.if_rdev; > break; > case XFS_DINODE_FMT_UUID: > - iip->ili_fields &= > - ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | > - XFS_ILOG_DEXT | XFS_ILOG_DEV); > - if (iip->ili_fields & XFS_ILOG_UUID) > + fields &= ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | > + XFS_ILOG_DEXT | XFS_ILOG_DEV); > + if (fields & XFS_ILOG_UUID) > ilf->ilf_u.ilfu_uuid = ip->i_df.if_u2.if_uuid; > break; > default: > ASSERT(0); > break; > } > + > + /* reflect the logged fields back in ili_format_fields */ > + iip->ili_format_fields = fields; > } > > STATIC void > @@ -250,13 +312,13 @@ xfs_inode_item_format_attr_fork( > { > struct xfs_inode *ip = iip->ili_inode; > size_t data_bytes; > + unsigned int fields = iip->ili_format_fields; > > switch (ip->i_d.di_aformat) { > case XFS_DINODE_FMT_EXTENTS: > - iip->ili_fields &= > - ~(XFS_ILOG_ADATA | XFS_ILOG_ABROOT); > + fields &= ~(XFS_ILOG_ADATA | XFS_ILOG_ABROOT); > > - if ((iip->ili_fields & XFS_ILOG_AEXT) && > + if ((fields & XFS_ILOG_AEXT) && > ip->i_d.di_anextents > 0 && > ip->i_afp->if_bytes > 0) { > struct xfs_bmbt_rec *p; > @@ -272,14 +334,13 @@ xfs_inode_item_format_attr_fork( > ilf->ilf_asize = data_bytes; > ilf->ilf_size++; > } else { > - iip->ili_fields &= ~XFS_ILOG_AEXT; > + fields &= ~XFS_ILOG_AEXT; > } > break; > case XFS_DINODE_FMT_BTREE: > - iip->ili_fields &= > - ~(XFS_ILOG_ADATA | XFS_ILOG_AEXT); > + fields &= ~(XFS_ILOG_ADATA | XFS_ILOG_AEXT); > > - if ((iip->ili_fields & XFS_ILOG_ABROOT) && > + if ((fields & XFS_ILOG_ABROOT) && > ip->i_afp->if_broot_bytes > 0) { > ASSERT(ip->i_afp->if_broot != NULL); > > @@ -289,14 +350,13 @@ xfs_inode_item_format_attr_fork( > ilf->ilf_asize = ip->i_afp->if_broot_bytes; > ilf->ilf_size++; > } else { > - iip->ili_fields &= ~XFS_ILOG_ABROOT; > + fields &= ~XFS_ILOG_ABROOT; > } > break; > case XFS_DINODE_FMT_LOCAL: > - iip->ili_fields &= > - ~(XFS_ILOG_AEXT | XFS_ILOG_ABROOT); > + fields &= ~(XFS_ILOG_AEXT | XFS_ILOG_ABROOT); > > - if ((iip->ili_fields & XFS_ILOG_ADATA) && > + if ((fields & XFS_ILOG_ADATA) && > ip->i_afp->if_bytes > 0) { > /* > * Round i_bytes up to a word boundary. > @@ -313,13 +373,16 @@ xfs_inode_item_format_attr_fork( > ilf->ilf_asize = (unsigned)data_bytes; > ilf->ilf_size++; > } else { > - iip->ili_fields &= ~XFS_ILOG_ADATA; > + fields &= ~XFS_ILOG_ADATA; > } > break; > default: > ASSERT(0); > break; > } > + > + /* reflect the logged fields back in ili_format_fields */ > + iip->ili_format_fields = fields; > } > > /* > @@ -359,12 +422,16 @@ xfs_inode_item_format( > if (XFS_IFORK_Q(ip)) { > xfs_inode_item_format_attr_fork(iip, ilf, lv, &vecp); > } else { > - iip->ili_fields &= > + iip->ili_format_fields &= > ~(XFS_ILOG_ADATA | XFS_ILOG_ABROOT | XFS_ILOG_AEXT); > } > > /* update the format with the exact fields we actually logged */ > - ilf->ilf_fields |= (iip->ili_fields & ~XFS_ILOG_TIMESTAMP); > + ilf->ilf_fields |= (iip->ili_format_fields & ~XFS_ILOG_TIMESTAMP); > + > + /* clear any fields we didn't log from ili_fields */ > + iip->ili_fields &= iip->ili_format_fields; > + iip->ili_format_fields = 0; > } > > /* > diff --git a/fs/xfs/xfs_inode_item.h b/fs/xfs/xfs_inode_item.h > index 488d812..43a9e1c 100644 > --- a/fs/xfs/xfs_inode_item.h > +++ b/fs/xfs/xfs_inode_item.h > @@ -34,6 +34,7 @@ typedef struct xfs_inode_log_item { > unsigned short ili_logged; /* flushed logged data */ > unsigned int ili_last_fields; /* fields when flushed */ > unsigned int ili_fields; /* fields to be logged */ > + unsigned int ili_format_fields; /* combined log fields */ > } xfs_inode_log_item_t; > > static inline int xfs_inode_clean(xfs_inode_t *ip) > diff --git a/fs/xfs/xfs_trans_inode.c b/fs/xfs/xfs_trans_inode.c > index 17280cd..77f1e8a 100644 > --- a/fs/xfs/xfs_trans_inode.c > +++ b/fs/xfs/xfs_trans_inode.c > @@ -123,13 +123,5 @@ xfs_trans_log_inode( > tp->t_flags |= XFS_TRANS_DIRTY; > ip->i_itemp->ili_item.li_desc->lid_flags |= XFS_LID_DIRTY; > > - /* > - * Always OR in the bits from the ili_last_fields field. > - * This is to coordinate with the xfs_iflush() and xfs_iflush_done() > - * routines in the eventual clearing of the ili_fields bits. > - * See the big comment in xfs_iflush() for an explanation of > - * this coordination mechanism. > - */ > - flags |= ip->i_itemp->ili_last_fields; > ip->i_itemp->ili_fields |= flags; > } > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From iustin@k1024.org Tue Sep 8 09:48:15 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 885A87F37 for ; Tue, 8 Sep 2015 09:48:15 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 76E368F8050 for ; Tue, 8 Sep 2015 07:48:12 -0700 (PDT) X-ASG-Debug-ID: 1441723689-04cb6c18ca00c50001-NocioJ Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by cuda.sgi.com with ESMTP id o4b2xXjyJMBuGccp (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 08 Sep 2015 07:48:10 -0700 (PDT) X-Barracuda-Envelope-From: iustin@k1024.org X-Barracuda-Apparent-Source-IP: 209.85.212.174 Received: by wiclk2 with SMTP id lk2so118481853wic.1 for ; Tue, 08 Sep 2015 07:48:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-type:content-disposition :content-transfer-encoding:user-agent; bh=TLpiHiMNdvMNHgB7orir8SDeTctX+0p/eU0rs1hGtvI=; b=cnF51Tp0ftVIPzgoBkFdb5i8BwvUEgfOIdTmGIStlN6w5CC2x3umuX3lL01sin2I34 uswEmBfypZNxHWFWrwvOlpfeeguWWr6FnZbG/5dIVcsArBwwt824qrKzuy2YBu39ttt1 KXtZfLQCthS3StZNbOVj5Hs1EJ4H1Un3x6FPsih2l5huFKo8N2Fw4C7CNiEw37kM+z5Q ZRtZPW+aRk5Rs8Ir/KxArAi8dq8ESP53NNg1eNSfQ+cIC4PuSuPdicPlvTPqSLAUSMKy Dr9W4znf1j73vuEML54Qw72pd6/aVuyk4bJQe7GZGof0X/8nPwxH6kPhdSmpwqiUzCya ewew== X-Gm-Message-State: ALoCoQkJfLwz8Go32mwJYo0EeZvKvPKFTaR9FrJZVfHQc3r0HeiO9fxNzFk1rdVi7qjj4wxg4ksk X-Received: by 10.195.11.202 with SMTP id ek10mr47957145wjd.12.1441723688645; Tue, 08 Sep 2015 07:48:08 -0700 (PDT) Received: from teal.hq.k1024.org (178-83-234-80.dynamic.hispeed.ch. [178.83.234.80]) by smtp.gmail.com with ESMTPSA id s9sm5274951wiy.1.2015.09.08.07.48.07 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Sep 2015 07:48:07 -0700 (PDT) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id BEE84487C00; Tue, 8 Sep 2015 16:48:06 +0200 (CEST) Date: Tue, 8 Sep 2015 16:48:06 +0200 From: Iustin Pop To: xfs@oss.sgi.com Subject: xfsrestore and multi-tape backups Message-ID: <20150908144806.GA22811@teal.hq.k1024.org> X-ASG-Orig-Subj: xfsrestore and multi-tape backups Mail-Followup-To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.23 (2014-03-12) X-Barracuda-Connect: mail-wi0-f174.google.com[209.85.212.174] X-Barracuda-Start-Time: 1441723689 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22335 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Hi all, Sorry for the long email. I don't understand how xfsrestore is supposed to work when restoring a dump spanning multiple tapes, maybe someone can explain things to me. I did an xfsdump: xfsdump -p 30 -f /dev/nst0 -l 0 -L "..." -M tape_0 -J /fs I don't have the output from it anymore, but it run out of tape, prompted me to insert a new media (which I named tape_02), I did, and then it finished successfully. I went then to do the restore after recreating the filesystem (so I don't have the original FS to do comparisons), and per the xfsrestore man page ("If a dump spans multiple media objects, the restore must begin with the media object containing the first media file dumped. The operator is prompted when the next media object is needed.") I inserted the first tape, and run the restore (note same tape ID as in the dump): xfsrestore -p 300 -T -J -f /dev/nst0 /fs xfsrestore: using scsi tape (drive_scsitape) strategy xfsrestore: version 3.1.4 (dump format 3.0) - type ^C for status and control xfsrestore: searching media for dump xfsrestore: preparing drive xfsrestore: examining media file 0 =========================== dump selection dialog ============================ the following dump has been found on drive 0 … media label: "tape_0" … restore this dump? 1: skip 2: restore (default) -> 2 this dump selected for restoral --------------------------------- end dialog --------------------------------- xfsrestore: searching media for directory dump xfsrestore: reading directories xfsrestore: 17241 directories and 875931 entries processed … xfsrestore: status at 01:04:03: 785594/858613 files restored, 89.2% complete, 18300 seconds elapsed xfsrestore: attempt to read 3719168 bytes failed: end of media file xfsrestore: restore complete: 18449 seconds elapsed xfsrestore: Restore Summary: xfsrestore: stream 0 /dev/nst0 OK (success) xfsrestore: Restore Status: SUCCESS And back to the shell, without asking me to insert a new media. I though maybe I need to manually do the second tape, so I did insert tape_02 and run: xfsrestore -p 300 -T -J -f /dev/nst0 /swamp xfsrestore: using scsi tape (drive_scsitape) strategy xfsrestore: version 3.1.4 (dump format 3.0) - type ^C for status and control xfsrestore: searching media for dump xfsrestore: preparing drive xfsrestore: examining media file 0 =========================== dump selection dialog ============================ the following dump has been found on drive 0 … media label: "tape_02" … restore this dump? 1: skip 2: restore (default) -> 2 this dump selected for restoral --------------------------------- end dialog --------------------------------- xfsrestore: searching media for directory dump xfsrestore: reading directories xfsrestore: 17241 directories and 875931 entries processed xfsrestore: directory post-processing xfsrestore: restoring non-directory files … xfsrestore: status at 01:43:32: 66021/858613 files restored, 9.7% complete, 2100 seconds elapsed xfsrestore: examining media file 1 ============================ change media dialog ============================= please change media in drive 1: media change declined 2: display media inventory status 3: list needed media objects 4: media changed (default) -> Here I was sure that it will know to prompt me for the first tape (maybe the restore needs to start from the last media object?), but: (selecting list needed media objects) -> 3 here may be unidentified media objects not yet fully restored --------------------------------- end dialog --------------------------------- ============================ change media dialog ============================= So it didn't know about any missing media. I reinserted the first tape, restored again it contents (long process, it did read the entire tape), at the end it prompted me *once more* for more media. Note that now it had a different error message than in the first restore (where it said "attempt to read NNNN bytes failed"): xfsrestore: status at 15:23:32: 849732/858613 files restored, 99.0% complete, 51300 seconds elapsed xfsrestore: attempt to read 3719168 bytes failed: end of media file xfsrestore: WARNING: hit EOD at stream 0 object 0, yet inventory indicates last object index is 1 ============================ change media dialog ============================= It still didn't know about any "missing" media, and the media inventory status at this time was: -> 2 session inventory display media stream 0: media object 0: label: "tape_0" id: 9f0405b8-d4bc-4f13-aa80-32a587decfd3 index within object of first media file: 0 media file 0 (0): first extent contained: ino 515 off 0 next extent to restore: ino 7522410547 off 134217728 non-directories done may be additional unidentified media files media object 1: label: "tape_02" id: 232ed239-9020-4da6-8ea5-abe6f22c9f0a index within object of first media file: 0 media file 0 (0): used for directory restoral first extent contained: ino 7522410547 off 134217728 next extent to restore: ino 8283659327 off 0 non-directories done media file 1 (1): is stream terminator --------------------------------- end dialog --------------------------------- I don't know how to parse this output. tape_02 seems consistent, tape_0 seems to not have all the information needed maybe? I inserted the 2nd tape again: 4: media changed (default) -> 4 examining new media --------------------------------- end dialog --------------------------------- xfsrestore: status at 15:28:32: 858069/858613 files restored, 100.0% complete, 51600 seconds elapsed xfsrestore: preparing drive xfsrestore: examining media file 0 xfsrestore: restore complete: 51946 seconds elapsed xfsrestore: Restore Summary: xfsrestore: stream 0 /dev/nst0 OK (success) xfsrestore: Restore Status: SUCCESS This time it didn't actually read anything from tape beyond the index (mt tell said block 1 afterwards, and there was no "tape reading" noise). It looks like it finished correctly, but also the first incomplete restore also said "SUCCESS". So at this point: I don't know what I did wrong, or if there was an issue with my tape unit where it didn't write things correctly to the end of the first tape. Or is the man page out of date? I also don't know for sure if everything was restored (858069/858613 files restored means I lost at most 544 files lost, but I presume that was just because the progress report interval was high). I didn't do a "find" before the dump to compare file lists. Hope someone can enlighten me :) thanks in advance, iustin From billodo@redhat.com Tue Sep 8 10:09:55 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2C5CA7F37 for ; Tue, 8 Sep 2015 10:09:55 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 193F330404E for ; Tue, 8 Sep 2015 08:09:55 -0700 (PDT) X-ASG-Debug-ID: 1441724993-04cbb025b400a70001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 3VBmybva4GiFsegI (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 08:09:54 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id A72D32620 for ; Tue, 8 Sep 2015 15:09:53 +0000 (UTC) Received: from localhost.localdomain.com (vpn-57-55.rdu2.redhat.com [10.10.57.55]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88F9pIP001556 for ; Tue, 8 Sep 2015 11:09:53 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 2/4] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Date: Tue, 8 Sep 2015 10:09:30 -0500 X-ASG-Orig-Subj: [PATCH 2/4] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-Id: <1441724972-7086-3-git-send-email-billodo@redhat.com> In-Reply-To: <1441724972-7086-1-git-send-email-billodo@redhat.com> References: <1441724972-7086-1-git-send-email-billodo@redhat.com> 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: 1441724994 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 6008e25..a9f05de 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -244,9 +244,10 @@ xfs_init_procfs(void) if (!proc_mkdir("fs/xfs", NULL)) goto out; - if (!proc_create("fs/xfs/stat", 0, NULL, - &xfs_stat_proc_fops)) + if (!proc_symlink("fs/xfs/stat", NULL, + "/sys/fs/xfs/stats/stats")) goto out_remove_xfs_dir; + #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, &xqmstat_proc_fops)) -- 2.4.3 From billodo@redhat.com Tue Sep 8 10:09:55 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 6F6777F37 for ; Tue, 8 Sep 2015 10:09:55 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 5D92B30404E for ; Tue, 8 Sep 2015 08:09:55 -0700 (PDT) X-ASG-Debug-ID: 1441724993-04cb6c18c9018e0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id fAM1H8j0GMaI6TEk (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 08:09:53 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 2BC3E461C4 for ; Tue, 8 Sep 2015 15:09:53 +0000 (UTC) Received: from localhost.localdomain.com (vpn-57-55.rdu2.redhat.com [10.10.57.55]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88F9pIO001556 for ; Tue, 8 Sep 2015 11:09:52 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 1/4] xfs: create global stats and stats_clear in sysfs Date: Tue, 8 Sep 2015 10:09:29 -0500 X-ASG-Orig-Subj: [PATCH 1/4] xfs: create global stats and stats_clear in sysfs Message-Id: <1441724972-7086-2-git-send-email-billodo@redhat.com> In-Reply-To: <1441724972-7086-1-git-send-email-billodo@redhat.com> References: <1441724972-7086-1-git-send-email-billodo@redhat.com> 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: 1441724993 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Currently, xfs global stats are in procfs. This patch introduces (replicates) the global stats in sysfs. Additionally a stats_clear file is introduced in sysfs. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_stats.h | 2 ++ fs/xfs/xfs_super.c | 20 +++++++++---- fs/xfs/xfs_sysctl.c | 15 ++-------- fs/xfs/xfs_sysfs.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_sysfs.h | 1 + 6 files changed, 179 insertions(+), 17 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index f224038..6008e25 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -29,6 +29,89 @@ static int counter_val(int idx) return val; } +int xfs_stats_format(char *buf) +{ + int i, j; + int len = 0; + __uint64_t xs_xstrat_bytes = 0; + __uint64_t xs_write_bytes = 0; + __uint64_t xs_read_bytes = 0; + + static const struct xstats_entry { + char *desc; + int endpoint; + } xstats[] = { + { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, + { "abt", XFSSTAT_END_ALLOC_BTREE }, + { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, + { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, + { "dir", XFSSTAT_END_DIRECTORY_OPS }, + { "trans", XFSSTAT_END_TRANSACTIONS }, + { "ig", XFSSTAT_END_INODE_OPS }, + { "log", XFSSTAT_END_LOG_OPS }, + { "push_ail", XFSSTAT_END_TAIL_PUSHING }, + { "xstrat", XFSSTAT_END_WRITE_CONVERT }, + { "rw", XFSSTAT_END_READ_WRITE_OPS }, + { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, + { "icluster", XFSSTAT_END_INODE_CLUSTER }, + { "vnodes", XFSSTAT_END_VNODE_OPS }, + { "buf", XFSSTAT_END_BUF }, + { "abtb2", XFSSTAT_END_ABTB_V2 }, + { "abtc2", XFSSTAT_END_ABTC_V2 }, + { "bmbt2", XFSSTAT_END_BMBT_V2 }, + { "ibt2", XFSSTAT_END_IBT_V2 }, + { "fibt2", XFSSTAT_END_FIBT_V2 }, + /* we print both series of quota information together */ + { "qm", XFSSTAT_END_QM }, + }; + + /* Loop over all stats groups */ + + for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { + len += snprintf(buf + len, PATH_MAX - len, "%s", + xstats[i].desc); + /* inner loop does each group */ + for (; j < xstats[i].endpoint; j++) + len += snprintf(buf + len, PATH_MAX - len, " %u", + counter_val(j)); + len += snprintf(buf + len, PATH_MAX - len, "\n"); + } + /* extra precision counters */ + for_each_possible_cpu(i) { + xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; + xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; + xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; + } + + len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", + xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); + len += snprintf(buf+len, PATH_MAX-len, "debug %u\n", +#if defined(DEBUG) + 1); +#else + 0); +#endif + +return len; +} + +void xfs_stats_clearall(void) +{ + int c; + __uint32_t vn_active; + + xfs_notice(NULL, "Clearing xfsstats"); + for_each_possible_cpu(c) { + preempt_disable(); + /* save vn_active, it's a universal truth! */ + vn_active = per_cpu(xfsstats, c).vn_active; + memset(&per_cpu(xfsstats, c), 0, + sizeof(struct xfsstats)); + per_cpu(xfsstats, c).vn_active = vn_active; + preempt_enable(); + } +} + static int xfs_stat_proc_show(struct seq_file *m, void *v) { int i, j; diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index c8f238b..18807b5 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -18,6 +18,8 @@ #ifndef __XFS_STATS_H__ #define __XFS_STATS_H__ +int xfs_stats_format(char *buf); +void xfs_stats_clearall(void); #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 3bf503a..31ad281 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -61,6 +61,7 @@ static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; static struct kset *xfs_kset; /* top-level xfs sysfs dir */ +static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ #ifdef DEBUG static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ #endif @@ -1838,19 +1839,25 @@ init_xfs_fs(void) xfs_kset = kset_create_and_add("xfs", NULL, fs_kobj); if (!xfs_kset) { error = -ENOMEM; - goto out_sysctl_unregister;; + goto out_sysctl_unregister; } + xfs_stats_kobj.kobject.kset = xfs_kset; + error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, + "stats"); + if (error) + goto out_kset_unregister; + #ifdef DEBUG xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_kset_unregister; + goto out_remove_stats_kobj; #endif error = xfs_qm_init(); if (error) - goto out_remove_kobj; + goto out_remove_dbg_kobj; error = register_filesystem(&xfs_fs_type); if (error) @@ -1859,11 +1866,13 @@ init_xfs_fs(void) out_qm_exit: xfs_qm_exit(); - out_remove_kobj: + out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_kset_unregister: + out_remove_stats_kobj: #endif + xfs_sysfs_del(&xfs_stats_kobj); + out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: xfs_sysctl_unregister(); @@ -1889,6 +1898,7 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif + xfs_sysfs_del(&xfs_stats_kobj); kset_unregister(xfs_kset); xfs_sysctl_unregister(); xfs_cleanup_procfs(); diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c index a0c8067..5defabb 100644 --- a/fs/xfs/xfs_sysctl.c +++ b/fs/xfs/xfs_sysctl.c @@ -19,6 +19,7 @@ #include #include #include "xfs_error.h" +#include "xfs_stats.h" static struct ctl_table_header *xfs_table_header; @@ -31,22 +32,12 @@ xfs_stats_clear_proc_handler( size_t *lenp, loff_t *ppos) { - int c, ret, *valp = ctl->data; - __uint32_t vn_active; + int ret, *valp = ctl->data; ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); if (!ret && write && *valp) { - xfs_notice(NULL, "Clearing xfsstats"); - for_each_possible_cpu(c) { - preempt_disable(); - /* save vn_active, it's a universal truth! */ - vn_active = per_cpu(xfsstats, c).vn_active; - memset(&per_cpu(xfsstats, c), 0, - sizeof(struct xfsstats)); - per_cpu(xfsstats, c).vn_active = vn_active; - preempt_enable(); - } + xfs_stats_clearall(); xfs_stats_clear = 0; } diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index aa03670..a094e20 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -21,6 +21,7 @@ #include "xfs_log_format.h" #include "xfs_log.h" #include "xfs_log_priv.h" +#include "xfs_stats.h" struct xfs_sysfs_attr { struct attribute attr; @@ -38,6 +39,8 @@ to_attr(struct attribute *attr) static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RW(name) #define XFS_SYSFS_ATTR_RO(name) \ static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RO(name) +#define XFS_SYSFS_ATTR_WO(name) \ + static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_WO(name) #define ATTR_LIST(name) &xfs_sysfs_attr_##name.attr @@ -125,6 +128,78 @@ struct kobj_type xfs_dbg_ktype = { #endif /* DEBUG */ + +/* stats */ + +STATIC ssize_t +stats_show( + char *buf, + void *data) +{ + return xfs_stats_format(buf); +} +XFS_SYSFS_ATTR_RO(stats); + +STATIC ssize_t +stats_clear_store( + const char *buf, + size_t count, + void *data) +{ + int ret; + int val; + + ret = kstrtoint(buf, 0, &val); + if (ret) + return ret; + + if (val != 1) + return -EINVAL; + xfs_stats_clearall(); + return count; +} +XFS_SYSFS_ATTR_WO(stats_clear); + +static struct attribute *xfs_stats_attrs[] = { + ATTR_LIST(stats), + ATTR_LIST(stats_clear), + NULL, +}; + +STATIC ssize_t +xfs_stats_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; +} + +STATIC ssize_t +xfs_stats_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; +} + +static struct sysfs_ops xfs_stats_ops = { + .show = xfs_stats_show, + .store = xfs_stats_store, +}; + +struct kobj_type xfs_stats_ktype = { + .release = xfs_sysfs_release, + .sysfs_ops = &xfs_stats_ops, + .default_attrs = xfs_stats_attrs, +}; + /* xlog */ STATIC ssize_t diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h index 240eee3..be692e5 100644 --- a/fs/xfs/xfs_sysfs.h +++ b/fs/xfs/xfs_sysfs.h @@ -22,6 +22,7 @@ extern struct kobj_type xfs_mp_ktype; /* xfs_mount */ extern struct kobj_type xfs_dbg_ktype; /* debug */ extern struct kobj_type xfs_log_ktype; /* xlog */ +extern struct kobj_type xfs_stats_ktype; /* stats */ static inline struct xfs_kobj * to_kobj(struct kobject *kobject) -- 2.4.3 From billodo@redhat.com Tue Sep 8 10:09:57 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2DCC87F56 for ; Tue, 8 Sep 2015 10:09:57 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 1939C304039 for ; Tue, 8 Sep 2015 08:09:54 -0700 (PDT) X-ASG-Debug-ID: 1441724992-04cbb025b600a70001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id NrRGbnZhyNJcixn5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 08:09:53 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id A4FEDC04FF81 for ; Tue, 8 Sep 2015 15:09:52 +0000 (UTC) Received: from localhost.localdomain.com (vpn-57-55.rdu2.redhat.com [10.10.57.55]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88F9pIN001556 for ; Tue, 8 Sep 2015 11:09:52 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 0/4 V4] xfs: new global stats in sysfs Date: Tue, 8 Sep 2015 10:09:28 -0500 X-ASG-Orig-Subj: [PATCH 0/4 V4] xfs: new global stats in sysfs Message-Id: <1441724972-7086-1-git-send-email-billodo@redhat.com> 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: 1441724993 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi all- Here is a new pass at the series to add new global stats to sysfs. The new series now includes a fourth patch that consolidates sysfs ops for debug, stats and log. (Per Dave Chinner's suggestion to create a common sysfs_ops structure to help streamline). The series provides the beginnings of the infrastructure for per-fs stats (in addition to global accumulative stats). We already have per-fs information in /sys, so it makes sense to have per-fs stats there too. As a first step, moving existing global stats infrastructure to /sys will allow us to re-use that sysfs code for per-fs stats as well. Patch 1 handles the bring-up and tear down of xfs/stats directory structure in sysfs when an fs is mounted. The directory contains the stats file and the stats_clear file. The stats file contents mimic those of /proc/fs/xfs/stat. The stats_clear file is empty, and much like the current stat_clear command, handles the zeroing of the stats file when a "1" is echoed to the stats_clear file. Patch 2 creates the symlink for stats from procfs to sysfs. Patch 3 removes the now unused portions of procfs for stat. Patch 4 consolidates the sysfs ops for dbg, stats, log. Once again, comments and questions are welcome. Thanks- Bill From billodo@redhat.com Tue Sep 8 10:09:58 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id CEBC97F56 for ; Tue, 8 Sep 2015 10:09:58 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id AE9C98F8050 for ; Tue, 8 Sep 2015 08:09:55 -0700 (PDT) X-ASG-Debug-ID: 1441724994-04cb6c18c8018e0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id m236o9bMy2rC50i3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 08:09:54 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 30A8BA86 for ; Tue, 8 Sep 2015 15:09:54 +0000 (UTC) Received: from localhost.localdomain.com (vpn-57-55.rdu2.redhat.com [10.10.57.55]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88F9pIQ001556 for ; Tue, 8 Sep 2015 11:09:53 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 3/4] xfs: remove unused procfs code Date: Tue, 8 Sep 2015 10:09:31 -0500 X-ASG-Orig-Subj: [PATCH 3/4] xfs: remove unused procfs code Message-Id: <1441724972-7086-4-git-send-email-billodo@redhat.com> In-Reply-To: <1441724972-7086-1-git-send-email-billodo@redhat.com> References: <1441724972-7086-1-git-send-email-billodo@redhat.com> 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: 1441724994 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch removes the now unused procfs code that was xfs stat specific. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 74 ------------------------------------------------------ 1 file changed, 74 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index a9f05de..05d5227 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -112,80 +112,6 @@ void xfs_stats_clearall(void) } } -static int xfs_stat_proc_show(struct seq_file *m, void *v) -{ - int i, j; - __uint64_t xs_xstrat_bytes = 0; - __uint64_t xs_write_bytes = 0; - __uint64_t xs_read_bytes = 0; - - static const struct xstats_entry { - char *desc; - int endpoint; - } xstats[] = { - { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, - { "abt", XFSSTAT_END_ALLOC_BTREE }, - { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, - { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, - { "dir", XFSSTAT_END_DIRECTORY_OPS }, - { "trans", XFSSTAT_END_TRANSACTIONS }, - { "ig", XFSSTAT_END_INODE_OPS }, - { "log", XFSSTAT_END_LOG_OPS }, - { "push_ail", XFSSTAT_END_TAIL_PUSHING }, - { "xstrat", XFSSTAT_END_WRITE_CONVERT }, - { "rw", XFSSTAT_END_READ_WRITE_OPS }, - { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, - { "icluster", XFSSTAT_END_INODE_CLUSTER }, - { "vnodes", XFSSTAT_END_VNODE_OPS }, - { "buf", XFSSTAT_END_BUF }, - { "abtb2", XFSSTAT_END_ABTB_V2 }, - { "abtc2", XFSSTAT_END_ABTC_V2 }, - { "bmbt2", XFSSTAT_END_BMBT_V2 }, - { "ibt2", XFSSTAT_END_IBT_V2 }, - { "fibt2", XFSSTAT_END_FIBT_V2 }, - /* we print both series of quota information together */ - { "qm", XFSSTAT_END_QM }, - }; - - /* Loop over all stats groups */ - for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { - seq_printf(m, "%s", xstats[i].desc); - /* inner loop does each group */ - for (; j < xstats[i].endpoint; j++) - seq_printf(m, " %u", counter_val(j)); - seq_putc(m, '\n'); - } - /* extra precision counters */ - for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; - } - - seq_printf(m, "xpc %Lu %Lu %Lu\n", - xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); - seq_printf(m, "debug %u\n", -#if defined(DEBUG) - 1); -#else - 0); -#endif - return 0; -} - -static int xfs_stat_proc_open(struct inode *inode, struct file *file) -{ - return single_open(file, xfs_stat_proc_show, NULL); -} - -static const struct file_operations xfs_stat_proc_fops = { - .owner = THIS_MODULE, - .open = xfs_stat_proc_open, - .read = seq_read, - .llseek = seq_lseek, - .release = single_release, -}; - /* legacy quota interfaces */ #ifdef CONFIG_XFS_QUOTA static int xqm_proc_show(struct seq_file *m, void *v) -- 2.4.3 From billodo@redhat.com Tue Sep 8 10:10:00 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 6092C29DFE for ; Tue, 8 Sep 2015 10:10:00 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id D59ACAC001 for ; Tue, 8 Sep 2015 08:09:56 -0700 (PDT) X-ASG-Debug-ID: 1441724994-04cbb025b200a70001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id ceB8qX9VkXYzQDwe (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 08:09:55 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id AD1EF2E8377 for ; Tue, 8 Sep 2015 15:09:54 +0000 (UTC) Received: from localhost.localdomain.com (vpn-57-55.rdu2.redhat.com [10.10.57.55]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88F9pIR001556 for ; Tue, 8 Sep 2015 11:09:54 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 4/4] xfs: consolidate sysfs ops (dbg, stats, log) Date: Tue, 8 Sep 2015 10:09:32 -0500 X-ASG-Orig-Subj: [PATCH 4/4] xfs: consolidate sysfs ops (dbg, stats, log) Message-Id: <1441724972-7086-5-git-send-email-billodo@redhat.com> In-Reply-To: <1441724972-7086-1-git-send-email-billodo@redhat.com> References: <1441724972-7086-1-git-send-email-billodo@redhat.com> 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: 1441724995 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the series to move xfs global stats from procfs to sysfs, this patch consolidates the sysfs ops functions and removes redundancy. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 2 +- fs/xfs/xfs_sysfs.c | 147 ++++++++++++++++++----------------------------------- 2 files changed, 51 insertions(+), 98 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 05d5227..dc6ca67 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -92,7 +92,7 @@ int xfs_stats_format(char *buf) 0); #endif -return len; + return len; } void xfs_stats_clearall(void) diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index a094e20..6c44e95 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -54,6 +54,53 @@ struct kobj_type xfs_mp_ktype = { .release = xfs_sysfs_release, }; +static inline struct xlog * +to_xlog(struct kobject *kobject) +{ + struct xfs_kobj *kobj = to_kobj(kobject); + return container_of(kobj, struct xlog, l_kobj); +} + +STATIC ssize_t +xfs_sysfs_object_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + struct kobj_type *ktype = get_ktype(kobject); + + if (ktype == &xfs_log_ktype) { + struct xlog *log = to_xlog(kobject); + return xfs_attr->show ? xfs_attr->show(buf, log) : 0; + } + else + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; +} + +STATIC ssize_t +xfs_sysfs_object_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + struct kobj_type *ktype = get_ktype(kobject); + + if (ktype == &xfs_log_ktype) { + struct xlog *log = to_xlog(kobject); + return xfs_attr->store ? xfs_attr->store(buf, count, log) : 0; + } + else + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; +} + +static struct sysfs_ops xfs_sysfs_ops = { + .show = xfs_sysfs_object_show, + .store = xfs_sysfs_object_store, +}; + #ifdef DEBUG /* debug */ @@ -92,43 +139,14 @@ static struct attribute *xfs_dbg_attrs[] = { NULL, }; -STATIC ssize_t -xfs_dbg_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; -} - -STATIC ssize_t -xfs_dbg_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; -} - -static struct sysfs_ops xfs_dbg_ops = { - .show = xfs_dbg_show, - .store = xfs_dbg_store, -}; - struct kobj_type xfs_dbg_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_dbg_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_dbg_attrs, }; #endif /* DEBUG */ - /* stats */ STATIC ssize_t @@ -166,37 +184,9 @@ static struct attribute *xfs_stats_attrs[] = { NULL, }; -STATIC ssize_t -xfs_stats_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; -} - -STATIC ssize_t -xfs_stats_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; -} - -static struct sysfs_ops xfs_stats_ops = { - .show = xfs_stats_show, - .store = xfs_stats_store, -}; - struct kobj_type xfs_stats_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_stats_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_stats_attrs, }; @@ -270,45 +260,8 @@ static struct attribute *xfs_log_attrs[] = { NULL, }; -static inline struct xlog * -to_xlog(struct kobject *kobject) -{ - struct xfs_kobj *kobj = to_kobj(kobject); - return container_of(kobj, struct xlog, l_kobj); -} - -STATIC ssize_t -xfs_log_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xlog *log = to_xlog(kobject); - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, log) : 0; -} - -STATIC ssize_t -xfs_log_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xlog *log = to_xlog(kobject); - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, log) : 0; -} - -static struct sysfs_ops xfs_log_ops = { - .show = xfs_log_show, - .store = xfs_log_store, -}; - struct kobj_type xfs_log_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_log_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_log_attrs, }; -- 2.4.3 From bfoster@redhat.com Tue Sep 8 11:23:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 57D1F7F37 for ; Tue, 8 Sep 2015 11:23:08 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id D0B74AC001 for ; Tue, 8 Sep 2015 09:23:04 -0700 (PDT) X-ASG-Debug-ID: 1441729382-04cbb005eb01790001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id sJzWH7UnCIBCESwr (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 09:23:03 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 678F4461D2 for ; Tue, 8 Sep 2015 16:23:02 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-237.bos.redhat.com [10.18.41.237]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88GN1gb023552; Tue, 8 Sep 2015 12:23:02 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id B80D2123FB0; Tue, 8 Sep 2015 12:23:00 -0400 (EDT) Date: Tue, 8 Sep 2015 12:23:00 -0400 From: Brian Foster To: "Bill O'Donnell" Cc: xfs@oss.sgi.com Subject: Re: [PATCH 4/4] xfs: consolidate sysfs ops (dbg, stats, log) Message-ID: <20150908162300.GC5305@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 4/4] xfs: consolidate sysfs ops (dbg, stats, log) References: <1441724972-7086-1-git-send-email-billodo@redhat.com> <1441724972-7086-5-git-send-email-billodo@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441724972-7086-5-git-send-email-billodo@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1441729383 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 08, 2015 at 10:09:32AM -0500, Bill O'Donnell wrote: > As a part of the series to move xfs global stats from procfs to sysfs, > this patch consolidates the sysfs ops functions and removes redundancy. > > Signed-off-by: Bill O'Donnell > --- > fs/xfs/xfs_stats.c | 2 +- > fs/xfs/xfs_sysfs.c | 147 ++++++++++++++++++----------------------------------- > 2 files changed, 51 insertions(+), 98 deletions(-) > > diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > index 05d5227..dc6ca67 100644 > --- a/fs/xfs/xfs_stats.c > +++ b/fs/xfs/xfs_stats.c > @@ -92,7 +92,7 @@ int xfs_stats_format(char *buf) > 0); > #endif > > -return len; > + return len; Looks like this snuck in from a fix to a previous patch. > } > > void xfs_stats_clearall(void) > diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c > index a094e20..6c44e95 100644 > --- a/fs/xfs/xfs_sysfs.c > +++ b/fs/xfs/xfs_sysfs.c > @@ -54,6 +54,53 @@ struct kobj_type xfs_mp_ktype = { > .release = xfs_sysfs_release, > }; > > +static inline struct xlog * > +to_xlog(struct kobject *kobject) > +{ > + struct xfs_kobj *kobj = to_kobj(kobject); > + return container_of(kobj, struct xlog, l_kobj); > +} > + > +STATIC ssize_t > +xfs_sysfs_object_show( > + struct kobject *kobject, > + struct attribute *attr, > + char *buf) > +{ > + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); > + struct kobj_type *ktype = get_ktype(kobject); > + > + if (ktype == &xfs_log_ktype) { > + struct xlog *log = to_xlog(kobject); > + return xfs_attr->show ? xfs_attr->show(buf, log) : 0; > + } > + else > + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; Could we just set a void pointer to the object and not duplicate the function call? The attribute handler parameter is a void * anyways. E.g.: void *data = NULL; ... if (...) data = to_xlog(kobject); return xfs_attr->show ? xfs_attr->show(buf, data) : 0; (and in the store path as well). Otherwise, looks like a nice cleanup to me. Brian P.S., It's good practice to include a brief, but running changelog in the cover letter to call out precisely what changed from the previous version(s) to help out reviewers. For example: v4: - Fixed up whitespace in patch N. - Added patch 4. ... v3: ... > +} > + > +STATIC ssize_t > +xfs_sysfs_object_store( > + struct kobject *kobject, > + struct attribute *attr, > + const char *buf, > + size_t count) > +{ > + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); > + struct kobj_type *ktype = get_ktype(kobject); > + > + if (ktype == &xfs_log_ktype) { > + struct xlog *log = to_xlog(kobject); > + return xfs_attr->store ? xfs_attr->store(buf, count, log) : 0; > + } > + else > + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; > +} > + > +static struct sysfs_ops xfs_sysfs_ops = { > + .show = xfs_sysfs_object_show, > + .store = xfs_sysfs_object_store, > +}; > + > #ifdef DEBUG > /* debug */ > > @@ -92,43 +139,14 @@ static struct attribute *xfs_dbg_attrs[] = { > NULL, > }; > > -STATIC ssize_t > -xfs_dbg_show( > - struct kobject *kobject, > - struct attribute *attr, > - char *buf) > -{ > - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); > - > - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; > -} > - > -STATIC ssize_t > -xfs_dbg_store( > - struct kobject *kobject, > - struct attribute *attr, > - const char *buf, > - size_t count) > -{ > - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); > - > - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; > -} > - > -static struct sysfs_ops xfs_dbg_ops = { > - .show = xfs_dbg_show, > - .store = xfs_dbg_store, > -}; > - > struct kobj_type xfs_dbg_ktype = { > .release = xfs_sysfs_release, > - .sysfs_ops = &xfs_dbg_ops, > + .sysfs_ops = &xfs_sysfs_ops, > .default_attrs = xfs_dbg_attrs, > }; > > #endif /* DEBUG */ > > - > /* stats */ > > STATIC ssize_t > @@ -166,37 +184,9 @@ static struct attribute *xfs_stats_attrs[] = { > NULL, > }; > > -STATIC ssize_t > -xfs_stats_show( > - struct kobject *kobject, > - struct attribute *attr, > - char *buf) > -{ > - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); > - > - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; > -} > - > -STATIC ssize_t > -xfs_stats_store( > - struct kobject *kobject, > - struct attribute *attr, > - const char *buf, > - size_t count) > -{ > - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); > - > - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; > -} > - > -static struct sysfs_ops xfs_stats_ops = { > - .show = xfs_stats_show, > - .store = xfs_stats_store, > -}; > - > struct kobj_type xfs_stats_ktype = { > .release = xfs_sysfs_release, > - .sysfs_ops = &xfs_stats_ops, > + .sysfs_ops = &xfs_sysfs_ops, > .default_attrs = xfs_stats_attrs, > }; > > @@ -270,45 +260,8 @@ static struct attribute *xfs_log_attrs[] = { > NULL, > }; > > -static inline struct xlog * > -to_xlog(struct kobject *kobject) > -{ > - struct xfs_kobj *kobj = to_kobj(kobject); > - return container_of(kobj, struct xlog, l_kobj); > -} > - > -STATIC ssize_t > -xfs_log_show( > - struct kobject *kobject, > - struct attribute *attr, > - char *buf) > -{ > - struct xlog *log = to_xlog(kobject); > - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); > - > - return xfs_attr->show ? xfs_attr->show(buf, log) : 0; > -} > - > -STATIC ssize_t > -xfs_log_store( > - struct kobject *kobject, > - struct attribute *attr, > - const char *buf, > - size_t count) > -{ > - struct xlog *log = to_xlog(kobject); > - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); > - > - return xfs_attr->store ? xfs_attr->store(buf, count, log) : 0; > -} > - > -static struct sysfs_ops xfs_log_ops = { > - .show = xfs_log_show, > - .store = xfs_log_store, > -}; > - > struct kobj_type xfs_log_ktype = { > .release = xfs_sysfs_release, > - .sysfs_ops = &xfs_log_ops, > + .sysfs_ops = &xfs_sysfs_ops, > .default_attrs = xfs_log_attrs, > }; > -- > 2.4.3 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From billodo@redhat.com Tue Sep 8 12:50:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 7CC257F37 for ; Tue, 8 Sep 2015 12:50:20 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 6894F304039 for ; Tue, 8 Sep 2015 10:50:20 -0700 (PDT) X-ASG-Debug-ID: 1441734618-04cbb005ea05770001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 5DT8imoMui1dRvxn (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 10:50:18 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 362BB2DD312 for ; Tue, 8 Sep 2015 17:50:18 +0000 (UTC) Received: from localhost.localdomain.com (vpn-57-55.rdu2.redhat.com [10.10.57.55]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88HoHBY022169 for ; Tue, 8 Sep 2015 13:50:17 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 1/4] xfs: create global stats and stats_clear in sysfs Date: Tue, 8 Sep 2015 12:49:51 -0500 X-ASG-Orig-Subj: [PATCH 1/4] xfs: create global stats and stats_clear in sysfs Message-Id: <1441734594-4175-2-git-send-email-billodo@redhat.com> In-Reply-To: <1441734594-4175-1-git-send-email-billodo@redhat.com> References: <1441734594-4175-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441734618 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Currently, xfs global stats are in procfs. This patch introduces (replicates) the global stats in sysfs. Additionally a stats_clear file is introduced in sysfs. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_stats.h | 2 ++ fs/xfs/xfs_super.c | 20 +++++++++---- fs/xfs/xfs_sysctl.c | 15 ++-------- fs/xfs/xfs_sysfs.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_sysfs.h | 1 + 6 files changed, 179 insertions(+), 17 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index f224038..6008e25 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -29,6 +29,89 @@ static int counter_val(int idx) return val; } +int xfs_stats_format(char *buf) +{ + int i, j; + int len = 0; + __uint64_t xs_xstrat_bytes = 0; + __uint64_t xs_write_bytes = 0; + __uint64_t xs_read_bytes = 0; + + static const struct xstats_entry { + char *desc; + int endpoint; + } xstats[] = { + { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, + { "abt", XFSSTAT_END_ALLOC_BTREE }, + { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, + { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, + { "dir", XFSSTAT_END_DIRECTORY_OPS }, + { "trans", XFSSTAT_END_TRANSACTIONS }, + { "ig", XFSSTAT_END_INODE_OPS }, + { "log", XFSSTAT_END_LOG_OPS }, + { "push_ail", XFSSTAT_END_TAIL_PUSHING }, + { "xstrat", XFSSTAT_END_WRITE_CONVERT }, + { "rw", XFSSTAT_END_READ_WRITE_OPS }, + { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, + { "icluster", XFSSTAT_END_INODE_CLUSTER }, + { "vnodes", XFSSTAT_END_VNODE_OPS }, + { "buf", XFSSTAT_END_BUF }, + { "abtb2", XFSSTAT_END_ABTB_V2 }, + { "abtc2", XFSSTAT_END_ABTC_V2 }, + { "bmbt2", XFSSTAT_END_BMBT_V2 }, + { "ibt2", XFSSTAT_END_IBT_V2 }, + { "fibt2", XFSSTAT_END_FIBT_V2 }, + /* we print both series of quota information together */ + { "qm", XFSSTAT_END_QM }, + }; + + /* Loop over all stats groups */ + + for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { + len += snprintf(buf + len, PATH_MAX - len, "%s", + xstats[i].desc); + /* inner loop does each group */ + for (; j < xstats[i].endpoint; j++) + len += snprintf(buf + len, PATH_MAX - len, " %u", + counter_val(j)); + len += snprintf(buf + len, PATH_MAX - len, "\n"); + } + /* extra precision counters */ + for_each_possible_cpu(i) { + xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; + xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; + xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; + } + + len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", + xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); + len += snprintf(buf+len, PATH_MAX-len, "debug %u\n", +#if defined(DEBUG) + 1); +#else + 0); +#endif + +return len; +} + +void xfs_stats_clearall(void) +{ + int c; + __uint32_t vn_active; + + xfs_notice(NULL, "Clearing xfsstats"); + for_each_possible_cpu(c) { + preempt_disable(); + /* save vn_active, it's a universal truth! */ + vn_active = per_cpu(xfsstats, c).vn_active; + memset(&per_cpu(xfsstats, c), 0, + sizeof(struct xfsstats)); + per_cpu(xfsstats, c).vn_active = vn_active; + preempt_enable(); + } +} + static int xfs_stat_proc_show(struct seq_file *m, void *v) { int i, j; diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index c8f238b..18807b5 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -18,6 +18,8 @@ #ifndef __XFS_STATS_H__ #define __XFS_STATS_H__ +int xfs_stats_format(char *buf); +void xfs_stats_clearall(void); #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 3bf503a..31ad281 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -61,6 +61,7 @@ static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; static struct kset *xfs_kset; /* top-level xfs sysfs dir */ +static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ #ifdef DEBUG static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ #endif @@ -1838,19 +1839,25 @@ init_xfs_fs(void) xfs_kset = kset_create_and_add("xfs", NULL, fs_kobj); if (!xfs_kset) { error = -ENOMEM; - goto out_sysctl_unregister;; + goto out_sysctl_unregister; } + xfs_stats_kobj.kobject.kset = xfs_kset; + error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, + "stats"); + if (error) + goto out_kset_unregister; + #ifdef DEBUG xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_kset_unregister; + goto out_remove_stats_kobj; #endif error = xfs_qm_init(); if (error) - goto out_remove_kobj; + goto out_remove_dbg_kobj; error = register_filesystem(&xfs_fs_type); if (error) @@ -1859,11 +1866,13 @@ init_xfs_fs(void) out_qm_exit: xfs_qm_exit(); - out_remove_kobj: + out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_kset_unregister: + out_remove_stats_kobj: #endif + xfs_sysfs_del(&xfs_stats_kobj); + out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: xfs_sysctl_unregister(); @@ -1889,6 +1898,7 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif + xfs_sysfs_del(&xfs_stats_kobj); kset_unregister(xfs_kset); xfs_sysctl_unregister(); xfs_cleanup_procfs(); diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c index a0c8067..5defabb 100644 --- a/fs/xfs/xfs_sysctl.c +++ b/fs/xfs/xfs_sysctl.c @@ -19,6 +19,7 @@ #include #include #include "xfs_error.h" +#include "xfs_stats.h" static struct ctl_table_header *xfs_table_header; @@ -31,22 +32,12 @@ xfs_stats_clear_proc_handler( size_t *lenp, loff_t *ppos) { - int c, ret, *valp = ctl->data; - __uint32_t vn_active; + int ret, *valp = ctl->data; ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); if (!ret && write && *valp) { - xfs_notice(NULL, "Clearing xfsstats"); - for_each_possible_cpu(c) { - preempt_disable(); - /* save vn_active, it's a universal truth! */ - vn_active = per_cpu(xfsstats, c).vn_active; - memset(&per_cpu(xfsstats, c), 0, - sizeof(struct xfsstats)); - per_cpu(xfsstats, c).vn_active = vn_active; - preempt_enable(); - } + xfs_stats_clearall(); xfs_stats_clear = 0; } diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index aa03670..a094e20 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -21,6 +21,7 @@ #include "xfs_log_format.h" #include "xfs_log.h" #include "xfs_log_priv.h" +#include "xfs_stats.h" struct xfs_sysfs_attr { struct attribute attr; @@ -38,6 +39,8 @@ to_attr(struct attribute *attr) static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RW(name) #define XFS_SYSFS_ATTR_RO(name) \ static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RO(name) +#define XFS_SYSFS_ATTR_WO(name) \ + static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_WO(name) #define ATTR_LIST(name) &xfs_sysfs_attr_##name.attr @@ -125,6 +128,78 @@ struct kobj_type xfs_dbg_ktype = { #endif /* DEBUG */ + +/* stats */ + +STATIC ssize_t +stats_show( + char *buf, + void *data) +{ + return xfs_stats_format(buf); +} +XFS_SYSFS_ATTR_RO(stats); + +STATIC ssize_t +stats_clear_store( + const char *buf, + size_t count, + void *data) +{ + int ret; + int val; + + ret = kstrtoint(buf, 0, &val); + if (ret) + return ret; + + if (val != 1) + return -EINVAL; + xfs_stats_clearall(); + return count; +} +XFS_SYSFS_ATTR_WO(stats_clear); + +static struct attribute *xfs_stats_attrs[] = { + ATTR_LIST(stats), + ATTR_LIST(stats_clear), + NULL, +}; + +STATIC ssize_t +xfs_stats_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; +} + +STATIC ssize_t +xfs_stats_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; +} + +static struct sysfs_ops xfs_stats_ops = { + .show = xfs_stats_show, + .store = xfs_stats_store, +}; + +struct kobj_type xfs_stats_ktype = { + .release = xfs_sysfs_release, + .sysfs_ops = &xfs_stats_ops, + .default_attrs = xfs_stats_attrs, +}; + /* xlog */ STATIC ssize_t diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h index 240eee3..be692e5 100644 --- a/fs/xfs/xfs_sysfs.h +++ b/fs/xfs/xfs_sysfs.h @@ -22,6 +22,7 @@ extern struct kobj_type xfs_mp_ktype; /* xfs_mount */ extern struct kobj_type xfs_dbg_ktype; /* debug */ extern struct kobj_type xfs_log_ktype; /* xlog */ +extern struct kobj_type xfs_stats_ktype; /* stats */ static inline struct xfs_kobj * to_kobj(struct kobject *kobject) -- 2.4.3 From billodo@redhat.com Tue Sep 8 12:50:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 7C6567F50 for ; Tue, 8 Sep 2015 12:50:22 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 12C6CAC005 for ; Tue, 8 Sep 2015 10:50:18 -0700 (PDT) X-ASG-Debug-ID: 1441734617-04bdf04db405d80001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id T8lcBjU7psPZdXiI (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 10:50:18 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id A4D2D8EA21 for ; Tue, 8 Sep 2015 17:50:17 +0000 (UTC) Received: from localhost.localdomain.com (vpn-57-55.rdu2.redhat.com [10.10.57.55]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88HoHBX022169 for ; Tue, 8 Sep 2015 13:50:17 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 0/4 V5] xfs: new global stats in sysfs Date: Tue, 8 Sep 2015 12:49:50 -0500 X-ASG-Orig-Subj: [PATCH 0/4 V5] xfs: new global stats in sysfs Message-Id: <1441734594-4175-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441734618 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi all- Here is another pass at the series to add new global stats to sysfs. ----------history--------------- V5: -optimization of sysfs_ops function. -style fixups V4: -whitespace fixup of patch 1 -add patch 4 (sysfs ops consolidation - dbg, stats, log) V3: -style fixups and removal of extraneous printk. V2: -style fixups. V1: -------------------------------- The series provides the beginnings of the infrastructure for per-fs stats (in addition to global accumulative stats). We already have per-fs information in /sys, so it makes sense to have per-fs stats there too. As a first step, moving existing global stats infrastructure to /sys will allow us to re-use that sysfs code for per-fs stats as well. Patch 1 handles the bring-up and tear down of xfs/stats directory structure in sysfs when an fs is mounted. The directory contains the stats file and the stats_clear file. The stats file contents mimic those of /proc/fs/xfs/stat. The stats_clear file is empty, and much like the current stat_clear command, handles the zeroing of the stats file when a "1" is echoed to the stats_clear file. Patch 2 creates the symlink for stats from procfs to sysfs. Patch 3 removes the now unused portions of procfs for stat. Patch 4 consolidates the sysfs ops for dbg, stats, log. Once again, comments and questions are welcome. Thanks- Bill From billodo@redhat.com Tue Sep 8 12:50:23 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 342DA7F50 for ; Tue, 8 Sep 2015 12:50:23 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id EB862304048 for ; Tue, 8 Sep 2015 10:50:19 -0700 (PDT) X-ASG-Debug-ID: 1441734618-04bdf04db505d90001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 3K6clvMKH7r8JcVq (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 10:50:19 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id B514BC0B988A for ; Tue, 8 Sep 2015 17:50:18 +0000 (UTC) Received: from localhost.localdomain.com (vpn-57-55.rdu2.redhat.com [10.10.57.55]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88HoHBZ022169 for ; Tue, 8 Sep 2015 13:50:18 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 2/4] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Date: Tue, 8 Sep 2015 12:49:52 -0500 X-ASG-Orig-Subj: [PATCH 2/4] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-Id: <1441734594-4175-3-git-send-email-billodo@redhat.com> In-Reply-To: <1441734594-4175-1-git-send-email-billodo@redhat.com> References: <1441734594-4175-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441734618 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 6008e25..a9f05de 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -244,9 +244,10 @@ xfs_init_procfs(void) if (!proc_mkdir("fs/xfs", NULL)) goto out; - if (!proc_create("fs/xfs/stat", 0, NULL, - &xfs_stat_proc_fops)) + if (!proc_symlink("fs/xfs/stat", NULL, + "/sys/fs/xfs/stats/stats")) goto out_remove_xfs_dir; + #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, &xqmstat_proc_fops)) -- 2.4.3 From billodo@redhat.com Tue Sep 8 12:50:25 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 9BAAE7F5D for ; Tue, 8 Sep 2015 12:50:25 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id E07FCAC005 for ; Tue, 8 Sep 2015 10:50:24 -0700 (PDT) X-ASG-Debug-ID: 1441734619-04cb6c355a05410001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id gKl9o5r5vqjkmskW (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 10:50:20 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 3EF51461D7 for ; Tue, 8 Sep 2015 17:50:19 +0000 (UTC) Received: from localhost.localdomain.com (vpn-57-55.rdu2.redhat.com [10.10.57.55]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88HoHBa022169 for ; Tue, 8 Sep 2015 13:50:18 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 3/4] xfs: remove unused procfs code Date: Tue, 8 Sep 2015 12:49:53 -0500 X-ASG-Orig-Subj: [PATCH 3/4] xfs: remove unused procfs code Message-Id: <1441734594-4175-4-git-send-email-billodo@redhat.com> In-Reply-To: <1441734594-4175-1-git-send-email-billodo@redhat.com> References: <1441734594-4175-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441734619 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch removes the now unused procfs code that was xfs stat specific. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 74 ------------------------------------------------------ 1 file changed, 74 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index a9f05de..05d5227 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -112,80 +112,6 @@ void xfs_stats_clearall(void) } } -static int xfs_stat_proc_show(struct seq_file *m, void *v) -{ - int i, j; - __uint64_t xs_xstrat_bytes = 0; - __uint64_t xs_write_bytes = 0; - __uint64_t xs_read_bytes = 0; - - static const struct xstats_entry { - char *desc; - int endpoint; - } xstats[] = { - { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, - { "abt", XFSSTAT_END_ALLOC_BTREE }, - { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, - { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, - { "dir", XFSSTAT_END_DIRECTORY_OPS }, - { "trans", XFSSTAT_END_TRANSACTIONS }, - { "ig", XFSSTAT_END_INODE_OPS }, - { "log", XFSSTAT_END_LOG_OPS }, - { "push_ail", XFSSTAT_END_TAIL_PUSHING }, - { "xstrat", XFSSTAT_END_WRITE_CONVERT }, - { "rw", XFSSTAT_END_READ_WRITE_OPS }, - { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, - { "icluster", XFSSTAT_END_INODE_CLUSTER }, - { "vnodes", XFSSTAT_END_VNODE_OPS }, - { "buf", XFSSTAT_END_BUF }, - { "abtb2", XFSSTAT_END_ABTB_V2 }, - { "abtc2", XFSSTAT_END_ABTC_V2 }, - { "bmbt2", XFSSTAT_END_BMBT_V2 }, - { "ibt2", XFSSTAT_END_IBT_V2 }, - { "fibt2", XFSSTAT_END_FIBT_V2 }, - /* we print both series of quota information together */ - { "qm", XFSSTAT_END_QM }, - }; - - /* Loop over all stats groups */ - for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { - seq_printf(m, "%s", xstats[i].desc); - /* inner loop does each group */ - for (; j < xstats[i].endpoint; j++) - seq_printf(m, " %u", counter_val(j)); - seq_putc(m, '\n'); - } - /* extra precision counters */ - for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; - } - - seq_printf(m, "xpc %Lu %Lu %Lu\n", - xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); - seq_printf(m, "debug %u\n", -#if defined(DEBUG) - 1); -#else - 0); -#endif - return 0; -} - -static int xfs_stat_proc_open(struct inode *inode, struct file *file) -{ - return single_open(file, xfs_stat_proc_show, NULL); -} - -static const struct file_operations xfs_stat_proc_fops = { - .owner = THIS_MODULE, - .open = xfs_stat_proc_open, - .read = seq_read, - .llseek = seq_lseek, - .release = single_release, -}; - /* legacy quota interfaces */ #ifdef CONFIG_XFS_QUOTA static int xqm_proc_show(struct seq_file *m, void *v) -- 2.4.3 From billodo@redhat.com Tue Sep 8 12:50:29 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 69A7B7F50 for ; Tue, 8 Sep 2015 12:50:29 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 31C5D8F8065 for ; Tue, 8 Sep 2015 10:50:26 -0700 (PDT) X-ASG-Debug-ID: 1441734619-04cb6c355b05420001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id A5XbyWHzx4y92TIj (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 10:50:20 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id C0F2E8E3E8 for ; Tue, 8 Sep 2015 17:50:19 +0000 (UTC) Received: from localhost.localdomain.com (vpn-57-55.rdu2.redhat.com [10.10.57.55]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t88HoHBb022169 for ; Tue, 8 Sep 2015 13:50:19 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 4/4] xfs: consolidate sysfs ops (dbg, stats, log) Date: Tue, 8 Sep 2015 12:49:54 -0500 X-ASG-Orig-Subj: [PATCH 4/4] xfs: consolidate sysfs ops (dbg, stats, log) Message-Id: <1441734594-4175-5-git-send-email-billodo@redhat.com> In-Reply-To: <1441734594-4175-1-git-send-email-billodo@redhat.com> References: <1441734594-4175-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441734620 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the series to move xfs global stats from procfs to sysfs, this patch consolidates the sysfs ops functions and removes redundancy. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 2 +- fs/xfs/xfs_sysfs.c | 144 +++++++++++++++++------------------------------------ 2 files changed, 48 insertions(+), 98 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 05d5227..dc6ca67 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -92,7 +92,7 @@ int xfs_stats_format(char *buf) 0); #endif -return len; + return len; } void xfs_stats_clearall(void) diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index a094e20..6fd597b 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -54,6 +54,50 @@ struct kobj_type xfs_mp_ktype = { .release = xfs_sysfs_release, }; +static inline struct xlog * +to_xlog(struct kobject *kobject) +{ + struct xfs_kobj *kobj = to_kobj(kobject); + + return container_of(kobj, struct xlog, l_kobj); +} + +STATIC ssize_t +xfs_sysfs_object_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + struct kobj_type *ktype = get_ktype(kobject); + void *data = NULL; + + if (ktype == &xfs_log_ktype) + data = to_xlog(kobject); + return xfs_attr->show ? xfs_attr->show(buf, data) : 0; +} + +STATIC ssize_t +xfs_sysfs_object_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + struct kobj_type *ktype = get_ktype(kobject); + void *data = NULL; + + if (ktype == &xfs_log_ktype) + data = to_xlog(kobject); + return xfs_attr->store ? xfs_attr->store(buf, count, data) : 0; +} + +static const struct sysfs_ops xfs_sysfs_ops = { + .show = xfs_sysfs_object_show, + .store = xfs_sysfs_object_store, +}; + #ifdef DEBUG /* debug */ @@ -92,43 +136,14 @@ static struct attribute *xfs_dbg_attrs[] = { NULL, }; -STATIC ssize_t -xfs_dbg_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; -} - -STATIC ssize_t -xfs_dbg_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; -} - -static struct sysfs_ops xfs_dbg_ops = { - .show = xfs_dbg_show, - .store = xfs_dbg_store, -}; - struct kobj_type xfs_dbg_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_dbg_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_dbg_attrs, }; #endif /* DEBUG */ - /* stats */ STATIC ssize_t @@ -166,37 +181,9 @@ static struct attribute *xfs_stats_attrs[] = { NULL, }; -STATIC ssize_t -xfs_stats_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; -} - -STATIC ssize_t -xfs_stats_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; -} - -static struct sysfs_ops xfs_stats_ops = { - .show = xfs_stats_show, - .store = xfs_stats_store, -}; - struct kobj_type xfs_stats_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_stats_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_stats_attrs, }; @@ -270,45 +257,8 @@ static struct attribute *xfs_log_attrs[] = { NULL, }; -static inline struct xlog * -to_xlog(struct kobject *kobject) -{ - struct xfs_kobj *kobj = to_kobj(kobject); - return container_of(kobj, struct xlog, l_kobj); -} - -STATIC ssize_t -xfs_log_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xlog *log = to_xlog(kobject); - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, log) : 0; -} - -STATIC ssize_t -xfs_log_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xlog *log = to_xlog(kobject); - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, log) : 0; -} - -static struct sysfs_ops xfs_log_ops = { - .show = xfs_log_show, - .store = xfs_log_store, -}; - struct kobj_type xfs_log_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_log_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_log_attrs, }; -- 2.4.3 From sandeen@redhat.com Tue Sep 8 14:49:14 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_FRT_PROFILE2 autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 044147F37 for ; Tue, 8 Sep 2015 14:49:14 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 84003AC00E for ; Tue, 8 Sep 2015 12:49:10 -0700 (PDT) X-ASG-Debug-ID: 1441741745-04cb6c355a083d0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id jtF5K6eV9Q24FZQf (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 08 Sep 2015 12:49:06 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 9FB7CC0B9890 for ; Tue, 8 Sep 2015 19:49:05 +0000 (UTC) Received: from Liberator.local (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 t88Jn26Y011197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Sep 2015 15:49:05 -0400 To: xfs-oss From: Eric Sandeen Subject: [PATCH] xfs: simplify /proc teardown & error handling Message-ID: <55EF3BAE.5010904@redhat.com> X-ASG-Orig-Subj: [PATCH] xfs: simplify /proc teardown & error handling Date: Tue, 8 Sep 2015 14:49:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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: 1441741746 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 remove_proc_subtree() was added in 3.9, and can be used to simplify our procfile creation error handling and cleanup, removing the nested gotos. It simply removes fs/xfs and everything created under it. Signed-off-by: Eric Sandeen --- This goes after Bill's patches, I just noticed it while reviewing them. diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 05d5227..009a860 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -168,41 +168,29 @@ int xfs_init_procfs(void) { if (!proc_mkdir("fs/xfs", NULL)) - goto out; + return -ENOMEM; if (!proc_symlink("fs/xfs/stat", NULL, "/sys/fs/xfs/stats/stats")) - goto out_remove_xfs_dir; + goto out; #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, &xqmstat_proc_fops)) - goto out_remove_stat_file; + goto out; if (!proc_create("fs/xfs/xqm", 0, NULL, &xqm_proc_fops)) - goto out_remove_xqmstat_file; + goto out; #endif return 0; -#ifdef CONFIG_XFS_QUOTA - out_remove_xqmstat_file: - remove_proc_entry("fs/xfs/xqmstat", NULL); - out_remove_stat_file: - remove_proc_entry("fs/xfs/stat", NULL); -#endif - out_remove_xfs_dir: - remove_proc_entry("fs/xfs", NULL); - out: +out: + remove_proc_subtree("fs/xfs", NULL); return -ENOMEM; } void xfs_cleanup_procfs(void) { -#ifdef CONFIG_XFS_QUOTA - remove_proc_entry("fs/xfs/xqm", NULL); - remove_proc_entry("fs/xfs/xqmstat", NULL); -#endif - remove_proc_entry("fs/xfs/stat", NULL); - remove_proc_entry("fs/xfs", NULL); + remove_proc_subtree("fs/xfs", NULL); } From david@fromorbit.com Tue Sep 8 16:06:52 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id BA7C17F37 for ; Tue, 8 Sep 2015 16:06:52 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id A97838F8033 for ; Tue, 8 Sep 2015 14:06:49 -0700 (PDT) X-ASG-Debug-ID: 1441746406-04cb6c355c0a810001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id m18S2g4T86RjA1xt for ; Tue, 08 Sep 2015 14:06:47 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BADgAZTe9VPOV8LHldgyOBPYJWg3yiTAabeQICAQECgThNAQEBAQEBBwEBAQFAAT+EJAEBBCcTHCMQCAMYCSUPBSUDBxoTiC3LZAELAR8ZhhOFQoUMB4QsAQSHMY4kjHeaeoI2HIFmLDOISQEBAQ Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 09 Sep 2015 06:36:44 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZZQ6G-0001jM-AS; Wed, 09 Sep 2015 07:06:44 +1000 Date: Wed, 9 Sep 2015 07:06:44 +1000 From: Dave Chinner To: Bill O'Donnell Cc: xfs@oss.sgi.com Subject: Re: [PATCH 4/4] xfs: consolidate sysfs ops (dbg, stats, log) Message-ID: <20150908210644.GK3902@dastard> X-ASG-Orig-Subj: Re: [PATCH 4/4] xfs: consolidate sysfs ops (dbg, stats, log) References: <1441734594-4175-1-git-send-email-billodo@redhat.com> <1441734594-4175-5-git-send-email-billodo@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441734594-4175-5-git-send-email-billodo@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1441746406 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22347 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 08, 2015 at 12:49:54PM -0500, Bill O'Donnell wrote: > As a part of the series to move xfs global stats from procfs to sysfs, > this patch consolidates the sysfs ops functions and removes redundancy. > > Signed-off-by: Bill O'Donnell > --- > fs/xfs/xfs_stats.c | 2 +- > fs/xfs/xfs_sysfs.c | 144 +++++++++++++++++------------------------------------ > 2 files changed, 48 insertions(+), 98 deletions(-) > > diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > index 05d5227..dc6ca67 100644 > --- a/fs/xfs/xfs_stats.c > +++ b/fs/xfs/xfs_stats.c > @@ -92,7 +92,7 @@ int xfs_stats_format(char *buf) > 0); > #endif > > -return len; > + return len; > } > > void xfs_stats_clearall(void) > diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c > index a094e20..6fd597b 100644 > --- a/fs/xfs/xfs_sysfs.c > +++ b/fs/xfs/xfs_sysfs.c > @@ -54,6 +54,50 @@ struct kobj_type xfs_mp_ktype = { > .release = xfs_sysfs_release, > }; > > +static inline struct xlog * > +to_xlog(struct kobject *kobject) > +{ > + struct xfs_kobj *kobj = to_kobj(kobject); > + > + return container_of(kobj, struct xlog, l_kobj); > +} > + > +STATIC ssize_t > +xfs_sysfs_object_show( > + struct kobject *kobject, > + struct attribute *attr, > + char *buf) > +{ > + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); > + struct kobj_type *ktype = get_ktype(kobject); > + void *data = NULL; > + > + if (ktype == &xfs_log_ktype) > + data = to_xlog(kobject); Move the to_xlog(kobject) to the relevant ->show/->store operations and just pass the kobject to them. Otherwise we'll end up with a lot of non-generic functionality in these functions. Cheers, Dave. -- Dave Chinner david@fromorbit.com From austin@peloton-tech.com Wed Sep 9 01:54:32 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 803D77F37 for ; Wed, 9 Sep 2015 01:54:32 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 42358304032 for ; Tue, 8 Sep 2015 23:54:29 -0700 (PDT) X-ASG-Debug-ID: 1441781666-04bdf04db617f50001-NocioJ Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by cuda.sgi.com with ESMTP id GcsSkU5SUT762dcm (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 08 Sep 2015 23:54:27 -0700 (PDT) X-Barracuda-Envelope-From: austin@peloton-tech.com X-Barracuda-Apparent-Source-IP: 209.85.192.41 Received: by qgev79 with SMTP id v79so526286qge.0 for ; Tue, 08 Sep 2015 23:54:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=mKPyE1xe9+HRvQluEvPAVmTVo+KTYRYBQWY1X1MJgzU=; b=iA11+TQ3NY8oawgXY5YC3++l32KmzvdygrcamEfZzP1dmVaSoLMcZwO3tBF4DgDg/I FtKltONrGcowSpbIyNzUsuj3wMmFbyU9+O9c77b99FxoELXKBOiE1LpydGwHAsuvEYXY 4xIc1HMKF3gad1QWrIWLCKGfTGIchfjvbh3Q82tH9BBL1f06gIyz6y2VKe0MA0oVDvFo MCiTsyy3dqPb8AgFHrCeXvIBKXENdtpihMsjr0CctczDB1x40h6CSjBt6KDTBP0g0Z7A d8kbHHTtkTr4yKG83SEFrEGE5wHhp2XLMOfzbLuR71KCh3E+vW9uc7PDzk70O8PEFAQT WHQg== X-Gm-Message-State: ALoCoQn0uPoMtEewRlyUHYFn+Y2onjPUxFyzjE0xnNNFaGB+3d5lmoCYatDN/FuaBaeJTjvLsm/v X-Received: by 10.140.238.198 with SMTP id j189mr44697986qhc.63.1441781666635; Tue, 08 Sep 2015 23:54:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.21.39 with HTTP; Tue, 8 Sep 2015 23:54:07 -0700 (PDT) From: Austin Schuh Date: Tue, 8 Sep 2015 23:54:07 -0700 Message-ID: Subject: [RT XFS] BUG from lockdep in xfs To: rt-users , xfs , Philipp Schrader , Brian Silverman , Dave Chinner X-ASG-Orig-Subj: [RT XFS] BUG from lockdep in xfs Content-Type: text/plain; charset=UTF-8 X-Barracuda-Connect: mail-qg0-f41.google.com[209.85.192.41] X-Barracuda-Start-Time: 1441781667 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22364 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- I'm running xfstests and got the following BUG with lockdep enabled. I'm running the 4.1.6-rt5 kernel from TI's tree on a TI ARM chip. Any ideas on what could be causing it, or if it is a real problem? I see some patches in Dave's latest 4.3 pull request that discuss lockdep. Are there any ones there that are worth backporting to my 4.1.6 kernel? [ 4349.692989] run fstests generic/078 at 2015-09-09 04:58:56 [ 4357.394974] BUG: looking up invalid subclass: 8 [ 4357.394979] turning off the locking correctness validator. [ 4357.394989] CPU: 0 PID: 22963 Comm: renameat2 Not tainted 4.1.6-rt5+ #9 [ 4357.394993] Hardware name: Generic DRA74X (Flattened Device Tree) [ 4357.395012] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 4357.395026] [] (show_stack) from [] (dump_stack+0x84/0xa0) [ 4357.395038] [] (dump_stack) from [] (__lock_acquire+0x694/0x1ec0) [ 4357.395046] [] (__lock_acquire) from [] (lock_acquire+0x10c/0x354) [ 4357.395055] [] (lock_acquire) from [] (rt_down_write_nested+0x3c/0x4c) [ 4357.395069] [] (rt_down_write_nested) from [] (xfs_ilock+0x110/0x328) [ 4357.395080] [] (xfs_ilock) from [] (xfs_lock_inodes+0x80/0x1b0) [ 4357.395088] [] (xfs_lock_inodes) from [] (xfs_rename+0x214/0xd24) [ 4357.395097] [] (xfs_rename) from [] (xfs_vn_rename+0x94/0xa8) [ 4357.395110] [] (xfs_vn_rename) from [] (vfs_rename+0x5c0/0x870) [ 4357.395119] [] (vfs_rename) from [] (SyS_renameat2+0x458/0x48c) [ 4357.395130] [] (SyS_renameat2) from [] (ret_fast_syscall+0x0/0x54) Thanks! Austin From jtulak@redhat.com Wed Sep 9 05:11:33 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 149DE7F37 for ; Wed, 9 Sep 2015 05:11:33 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 94BC5AC003 for ; Wed, 9 Sep 2015 03:11:29 -0700 (PDT) X-ASG-Debug-ID: 1441793487-04cb6c355d1b6a0001-NocioJ Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) by cuda.sgi.com with ESMTP id PCfU2woegVu48jGe (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 09 Sep 2015 03:11:27 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-RBL-Trusted-Forwarder: 209.85.213.175 Received: by igbni9 with SMTP id ni9so10379887igb.0 for ; Wed, 09 Sep 2015 03:11:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/SUFoZwPgqgG7OUe6euxnNxdy1cYTb2W0bQXXbJhGlU=; b=KFBlyiKI93dqt9sSmDptn8TsYZMycYj/dB09HM8xYwRX+an36ARYUoBfsbDKs32uyS FOJt88yKtP3ekpeSMieCn/e62zmhIuB4gfgUOGHUoAmfX6IWz+sgu1a+Pe3PbKnzghAd 51cQFqhtPjbNBnKW6O5WaA8NERWaPk6vdgJcU6OQjSIuInJZqbuTBNz6DHwgefu8q8eu he/8dq9YM54hBApI3NLXC4BYcJwG0UqKkgzPtwgf5pfQZ7iWvdE5hTWHYnC/cVddwHpM KVqNTiCJoHox4IYCboYP27vnPrjSdoX6FSMeNmSojs4gqd8BoIcwPfAlLpLmFLt3Z6kZ bI3A== X-Gm-Message-State: ALoCoQmyDIqJ/+UTylCLSQO1dY0VA951bOyPYkhvCaOiA+EzjnCcNEYqguq8Vot0BU84gZc5HG9v X-Received: by 10.50.78.69 with SMTP id z5mr30380723igw.19.1441793487402; Wed, 09 Sep 2015 03:11:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Wed, 9 Sep 2015 03:11:08 -0700 (PDT) In-Reply-To: <1441276784-23701-1-git-send-email-jtulak@redhat.com> References: <1440590555-20463-7-git-send-email-jtulak@redhat.com> <1441276784-23701-1-git-send-email-jtulak@redhat.com> From: Jan Tulak Date: Wed, 9 Sep 2015 12:11:08 +0200 Message-ID: Subject: Re: [PATCH v2 07/11] xfsprogs: change nftw64 to nftw To: xfs-oss X-ASG-Orig-Subj: Re: [PATCH v2 07/11] xfsprogs: change nftw64 to nftw Cc: Christoph Hellwig , Jan Tulak Content-Type: multipart/alternative; boundary=089e01184e64a8228d051f4db4ee X-Barracuda-Connect: mail-ig0-f175.google.com[209.85.213.175] X-Barracuda-Start-Time: 1441793487 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22367 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --089e01184e64a8228d051f4db4ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > --- a/estimate/xfs_estimate.c > +++ b/estimate/xfs_estimate.c > @@ -168,7 +168,7 @@ main(int argc, char **argv) > ndirs=3D0LL; /* number of directories */ > nspecial=3D0LL; /* number of special files */ > > - nftw64(argv[optind], ffn, 40, FTW_PHYS | FTW_MOUNT); > + nftw(argv[optind], ffn, 40, FTW_PHYS | FTW_MOUNT); > > if (__debug) { > printf(_("dirsize=3D%llu\n"), dirsize); > -- > 2.4.5 > > =E2=80=8BNow I noticed this causes a warning: xfs_estimate.c:171:3: warning: passing argument 2 of =E2=80=98nftw=E2=80=99= from incompatible pointer type >From ftw.h, the difference is in __nftw_func_t and __nftw64_func_t as a second argument. However, what we pass in the code is " int =E2=80=8B =E2=80=8B ffn( =E2=80=8B..., struct stat64 *stb, ...)". =E2=80=8BIf I change this to struc= t stat, it works and xfstests -g quick gives the same result as with 64bit variant. So I'm sending an updated patch. Cheers, Jan --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --089e01184e64a8228d051f4db4ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


--- a/estimate/xfs_estimate.c
+++ b/estimate/xfs_estimate.c
@@ -168,7 +168,7 @@ main(int argc, char **argv)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ndirs=3D0LL;=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* number of directories */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nspecial=3D0LL;=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* number of special files */

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nftw64(argv[optind]= , ffn, 40, FTW_PHYS | FTW_MOUNT);
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nftw(argv[optind], = ffn, 40, FTW_PHYS | FTW_MOUNT);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (__debug) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 printf(_("dirsize=3D%llu\n"), dirsize);
--
2.4.5

=C2=A0
=E2= =80=8BNow I noticed this causes a warning:
xfs_estimate.c:171:3: warning: passing argument 2 of =E2=80=98nftw= =E2=80=99 from incompatible pointer type

From ftw.h, the differenc= e is in=C2=A0__nftw_func_t and=C2=A0__nftw64_func_t as a second argument. H= owever, what we pass in the code is "
int
=E2=80=8B =E2=80=8B
ffn(
=E2= =80=8B..., struct stat64 *stb, ...)". =E2=80=8BIf I change this to str= uct stat, it works and xfstests -g quick gives the same result as with 64bi= t variant. So I'm sending an updated patch.

Cheers,
Jan
<= br>


<= /div>

--
Jan Tulak
jtulak@redhat.com=C2=A0/ jan@tulak.me
--089e01184e64a8228d051f4db4ee-- From jtulak@redhat.com Wed Sep 9 05:14:28 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id B8ECA7F37 for ; Wed, 9 Sep 2015 05:14:28 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 45DC1AC003 for ; Wed, 9 Sep 2015 03:14:28 -0700 (PDT) X-ASG-Debug-ID: 1441793666-04cb6c355c1b7a0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id SLYaw0hmdzNl89ZS (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 09 Sep 2015 03:14:27 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 79407C0BB242; Wed, 9 Sep 2015 10:14:26 +0000 (UTC) Received: from localhost.localdomain (vpn1-5-160.ams2.redhat.com [10.36.5.160]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t89AEOVo027670; Wed, 9 Sep 2015 06:14:25 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: hch@infradead.org, Jan Tulak Subject: [PATCH v3 07/11] xfsprogs: change nftw64 to nftw Date: Wed, 9 Sep 2015 12:14:16 +0200 X-ASG-Orig-Subj: [PATCH v3 07/11] xfsprogs: change nftw64 to nftw Message-Id: <1441793656-20260-1-git-send-email-jtulak@redhat.com> In-Reply-To: <1441276784-23701-1-git-send-email-jtulak@redhat.com> References: <1441276784-23701-1-git-send-email-jtulak@redhat.com> 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: 1441793667 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Changelog: - changed ffn argument from stat64 to stat - Subject was "add nftw64 translation for OS X" - Changed from #define to renaming There is only one usage of nftw64 in entire xfsprogs, but multiple usages of nftw. It seems the 64 variant has no reason, and causes difficulties with some other platforms which has only nftw call. Signed-off-by: Jan Tulak --- estimate/xfs_estimate.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/estimate/xfs_estimate.c b/estimate/xfs_estimate.c index 65b7168..323137c 100644 --- a/estimate/xfs_estimate.c +++ b/estimate/xfs_estimate.c @@ -45,7 +45,7 @@ cvtnum(char *s) return 0LL; } -int ffn(const char *, const struct stat64 *, int, struct FTW *); +int ffn(const char *, const struct stat *, int, struct FTW *); #define BLOCKSIZE 4096 #define INODESIZE 256 @@ -168,7 +168,7 @@ main(int argc, char **argv) ndirs=0LL; /* number of directories */ nspecial=0LL; /* number of special files */ - nftw64(argv[optind], ffn, 40, FTW_PHYS | FTW_MOUNT); + nftw(argv[optind], ffn, 40, FTW_PHYS | FTW_MOUNT); if (__debug) { printf(_("dirsize=%llu\n"), dirsize); @@ -214,7 +214,7 @@ main(int argc, char **argv) } int -ffn(const char *path, const struct stat64 *stb, int flags, struct FTW *f) +ffn(const char *path, const struct stat *stb, int flags, struct FTW *f) { /* cases are in most-encountered to least-encountered order */ dirsize+=PERDIRENTRY+strlen(path); -- 2.4.5 From bfoster@redhat.com Wed Sep 9 06:44:58 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 833D07F37 for ; Wed, 9 Sep 2015 06:44:58 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 115F5AC002 for ; Wed, 9 Sep 2015 04:44:54 -0700 (PDT) X-ASG-Debug-ID: 1441799093-04cbb005ea1e5b0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 0CxOXaaTfwb5yWbb (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 09 Sep 2015 04:44:53 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 097DA2BA10C; Wed, 9 Sep 2015 11:44:53 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t89Biqhi002718; Wed, 9 Sep 2015 07:44:52 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 8B6751236D9; Wed, 9 Sep 2015 07:44:51 -0400 (EDT) Date: Wed, 9 Sep 2015 07:44:51 -0400 From: Brian Foster To: Austin Schuh Cc: rt-users , xfs , Philipp Schrader , Brian Silverman , Dave Chinner Subject: Re: [RT XFS] BUG from lockdep in xfs Message-ID: <20150909114451.GA30015@bfoster.bfoster> X-ASG-Orig-Subj: Re: [RT XFS] BUG from lockdep in xfs References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441799093 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 08, 2015 at 11:54:07PM -0700, Austin Schuh wrote: > I'm running xfstests and got the following BUG with lockdep enabled. > I'm running the 4.1.6-rt5 kernel from TI's tree on a TI ARM chip. > > Any ideas on what could be causing it, or if it is a real problem? > > I see some patches in Dave's latest 4.3 pull request that discuss > lockdep. Are there any ones there that are worth backporting to my > 4.1.6 kernel? > I suspect Dave's recent rework of the lockdep namespace bits is what you want: 0952c818 xfs: clean up inode lockdep annotations Note that there are a few follow on patches as well to clean up directory locking and some kconfig related warnings and such. Brian > [ 4349.692989] run fstests generic/078 at 2015-09-09 04:58:56 > [ 4357.394974] BUG: looking up invalid subclass: 8 > [ 4357.394979] turning off the locking correctness validator. > [ 4357.394989] CPU: 0 PID: 22963 Comm: renameat2 Not tainted 4.1.6-rt5+ #9 > [ 4357.394993] Hardware name: Generic DRA74X (Flattened Device Tree) > [ 4357.395012] [] (unwind_backtrace) from [] > (show_stack+0x20/0x24) > [ 4357.395026] [] (show_stack) from [] > (dump_stack+0x84/0xa0) > [ 4357.395038] [] (dump_stack) from [] > (__lock_acquire+0x694/0x1ec0) > [ 4357.395046] [] (__lock_acquire) from [] > (lock_acquire+0x10c/0x354) > [ 4357.395055] [] (lock_acquire) from [] > (rt_down_write_nested+0x3c/0x4c) > [ 4357.395069] [] (rt_down_write_nested) from [] > (xfs_ilock+0x110/0x328) > [ 4357.395080] [] (xfs_ilock) from [] > (xfs_lock_inodes+0x80/0x1b0) > [ 4357.395088] [] (xfs_lock_inodes) from [] > (xfs_rename+0x214/0xd24) > [ 4357.395097] [] (xfs_rename) from [] > (xfs_vn_rename+0x94/0xa8) > [ 4357.395110] [] (xfs_vn_rename) from [] > (vfs_rename+0x5c0/0x870) > [ 4357.395119] [] (vfs_rename) from [] > (SyS_renameat2+0x458/0x48c) > [ 4357.395130] [] (SyS_renameat2) from [] > (ret_fast_syscall+0x0/0x54) > > Thanks! > Austin > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Wed Sep 9 06:49:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_FRT_PROFILE2 autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 5ED7C7F37 for ; Wed, 9 Sep 2015 06:49:22 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 406D58F8052 for ; Wed, 9 Sep 2015 04:49:19 -0700 (PDT) X-ASG-Debug-ID: 1441799357-04cb6c355d1dc10001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id JIbDRCcCGDtZCrUz (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 09 Sep 2015 04:49:18 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 79E0F91DAC for ; Wed, 9 Sep 2015 11:49:17 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t89BnHx6030111; Wed, 9 Sep 2015 07:49:17 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 4A7FE1236D9; Wed, 9 Sep 2015 07:49:16 -0400 (EDT) Date: Wed, 9 Sep 2015 07:49:16 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs-oss Subject: Re: [PATCH] xfs: simplify /proc teardown & error handling Message-ID: <20150909114915.GB30015@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH] xfs: simplify /proc teardown & error handling References: <55EF3BAE.5010904@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55EF3BAE.5010904@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1441799358 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 08, 2015 at 02:49:02PM -0500, Eric Sandeen wrote: > remove_proc_subtree() was added in 3.9, and can be > used to simplify our procfile creation error handling > and cleanup, removing the nested gotos. It simply > removes fs/xfs and everything created under it. > > Signed-off-by: Eric Sandeen > --- Reviewed-by: Brian Foster > > This goes after Bill's patches, I just noticed it > while reviewing them. > > diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > index 05d5227..009a860 100644 > --- a/fs/xfs/xfs_stats.c > +++ b/fs/xfs/xfs_stats.c > @@ -168,41 +168,29 @@ int > xfs_init_procfs(void) > { > if (!proc_mkdir("fs/xfs", NULL)) > - goto out; > + return -ENOMEM; > > if (!proc_symlink("fs/xfs/stat", NULL, > "/sys/fs/xfs/stats/stats")) > - goto out_remove_xfs_dir; > + goto out; > > #ifdef CONFIG_XFS_QUOTA > if (!proc_create("fs/xfs/xqmstat", 0, NULL, > &xqmstat_proc_fops)) > - goto out_remove_stat_file; > + goto out; > if (!proc_create("fs/xfs/xqm", 0, NULL, > &xqm_proc_fops)) > - goto out_remove_xqmstat_file; > + goto out; > #endif > return 0; > > -#ifdef CONFIG_XFS_QUOTA > - out_remove_xqmstat_file: > - remove_proc_entry("fs/xfs/xqmstat", NULL); > - out_remove_stat_file: > - remove_proc_entry("fs/xfs/stat", NULL); > -#endif > - out_remove_xfs_dir: > - remove_proc_entry("fs/xfs", NULL); > - out: > +out: > + remove_proc_subtree("fs/xfs", NULL); > return -ENOMEM; > } > > void > xfs_cleanup_procfs(void) > { > -#ifdef CONFIG_XFS_QUOTA > - remove_proc_entry("fs/xfs/xqm", NULL); > - remove_proc_entry("fs/xfs/xqmstat", NULL); > -#endif > - remove_proc_entry("fs/xfs/stat", NULL); > - remove_proc_entry("fs/xfs", NULL); > + remove_proc_subtree("fs/xfs", NULL); > } > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From jtulak@redhat.com Wed Sep 9 07:36:21 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 92E6F7F37 for ; Wed, 9 Sep 2015 07:36:21 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 82CD18F8040 for ; Wed, 9 Sep 2015 05:36:18 -0700 (PDT) X-ASG-Debug-ID: 1441802174-04cb6c355b1f170001-NocioJ Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by cuda.sgi.com with ESMTP id bdTlc50tJ5nKNMPf (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 09 Sep 2015 05:36:14 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-RBL-Trusted-Forwarder: 209.85.223.170 Received: by iofh134 with SMTP id h134so20016378iof.0 for ; Wed, 09 Sep 2015 05:36:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=gBE+d8KUQlZsNxP/R5g2p37rOtngo8qi7i9+qG9vopQ=; b=lgR4uKLOCgInieYclIekobq0sSA4RBya8Ulz160V8rs61t3KPf8JFY/n0ZZQojHZgt we+PacBQKqS0AO/OBjeFaHbia36QogdCh7ldzMtgvf1vUzwHUXuN5uGml6/+9g4aZb/D vCxs73WOWYrtjb5sv4o9kpjmH3I1+FDDqX5Oa2H9sABbJyPw0aRde4l0++iew7IQ+8lV xeWc4NAKqlpBmRmgCbaGgrbZHHOl4TalVSvD7+W+cmL6yFWvSRvCB224kfZ1OOXAp2wh kpMHKW2JTAyDx0rYcTTaR1tatHDivNaA2qpcBYpzRkkYDQ34vTWQcQ0icyfe18V+Fh7X qsNA== X-Gm-Message-State: ALoCoQmFKsYynzXzCtOyWQVMgqjqH+8VIrjmKJbYuavxC6g7v0Ug98SEdUXW2Ul7NjcQ7wXVu7Zu X-Received: by 10.107.133.151 with SMTP id p23mr56549769ioi.71.1441802173976; Wed, 09 Sep 2015 05:36:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Wed, 9 Sep 2015 05:35:54 -0700 (PDT) From: Jan Tulak Date: Wed, 9 Sep 2015 14:35:54 +0200 Message-ID: Subject: xfsprogs - debug build with -O0 To: xfs-oss X-ASG-Orig-Subj: xfsprogs - debug build with -O0 Content-Type: multipart/alternative; boundary=001a113ec2ac6ab04e051f4fba0e X-Barracuda-Connect: mail-io0-f170.google.com[209.85.223.170] X-Barracuda-Start-Time: 1441802174 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22370 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --001a113ec2ac6ab04e051f4fba0e Content-Type: text/plain; charset=UTF-8 Hi all, Is there a way how to disable compiler optimisation in xfsprogs? It should be done with setting env variable OPTIMIZER='-O0', however, even though this is mentioned on few places in xfsprogs, it doesn't work and the configure file always use "-O2" from autogenerated m4/libtool.m4. Other environment variables works as expected. So far, when in need of debugging, I have been manually replacing -O2 with -O0 in configure, but this isn't a good solution. So, is there another way, or it is just broken? I find it strange that nobody would mind messed GDB outputs... :-) Cheers, Jan -- Jan Tulak jtulak@redhat.com / jan@tulak.me --001a113ec2ac6ab04e051f4fba0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Is there a way how to disa= ble compiler optimisation in xfsprogs? It should be done with setting env v= ariable OPTIMIZER=3D'-O0', however, even though this is mentioned o= n few places in xfsprogs, it doesn't work and the configure file always= use "-O2" from autogenerated m4/libtool.m4. Other environment va= riables works as expected.

So far, when in need of deb= ugging, I have been manually replacing -O2 with -O0 in configure, but this = isn't a good solution. So, is there another way, or it is just broken? = I find it strange that nobody would mind messed GDB outputs... :-)
=
Cheers,
Jan

--
--001a113ec2ac6ab04e051f4fba0e-- From 6399cf63.1dw1.1gPf.gQ.1yGAmynPE9+xfs=oss.sgi.com@bnc3.mailjet.com Wed Sep 9 07:50:13 2015 Return-Path: <6399cf63.1dw1.1gPf.gQ.1yGAmynPE9+xfs=oss.sgi.com@bnc3.mailjet.com> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 104417F37 for ; Wed, 9 Sep 2015 07:50:13 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id D8FF0304051 for ; Wed, 9 Sep 2015 05:50:12 -0700 (PDT) X-ASG-Debug-ID: 1441803007-04cbb005e9205f0001-NocioJ Received: from o142.p9.mailjet.com (o142.p9.mailjet.com [87.253.234.142]) by cuda.sgi.com with ESMTP id OVzWIzQPuPYu2yrl (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 09 Sep 2015 05:50:07 -0700 (PDT) X-Barracuda-Envelope-From: 6399cf63.1dw1.1gPf.gQ.1yGAmynPE9+xfs=oss.sgi.com@bnc3.mailjet.com X-Barracuda-Apparent-Source-IP: 87.253.234.142 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; q=dns/txt; d=bnc3.mailjet.com; i=marketing=3Dministryofmagicnam.com@bnc3.mailjet.com; s=mailjet; h=message-id:mime-version:from:reply-to:to:subject:date:list-id:list-unsubscribe: precedence:x-csa-complaints:content-type; bh=V41u1Qbx+3Hzr7Bn9+bsJ9gZMh0=; b= DPaOc8XKbaRZmDlqfrTo8qMj9fRArdNG+Bst6M+vGAZhMplnEPD6nnYuUOIy bmC/LwehRlcKMR9PYGPXkSiAvE17h0wenn3WuPmC+WdE3whmzSH/DUIojbIv ohPG6m6/iB9zS2bpLUDdFWuiFe99sb96r5JnEN6fcQrUzOxD5VU= Message-Id: <6399cf63.1dw1.1gPf.gQ.1yGAmynPE9@mailjet.com> MIME-Version: 1.0 From: Ministry of Magic Reply-To: marketing@ministryofmagicnam.com To: xfs@oss.sgi.com Subject: Moving Forward Date: Wed, 9 Sep 2015 12:50:06 +0000 X-ASG-Orig-Subj: Moving Forward List-Id: List-Unsubscribe: Precedence: bulk X-CSA-Complaints: whitelist-complaints@eco.de Content-Type: multipart/alternative; boundary="=-6/dborFoAy414kEAym4H" X-Barracuda-Connect: o142.p9.mailjet.com[87.253.234.142] X-Barracuda-Start-Time: 1441803007 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-BRTS-Evidence: ministryofmagicnam.com X-Barracuda-Spam-Score: 1.00 X-Barracuda-Spam-Status: No, SCORE=1.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC7_SA_HREF_WWW_MISMATCH, BSF_URI_OBF_TLD, DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22370 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.80 BSF_SC7_SA_HREF_WWW_MISMATCH BODY: Custom Phishing Mismatch -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.20 BSF_URI_OBF_TLD Custom Rule BSF_URI_OBF_TLD --=-6/dborFoAy414kEAym4H Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ministry of Magic can help YOUR business move forward. View online version = [http://omi3.mjt.lu/nl2/omi3/143uj.html?a=3D1yGAmynPE9&b=3D6399cf63&c=3Domi= 3&d=3D4df9fd42&e=3D44ac87c6&email=3Dxfs@oss.sgi.com][http://omi3.mjt.lu/img= /omi3/b/143um/26r.jpeg]For your business to be taken seriously, you need to= maintain a respectable presence on all platforms - especially on the internet. The image you portr= ay to your potential clients is what creates the perception of value and professionalism. Using generic email addresses and avoiding a web presence, will not help yo= ur business to move forward. Ministry of Magic - an established Namibian design company - can help your business move forward by creating a public and client perceptions which wil= l drive sales and ensure future growth. [http://omi3.mjt.lu/img/omi3/b/143um/2h3.jpeg]Web Domain Registration Ministry of Magic can register your domain on the internet. Our superior ho= sting packages are not only affordable, but offers REAL value. Our hosting packag= es includes all the email accounts your business might need. Will you ever be taken seriously by sending your business correspondence fr= om a @yahoo or a @Hotmail account? Register your domain NOW, and send your correspondence from you@yourbusines= sname.com [you@yourbusinessname.com] ! [http://omi3.mjt.lu/img/omi3/b/143um/2h5.jpeg]Website Design Clients will research your business before they decide to do business with = you - long before they pick up the phone. A professionally designed website which is informative, easy to naviagte an= d that tells clients what you do and the manner in which you do it, is of paramount importance. Ministry of Magic can design your website, which will be accessible from computers world wide, as well as from mobile phones. [http://omi3.mjt.lu/img/omi3/b/143um/2hh.jpeg]Email Marketing Ministry of Magic can help you reach over 50,000 potential clients right on their desktops by using our innovative email marketing campaigns. Our email marketing campaigns have proven not only cost effective, but successful over and over again. How will your clients know about your products and services if you do not t= ell them? [http://omi3.mjt.lu/img/omi3/b/143um/2hn.jpeg][http://omi3.mjt.lu/img/omi3/= b/143um/26o.jpeg]www.ministryofmagicnam.com [http://www.ministryofmagicnam.= com] e: henri@ministryofmagicnam.com e: md@ministryofmagicnam.com This e-mail has been sent to xfs@oss.sgi.com, click here to unsubscribe [[[= UNSUB_LINK_EN]]] . 5 Orion Park, Ludwigsdorf 0000 Windhoek NA= --=-6/dborFoAy414kEAym4H Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Moving Forward
Ministry of Magic can help YOUR business move forward.
=
View online version
=
<= /tr>
=
=C2=A0
3D""
=C2=A0
<= /tr>
=
=C2=A0

For your business to be taken seriously, you= need to maintain a respectable presence on all platforms - especially on t= he internet. The image you portray to your potential clients is what create= s the perception of value and professionalism.

Using generic email a= ddresses and avoiding a web presence, will not help your business to move f= orward.

Ministry of Magic - an established Namibian design company -&= nbsp;can help your business move forward by creating a public and client pe= rceptions which will drive sales and ensure future growth.

=C2= =A0
<= /tr>
3D""

Web Domain Registration

Ministry of Magic can register your domain on the internet. = Our superior hosting packages are not only affordable, but offers REAL valu= e. Our hosting packages includes all the email accounts your business might= need. 

Will you ever be taken seriously by sending your busine= ss correspondence from a @yahoo or a @Hotmail account?

Register your = domain NOW, and send your correspondence from you@yourbusinessname.com!

=
=
3D""

= Website Design 

Clients will research your busines= s before they decide to do business with you - long before they pick up the= phone.

A professionally designed website which is informative, easy= to naviagte and that tells clients what you do and the manner in which you= do it, is of paramount importance.

Ministry of Magic can design you= r website, which will be accessible from computers world wide, as well as f= rom mobile phones.

<= /tr>
<= td data-legacy-align=3D"center" class=3D"toolContentInner" style=3D"border:= 0;border-spacing:0px;vertical-align:top;" align=3D"center">
3D""
<= /td>
=

Email Marketing

Ministry of Magic can help you reach over 50,000 potential clie= nts right on their desktops by using our innovative email marketing ca= mpaigns.

Our email marketing campaigns have proven not only cost eff= ective, but successful over and over again.

How will your clients kn= ow about your products and services if you do not tell them?

<= tr>
<= tbody>
<= table class=3D"section" width=3D"100%" cellpadding=3D"0" cellspacing=3D"0" = style=3D"font-family:Ubuntu, Helvetica, Arial, sans-serif;border-collapse:c= ollapse;border-spacing:0px;">
<= tr>
=
=C2=A0
3D""
=C2=A0
<= td width=3D"300" class=3D"col" style=3D"border:none;border-spacing:0px;vert= ical-align:top;">
=C2=A0
3D""
=C2=A0

= www.ministryofmagicnam.com
=
e: henri@ministryofmagicnam.com
e: md@ministryofmagicnam.com

<= /tr>
=
= =
<= /tbody>

This e-mail has been sent to xfs@oss.sgi.com, click here to unsubscribe.<= /span>

5 Orion Park, L= udwigsdorf 0000 Windhoek NA


3D"" = --=-6/dborFoAy414kEAym4H-- From bfoster@redhat.com Wed Sep 9 09:43:35 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id C31DB7F37 for ; Wed, 9 Sep 2015 09:43:35 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id AF8888F8050 for ; Wed, 9 Sep 2015 07:43:35 -0700 (PDT) X-ASG-Debug-ID: 1441809814-04cb6c355a23100001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id sdonHKVqd1XfxcAT (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 09 Sep 2015 07:43:34 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 17D9567 for ; Wed, 9 Sep 2015 14:43:34 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t89EhXbd009099; Wed, 9 Sep 2015 10:43:33 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 9186C1236D9; Wed, 9 Sep 2015 10:43:32 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Cc: David Jeffery Subject: [PATCH] xfs: add missing ilock around dio write last extent alignment Date: Wed, 9 Sep 2015 10:43:32 -0400 X-ASG-Orig-Subj: [PATCH] xfs: add missing ilock around dio write last extent alignment Message-Id: <1441809812-60175-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441809814 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 The iomap codepath (via get_blocks()) acquires and release the inode lock in the case of a direct write that requires block allocation. This is because xfs_iomap_write_direct() allocates a transaction, which means the ilock must be dropped and reacquired after the transaction is allocated and reserved. xfs_iomap_write_direct() invokes xfs_iomap_eof_align_last_fsb() before the transaction is created and thus before the ilock is reacquired. This can lead to calls to xfs_iread_extents() and reads of the in-core extent list without any synchronization (via xfs_bmap_eof() and xfs_bmap_last_extent()). xfs_iread_extents() assert fails if the ilock is not held, but this is not currently seen in practice as the current callers had already invoked xfs_bmapi_read(). What has been seen in practice are reports of crashes down in the xfs_bmap_eof() codepath on direct writes due to seemingly bogus pointer references from xfs_iext_get_ext(). While an explicit reproducer is not currently available to confirm the cause of the problem, crash analysis and code inspection from David Jeffrey had identified the insufficient locking. xfs_iomap_eof_align_last_fsb() is called from other contexts with the inode lock already held. __xfs_get_blocks() acquires and drops the ilock with variable flags. Therefore, take the simple approach to cycle ilock around the last extent alignment call from xfs_iomap_write_direct(). Reported-by: David Jeffery Signed-off-by: Brian Foster --- fs/xfs/xfs_iomap.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 1f86033..4d7534e 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -142,7 +142,9 @@ xfs_iomap_write_direct( offset_fsb = XFS_B_TO_FSBT(mp, offset); last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); if ((offset + count) > XFS_ISIZE(ip)) { + xfs_ilock(ip, XFS_ILOCK_EXCL); error = xfs_iomap_eof_align_last_fsb(mp, ip, extsz, &last_fsb); + xfs_iunlock(ip, XFS_ILOCK_EXCL); if (error) return error; } else { -- 2.1.0 From billodo@redhat.com Wed Sep 9 12:07:24 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 8BCF07F37 for ; Wed, 9 Sep 2015 12:07:24 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 68202304059 for ; Wed, 9 Sep 2015 10:07:24 -0700 (PDT) X-ASG-Debug-ID: 1441818443-04bdf04db429ab0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id kgEKSXPniwzeDyqC (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 09 Sep 2015 10:07:23 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id F0530A2C12 for ; Wed, 9 Sep 2015 17:07:22 +0000 (UTC) Received: from localhost.localdomain.com (unused [10.10.52.30] (may be forged)) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t89H7Mv8003396 for ; Wed, 9 Sep 2015 13:07:22 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 0/4 v6] xfs: new global stats in sysfs Date: Wed, 9 Sep 2015 12:06:31 -0500 X-ASG-Orig-Subj: [PATCH 0/4 v6] xfs: new global stats in sysfs Message-Id: <1441818395-11612-1-git-send-email-billodo@redhat.com> 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: 1441818443 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi all- Here is the sixth iteration of the series to add new global stats to sysfs. ----------history--------------- v6: -patch 4/4: move to_xlog(kobject) to the relevant show/store operations. This keeps the xfs_sysfs_object_show/store functions generic. Also, with the change, there can be some cleanup of the show/store function arguments. V5: -optimization of sysfs_ops function. -style fixups V4: -whitespace fixup of patch 1 -add patch 4 (sysfs ops consolidation - dbg, stats, log) V3: -style fixups and removal of extraneous printk. V2: -style fixups. V1: -------------------------------- The series provides the beginnings of the infrastructure for per-fs stats (in addition to global accumulative stats). We already have per-fs information in /sys, so it makes sense to have per-fs stats there too. As a first step, moving existing global stats infrastructure to /sys will allow us to re-use that sysfs code for per-fs stats as well. Patch 1 handles the bring-up and tear down of xfs/stats directory structure in sysfs when an fs is mounted. The directory contains the stats file and the stats_clear file. The stats file contents mimic those of /proc/fs/xfs/stat. The stats_clear file is empty, and much like the current stat_clear command, handles the zeroing of the stats file when a "1" is echoed to the stats_clear file. Patch 2 creates the symlink for stats from procfs to sysfs. Patch 3 removes the now unused portions of procfs for stat. Patch 4 consolidates the sysfs ops for dbg, stats, log. Comments/questions welcome. Thanks- Bill From billodo@redhat.com Wed Sep 9 12:07:26 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 0772729DFC for ; Wed, 9 Sep 2015 12:07:26 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id EBA8330404E for ; Wed, 9 Sep 2015 10:07:25 -0700 (PDT) X-ASG-Debug-ID: 1441818444-04cbb005ec28980001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id sFDpKWAPb3FnUowv (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 09 Sep 2015 10:07:25 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 833242B786D for ; Wed, 9 Sep 2015 17:07:24 +0000 (UTC) Received: from localhost.localdomain.com (unused [10.10.52.30] (may be forged)) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t89H7MvB003396 for ; Wed, 9 Sep 2015 13:07:24 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 3/4] xfs: remove unused procfs code Date: Wed, 9 Sep 2015 12:06:34 -0500 X-ASG-Orig-Subj: [PATCH 3/4] xfs: remove unused procfs code Message-Id: <1441818395-11612-4-git-send-email-billodo@redhat.com> In-Reply-To: <1441818395-11612-1-git-send-email-billodo@redhat.com> References: <1441818395-11612-1-git-send-email-billodo@redhat.com> 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: 1441818444 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch removes the now unused procfs code that was xfs stat specific. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 74 ------------------------------------------------------ 1 file changed, 74 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index a9f05de..05d5227 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -112,80 +112,6 @@ void xfs_stats_clearall(void) } } -static int xfs_stat_proc_show(struct seq_file *m, void *v) -{ - int i, j; - __uint64_t xs_xstrat_bytes = 0; - __uint64_t xs_write_bytes = 0; - __uint64_t xs_read_bytes = 0; - - static const struct xstats_entry { - char *desc; - int endpoint; - } xstats[] = { - { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, - { "abt", XFSSTAT_END_ALLOC_BTREE }, - { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, - { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, - { "dir", XFSSTAT_END_DIRECTORY_OPS }, - { "trans", XFSSTAT_END_TRANSACTIONS }, - { "ig", XFSSTAT_END_INODE_OPS }, - { "log", XFSSTAT_END_LOG_OPS }, - { "push_ail", XFSSTAT_END_TAIL_PUSHING }, - { "xstrat", XFSSTAT_END_WRITE_CONVERT }, - { "rw", XFSSTAT_END_READ_WRITE_OPS }, - { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, - { "icluster", XFSSTAT_END_INODE_CLUSTER }, - { "vnodes", XFSSTAT_END_VNODE_OPS }, - { "buf", XFSSTAT_END_BUF }, - { "abtb2", XFSSTAT_END_ABTB_V2 }, - { "abtc2", XFSSTAT_END_ABTC_V2 }, - { "bmbt2", XFSSTAT_END_BMBT_V2 }, - { "ibt2", XFSSTAT_END_IBT_V2 }, - { "fibt2", XFSSTAT_END_FIBT_V2 }, - /* we print both series of quota information together */ - { "qm", XFSSTAT_END_QM }, - }; - - /* Loop over all stats groups */ - for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { - seq_printf(m, "%s", xstats[i].desc); - /* inner loop does each group */ - for (; j < xstats[i].endpoint; j++) - seq_printf(m, " %u", counter_val(j)); - seq_putc(m, '\n'); - } - /* extra precision counters */ - for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; - } - - seq_printf(m, "xpc %Lu %Lu %Lu\n", - xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); - seq_printf(m, "debug %u\n", -#if defined(DEBUG) - 1); -#else - 0); -#endif - return 0; -} - -static int xfs_stat_proc_open(struct inode *inode, struct file *file) -{ - return single_open(file, xfs_stat_proc_show, NULL); -} - -static const struct file_operations xfs_stat_proc_fops = { - .owner = THIS_MODULE, - .open = xfs_stat_proc_open, - .read = seq_read, - .llseek = seq_lseek, - .release = single_release, -}; - /* legacy quota interfaces */ #ifdef CONFIG_XFS_QUOTA static int xqm_proc_show(struct seq_file *m, void *v) -- 2.4.3 From billodo@redhat.com Wed Sep 9 12:07:27 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 124C229E04 for ; Wed, 9 Sep 2015 12:07:27 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 025EF8F8065 for ; Wed, 9 Sep 2015 10:07:27 -0700 (PDT) X-ASG-Debug-ID: 1441818445-04cb6c355c27670001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Se5PG9It4gEEfDxv (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 09 Sep 2015 10:07:25 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 0BA04C0AA27D for ; Wed, 9 Sep 2015 17:07:25 +0000 (UTC) Received: from localhost.localdomain.com (unused [10.10.52.30] (may be forged)) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t89H7MvC003396 for ; Wed, 9 Sep 2015 13:07:24 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 4/4] xfs: consolidate sysfs ops (dbg, stats, log) Date: Wed, 9 Sep 2015 12:06:35 -0500 X-ASG-Orig-Subj: [PATCH 4/4] xfs: consolidate sysfs ops (dbg, stats, log) Message-Id: <1441818395-11612-5-git-send-email-billodo@redhat.com> In-Reply-To: <1441818395-11612-1-git-send-email-billodo@redhat.com> References: <1441818395-11612-1-git-send-email-billodo@redhat.com> 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: 1441818445 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the series to move xfs global stats from procfs to sysfs, this patch consolidates the sysfs ops functions and removes redundancy. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 2 +- fs/xfs/xfs_sysfs.c | 182 +++++++++++++++++++---------------------------------- 2 files changed, 64 insertions(+), 120 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 05d5227..dc6ca67 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -92,7 +92,7 @@ int xfs_stats_format(char *buf) 0); #endif -return len; + return len; } void xfs_stats_clearall(void) diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index a094e20..ab4850b 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -25,8 +25,9 @@ struct xfs_sysfs_attr { struct attribute attr; - ssize_t (*show)(char *buf, void *data); - ssize_t (*store)(const char *buf, size_t count, void *data); + ssize_t (*show)(struct kobject *kobject, char *buf); + ssize_t (*store)(struct kobject *kobject, const char *buf, + size_t count); }; static inline struct xfs_sysfs_attr * @@ -54,14 +55,42 @@ struct kobj_type xfs_mp_ktype = { .release = xfs_sysfs_release, }; +STATIC ssize_t +xfs_sysfs_object_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->show ? xfs_attr->show(kobject, buf) : 0; +} + +STATIC ssize_t +xfs_sysfs_object_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->store ? xfs_attr->store(kobject, buf, count) : 0; +} + +static const struct sysfs_ops xfs_sysfs_ops = { + .show = xfs_sysfs_object_show, + .store = xfs_sysfs_object_store, +}; + #ifdef DEBUG /* debug */ STATIC ssize_t log_recovery_delay_store( + struct kobject *kobject, const char *buf, - size_t count, - void *data) + size_t count) { int ret; int val; @@ -80,8 +109,8 @@ log_recovery_delay_store( STATIC ssize_t log_recovery_delay_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { return snprintf(buf, PAGE_SIZE, "%d\n", xfs_globals.log_recovery_delay); } @@ -92,49 +121,20 @@ static struct attribute *xfs_dbg_attrs[] = { NULL, }; -STATIC ssize_t -xfs_dbg_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; -} - -STATIC ssize_t -xfs_dbg_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; -} - -static struct sysfs_ops xfs_dbg_ops = { - .show = xfs_dbg_show, - .store = xfs_dbg_store, -}; - struct kobj_type xfs_dbg_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_dbg_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_dbg_attrs, }; #endif /* DEBUG */ - /* stats */ STATIC ssize_t stats_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { return xfs_stats_format(buf); } @@ -142,9 +142,9 @@ XFS_SYSFS_ATTR_RO(stats); STATIC ssize_t stats_clear_store( + struct kobject *kobject, const char *buf, - size_t count, - void *data) + size_t count) { int ret; int val; @@ -166,50 +166,30 @@ static struct attribute *xfs_stats_attrs[] = { NULL, }; -STATIC ssize_t -xfs_stats_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; -} - -STATIC ssize_t -xfs_stats_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; -} - -static struct sysfs_ops xfs_stats_ops = { - .show = xfs_stats_show, - .store = xfs_stats_store, -}; - struct kobj_type xfs_stats_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_stats_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_stats_attrs, }; /* xlog */ +static inline struct xlog * +to_xlog(struct kobject *kobject) +{ + struct xfs_kobj *kobj = to_kobj(kobject); + + return container_of(kobj, struct xlog, l_kobj); +} + STATIC ssize_t log_head_lsn_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { - struct xlog *log = data; int cycle; int block; + struct xlog *log = to_xlog(kobject); spin_lock(&log->l_icloglock); cycle = log->l_curr_cycle; @@ -222,12 +202,12 @@ XFS_SYSFS_ATTR_RO(log_head_lsn); STATIC ssize_t log_tail_lsn_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { - struct xlog *log = data; int cycle; int block; + struct xlog *log = to_xlog(kobject); xlog_crack_atomic_lsn(&log->l_tail_lsn, &cycle, &block); return snprintf(buf, PAGE_SIZE, "%d:%d\n", cycle, block); @@ -236,12 +216,13 @@ XFS_SYSFS_ATTR_RO(log_tail_lsn); STATIC ssize_t reserve_grant_head_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) + { - struct xlog *log = data; int cycle; int bytes; + struct xlog *log = to_xlog(kobject); xlog_crack_grant_head(&log->l_reserve_head.grant, &cycle, &bytes); return snprintf(buf, PAGE_SIZE, "%d:%d\n", cycle, bytes); @@ -250,12 +231,12 @@ XFS_SYSFS_ATTR_RO(reserve_grant_head); STATIC ssize_t write_grant_head_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { - struct xlog *log = data; int cycle; int bytes; + struct xlog *log = to_xlog(kobject); xlog_crack_grant_head(&log->l_write_head.grant, &cycle, &bytes); return snprintf(buf, PAGE_SIZE, "%d:%d\n", cycle, bytes); @@ -270,45 +251,8 @@ static struct attribute *xfs_log_attrs[] = { NULL, }; -static inline struct xlog * -to_xlog(struct kobject *kobject) -{ - struct xfs_kobj *kobj = to_kobj(kobject); - return container_of(kobj, struct xlog, l_kobj); -} - -STATIC ssize_t -xfs_log_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xlog *log = to_xlog(kobject); - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, log) : 0; -} - -STATIC ssize_t -xfs_log_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xlog *log = to_xlog(kobject); - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, log) : 0; -} - -static struct sysfs_ops xfs_log_ops = { - .show = xfs_log_show, - .store = xfs_log_store, -}; - struct kobj_type xfs_log_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_log_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_log_attrs, }; -- 2.4.3 From billodo@redhat.com Wed Sep 9 12:07:28 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 58D1E29E04 for ; Wed, 9 Sep 2015 12:07:28 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3A5BE8F8059 for ; Wed, 9 Sep 2015 10:07:25 -0700 (PDT) X-ASG-Debug-ID: 1441818444-04cb6c355a27660001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id OTSb7ee6QaLHYjtf (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 09 Sep 2015 10:07:24 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 008828EA45 for ; Wed, 9 Sep 2015 17:07:23 +0000 (UTC) Received: from localhost.localdomain.com (unused [10.10.52.30] (may be forged)) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t89H7MvA003396 for ; Wed, 9 Sep 2015 13:07:23 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 2/4] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Date: Wed, 9 Sep 2015 12:06:33 -0500 X-ASG-Orig-Subj: [PATCH 2/4] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-Id: <1441818395-11612-3-git-send-email-billodo@redhat.com> In-Reply-To: <1441818395-11612-1-git-send-email-billodo@redhat.com> References: <1441818395-11612-1-git-send-email-billodo@redhat.com> 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: 1441818444 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 6008e25..a9f05de 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -244,9 +244,10 @@ xfs_init_procfs(void) if (!proc_mkdir("fs/xfs", NULL)) goto out; - if (!proc_create("fs/xfs/stat", 0, NULL, - &xfs_stat_proc_fops)) + if (!proc_symlink("fs/xfs/stat", NULL, + "/sys/fs/xfs/stats/stats")) goto out_remove_xfs_dir; + #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, &xqmstat_proc_fops)) -- 2.4.3 From billodo@redhat.com Wed Sep 9 12:07:29 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A8D6E29E09 for ; Wed, 9 Sep 2015 12:07:29 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 297EAAC005 for ; Wed, 9 Sep 2015 10:07:26 -0700 (PDT) X-ASG-Debug-ID: 1441818443-04cbb005e928970001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id LjP2CfnKDarRJXPd (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 09 Sep 2015 10:07:24 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 98C0EA1007 for ; Wed, 9 Sep 2015 17:07:23 +0000 (UTC) Received: from localhost.localdomain.com (unused [10.10.52.30] (may be forged)) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t89H7Mv9003396 for ; Wed, 9 Sep 2015 13:07:23 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 1/4] xfs: create global stats and stats_clear in sysfs Date: Wed, 9 Sep 2015 12:06:32 -0500 X-ASG-Orig-Subj: [PATCH 1/4] xfs: create global stats and stats_clear in sysfs Message-Id: <1441818395-11612-2-git-send-email-billodo@redhat.com> In-Reply-To: <1441818395-11612-1-git-send-email-billodo@redhat.com> References: <1441818395-11612-1-git-send-email-billodo@redhat.com> 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: 1441818444 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Currently, xfs global stats are in procfs. This patch introduces (replicates) the global stats in sysfs. Additionally a stats_clear file is introduced in sysfs. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_stats.h | 2 ++ fs/xfs/xfs_super.c | 20 +++++++++---- fs/xfs/xfs_sysctl.c | 15 ++-------- fs/xfs/xfs_sysfs.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_sysfs.h | 1 + 6 files changed, 179 insertions(+), 17 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index f224038..6008e25 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -29,6 +29,89 @@ static int counter_val(int idx) return val; } +int xfs_stats_format(char *buf) +{ + int i, j; + int len = 0; + __uint64_t xs_xstrat_bytes = 0; + __uint64_t xs_write_bytes = 0; + __uint64_t xs_read_bytes = 0; + + static const struct xstats_entry { + char *desc; + int endpoint; + } xstats[] = { + { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, + { "abt", XFSSTAT_END_ALLOC_BTREE }, + { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, + { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, + { "dir", XFSSTAT_END_DIRECTORY_OPS }, + { "trans", XFSSTAT_END_TRANSACTIONS }, + { "ig", XFSSTAT_END_INODE_OPS }, + { "log", XFSSTAT_END_LOG_OPS }, + { "push_ail", XFSSTAT_END_TAIL_PUSHING }, + { "xstrat", XFSSTAT_END_WRITE_CONVERT }, + { "rw", XFSSTAT_END_READ_WRITE_OPS }, + { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, + { "icluster", XFSSTAT_END_INODE_CLUSTER }, + { "vnodes", XFSSTAT_END_VNODE_OPS }, + { "buf", XFSSTAT_END_BUF }, + { "abtb2", XFSSTAT_END_ABTB_V2 }, + { "abtc2", XFSSTAT_END_ABTC_V2 }, + { "bmbt2", XFSSTAT_END_BMBT_V2 }, + { "ibt2", XFSSTAT_END_IBT_V2 }, + { "fibt2", XFSSTAT_END_FIBT_V2 }, + /* we print both series of quota information together */ + { "qm", XFSSTAT_END_QM }, + }; + + /* Loop over all stats groups */ + + for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { + len += snprintf(buf + len, PATH_MAX - len, "%s", + xstats[i].desc); + /* inner loop does each group */ + for (; j < xstats[i].endpoint; j++) + len += snprintf(buf + len, PATH_MAX - len, " %u", + counter_val(j)); + len += snprintf(buf + len, PATH_MAX - len, "\n"); + } + /* extra precision counters */ + for_each_possible_cpu(i) { + xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; + xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; + xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; + } + + len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", + xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); + len += snprintf(buf+len, PATH_MAX-len, "debug %u\n", +#if defined(DEBUG) + 1); +#else + 0); +#endif + +return len; +} + +void xfs_stats_clearall(void) +{ + int c; + __uint32_t vn_active; + + xfs_notice(NULL, "Clearing xfsstats"); + for_each_possible_cpu(c) { + preempt_disable(); + /* save vn_active, it's a universal truth! */ + vn_active = per_cpu(xfsstats, c).vn_active; + memset(&per_cpu(xfsstats, c), 0, + sizeof(struct xfsstats)); + per_cpu(xfsstats, c).vn_active = vn_active; + preempt_enable(); + } +} + static int xfs_stat_proc_show(struct seq_file *m, void *v) { int i, j; diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index c8f238b..18807b5 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -18,6 +18,8 @@ #ifndef __XFS_STATS_H__ #define __XFS_STATS_H__ +int xfs_stats_format(char *buf); +void xfs_stats_clearall(void); #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 3bf503a..31ad281 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -61,6 +61,7 @@ static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; static struct kset *xfs_kset; /* top-level xfs sysfs dir */ +static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ #ifdef DEBUG static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ #endif @@ -1838,19 +1839,25 @@ init_xfs_fs(void) xfs_kset = kset_create_and_add("xfs", NULL, fs_kobj); if (!xfs_kset) { error = -ENOMEM; - goto out_sysctl_unregister;; + goto out_sysctl_unregister; } + xfs_stats_kobj.kobject.kset = xfs_kset; + error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, + "stats"); + if (error) + goto out_kset_unregister; + #ifdef DEBUG xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_kset_unregister; + goto out_remove_stats_kobj; #endif error = xfs_qm_init(); if (error) - goto out_remove_kobj; + goto out_remove_dbg_kobj; error = register_filesystem(&xfs_fs_type); if (error) @@ -1859,11 +1866,13 @@ init_xfs_fs(void) out_qm_exit: xfs_qm_exit(); - out_remove_kobj: + out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_kset_unregister: + out_remove_stats_kobj: #endif + xfs_sysfs_del(&xfs_stats_kobj); + out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: xfs_sysctl_unregister(); @@ -1889,6 +1898,7 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif + xfs_sysfs_del(&xfs_stats_kobj); kset_unregister(xfs_kset); xfs_sysctl_unregister(); xfs_cleanup_procfs(); diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c index a0c8067..5defabb 100644 --- a/fs/xfs/xfs_sysctl.c +++ b/fs/xfs/xfs_sysctl.c @@ -19,6 +19,7 @@ #include #include #include "xfs_error.h" +#include "xfs_stats.h" static struct ctl_table_header *xfs_table_header; @@ -31,22 +32,12 @@ xfs_stats_clear_proc_handler( size_t *lenp, loff_t *ppos) { - int c, ret, *valp = ctl->data; - __uint32_t vn_active; + int ret, *valp = ctl->data; ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); if (!ret && write && *valp) { - xfs_notice(NULL, "Clearing xfsstats"); - for_each_possible_cpu(c) { - preempt_disable(); - /* save vn_active, it's a universal truth! */ - vn_active = per_cpu(xfsstats, c).vn_active; - memset(&per_cpu(xfsstats, c), 0, - sizeof(struct xfsstats)); - per_cpu(xfsstats, c).vn_active = vn_active; - preempt_enable(); - } + xfs_stats_clearall(); xfs_stats_clear = 0; } diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index aa03670..a094e20 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -21,6 +21,7 @@ #include "xfs_log_format.h" #include "xfs_log.h" #include "xfs_log_priv.h" +#include "xfs_stats.h" struct xfs_sysfs_attr { struct attribute attr; @@ -38,6 +39,8 @@ to_attr(struct attribute *attr) static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RW(name) #define XFS_SYSFS_ATTR_RO(name) \ static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RO(name) +#define XFS_SYSFS_ATTR_WO(name) \ + static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_WO(name) #define ATTR_LIST(name) &xfs_sysfs_attr_##name.attr @@ -125,6 +128,78 @@ struct kobj_type xfs_dbg_ktype = { #endif /* DEBUG */ + +/* stats */ + +STATIC ssize_t +stats_show( + char *buf, + void *data) +{ + return xfs_stats_format(buf); +} +XFS_SYSFS_ATTR_RO(stats); + +STATIC ssize_t +stats_clear_store( + const char *buf, + size_t count, + void *data) +{ + int ret; + int val; + + ret = kstrtoint(buf, 0, &val); + if (ret) + return ret; + + if (val != 1) + return -EINVAL; + xfs_stats_clearall(); + return count; +} +XFS_SYSFS_ATTR_WO(stats_clear); + +static struct attribute *xfs_stats_attrs[] = { + ATTR_LIST(stats), + ATTR_LIST(stats_clear), + NULL, +}; + +STATIC ssize_t +xfs_stats_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; +} + +STATIC ssize_t +xfs_stats_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; +} + +static struct sysfs_ops xfs_stats_ops = { + .show = xfs_stats_show, + .store = xfs_stats_store, +}; + +struct kobj_type xfs_stats_ktype = { + .release = xfs_sysfs_release, + .sysfs_ops = &xfs_stats_ops, + .default_attrs = xfs_stats_attrs, +}; + /* xlog */ STATIC ssize_t diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h index 240eee3..be692e5 100644 --- a/fs/xfs/xfs_sysfs.h +++ b/fs/xfs/xfs_sysfs.h @@ -22,6 +22,7 @@ extern struct kobj_type xfs_mp_ktype; /* xfs_mount */ extern struct kobj_type xfs_dbg_ktype; /* debug */ extern struct kobj_type xfs_log_ktype; /* xlog */ +extern struct kobj_type xfs_stats_ktype; /* stats */ static inline struct xfs_kobj * to_kobj(struct kobject *kobject) -- 2.4.3 From sandeen@sandeen.net Wed Sep 9 14:34:17 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 01DA67F37 for ; Wed, 9 Sep 2015 14:34:17 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id D0D8F304066 for ; Wed, 9 Sep 2015 12:34:16 -0700 (PDT) X-ASG-Debug-ID: 1441827254-04cb6c355c2b600001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id dFSmBK7MbtC8SsR5 for ; Wed, 09 Sep 2015 12:34:14 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id 7C4EA61BD078; Wed, 9 Sep 2015 14:34:14 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c Date: Wed, 9 Sep 2015 14:33:58 -0500 X-ASG-Orig-Subj: [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c Message-Id: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827254 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- repair/dir2.c and repair/attr_repair.c got cut and pasted long, long ago and have diverged since. This series brings them back together, presumably fixes some bugs, and loses a few hundred lines in the process. o/~ reunited, and it feels so so good ... o/~ The series accomplishes this through a combination of trivial changes (removing unused structure members, whitespace, etc) as well as by "cross-porting" changes & fixes which happened to one file but not the other over the past many years. Along the way, a graphical diff of dir2 vs. attr_repair should show the convergence. Up until the last patch, I don't worry about dir vs. attr naming in comments or error messages; the goal is to make these chunks of the two files sufficiently similar so that by patch 11, the reviewer can do a diff and say "yeah, ok, those really are substantially the same now." Also instructive is to apply up to patch 11, copy dir2.c and attr_repair.c to /tmp, apply patch 12, and do a 3-way graphical diff of the 3 files to see that the move really is OK and didn't play any significant tricks. The last patch fixes up the dir vs. attr text in error messages and comments. I do have a question about whether this is ok for i8n: printf(_("This string is %s"), _("awesome")); because that's essentially the trick I used... Thanks, -Eric From sandeen@sandeen.net Wed Sep 9 14:34:17 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 1A1BA7F3F for ; Wed, 9 Sep 2015 14:34:17 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 09A818F8049 for ; Wed, 9 Sep 2015 12:34:16 -0700 (PDT) X-ASG-Debug-ID: 1441827255-04cbb005ec2d2f0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id xJyivsBHadCFm2Pe for ; Wed, 09 Sep 2015 12:34:15 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id DC64963CBFE9; Wed, 9 Sep 2015 14:34:14 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 06/13] xfs_repair: add XR_DIR_TRACE to dir2.c Date: Wed, 9 Sep 2015 14:34:04 -0500 X-ASG-Orig-Subj: [PATCH 06/13] xfs_repair: add XR_DIR_TRACE to dir2.c Message-Id: <1441827251-13128-7-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827255 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- attr_repair.c has many printf-tracepoints under #ifdef XR_DIR_TRACE, but the similar code in dir2.c does not. Add these same tracepoints to remove more differences between these two pieces of code. Not all messages are quite correct; those will be fixed up last. For now we just make the code more obviously similar. Signed-off-by: Eric Sandeen Signed-off-by: Eric Sandeen --- repair/dir2.c | 39 ++++++++++++++++++++++++++++++++++++--- 1 files changed, 36 insertions(+), 3 deletions(-) diff --git a/repair/dir2.c b/repair/dir2.c index 898b27e..d9bd5fc 100644 --- a/repair/dir2.c +++ b/repair/dir2.c @@ -337,6 +337,11 @@ verify_final_dir2_path(xfs_mount_t *mp, struct xfs_da_node_entry *btree; struct xfs_da3_icnode_hdr nodehdr; +#ifdef XR_DIR_TRACE + fprintf(stderr, "in verify_final_dir2_path, this_level = %d\n", + this_level); +#endif + /* * the index should point to the next "unprocessed" entry * in the block which should be the final (rightmost) entry @@ -388,8 +393,17 @@ verify_final_dir2_path(xfs_mount_t *mp, /* * ok, now check descendant block number against this level */ - if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) + if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { +#ifdef XR_DIR_TRACE + fprintf(stderr, "bad directory btree pointer, child bno should " + "be %d, block bno is %d, hashval is %u\n", + be16_to_cpu(btree[entry].before), + cursor->level[p_level].bno, + cursor->level[p_level].hashval); + fprintf(stderr, "verify_final_dir2_path returns 1 (bad) #1a\n"); +#endif return(1); + } if (cursor->level[p_level].hashval != be32_to_cpu(btree[entry].hashval)) { @@ -431,8 +445,12 @@ _("would correct bad hashval in non-leaf dir block\n" /* * bail out if this is the root block (top of tree) */ - if (this_level >= cursor->active) + if (this_level >= cursor->active) { +#ifdef XR_DIR_TRACE + fprintf(stderr, "verify_final_dir2_path returns 0 (ok)\n"); +#endif return(0); + } /* * set hashvalue to correctl reflect the now-validated * last entry in this block and continue upwards validation @@ -600,6 +618,9 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), bad++; } if (bad) { +#ifdef XR_DIR_TRACE + fprintf(stderr, "verify_dir2_path returns 1 (bad) #4\n"); +#endif libxfs_putbuf(bp); return(1); } @@ -631,8 +652,17 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), /* * ditto for block numbers */ - if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) + if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { +#ifdef XR_DIR_TRACE + fprintf(stderr, "bad directory btree pointer, child bno " + "should be %d, block bno is %d, hashval is %u\n", + be32_to_cpu(btree[entry].before), + cursor->level[p_level].bno, + cursor->level[p_level].hashval); + fprintf(stderr, "verify_dir2_path returns 1 (bad) #1a\n"); +#endif return(1); + } /* * ok, now validate last hashvalue in the descendant * block against the hashval in the current entry @@ -659,6 +689,9 @@ _("would correct bad hashval in interior dir block\n" * (which should point to the next descendant block) */ cursor->level[this_level].index++; +#ifdef XR_DIR_TRACE + fprintf(stderr, "verify_dir2_path returns 0 (ok)\n"); +#endif return(0); } -- 1.7.1 From sandeen@sandeen.net Wed Sep 9 14:34:17 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6877A7F37 for ; Wed, 9 Sep 2015 14:34:17 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3AFDC8F8054 for ; Wed, 9 Sep 2015 12:34:17 -0700 (PDT) X-ASG-Debug-ID: 1441827255-04bdf04db52e1a0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id tb5ZOCUNzMWKY6uK for ; Wed, 09 Sep 2015 12:34:16 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id CFB4763CBFD7; Wed, 9 Sep 2015 14:34:14 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 05/13] xfs_repair: fix use-after-free in verify_final_dir2_path Date: Wed, 9 Sep 2015 14:34:03 -0500 X-ASG-Orig-Subj: [PATCH 05/13] xfs_repair: fix use-after-free in verify_final_dir2_path Message-Id: <1441827251-13128-6-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827255 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 2.60 X-Barracuda-Spam-Status: No, SCORE=2.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MV0249, MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words 2.00 BSF_SC0_MV0249 Custom rule MV0249 Way back in 2002, commit 948ce18 fixed a potential use-after-free in verify_final_da_path, but the same fix was not applied to verify_final_dir2_path; apply it now. Signed-off-by: Eric Sandeen Signed-off-by: Eric Sandeen --- repair/dir2.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/repair/dir2.c b/repair/dir2.c index 44367c6..898b27e 100644 --- a/repair/dir2.c +++ b/repair/dir2.c @@ -330,6 +330,7 @@ verify_final_dir2_path(xfs_mount_t *mp, const int p_level) { xfs_da_intnode_t *node; + xfs_dahash_t hashval; int bad = 0; int entry; int this_level = p_level + 1; @@ -409,6 +410,12 @@ _("would correct bad hashval in non-leaf dir block\n" } /* + * Note: squirrel hashval away _before_ releasing the + * buffer, preventing a use-after-free problem. + */ + hashval = be32_to_cpu(btree[entry].hashval); + + /* * release/write buffer */ ASSERT(cursor->level[this_level].dirty == 0 || @@ -430,7 +437,7 @@ _("would correct bad hashval in non-leaf dir block\n" * set hashvalue to correctl reflect the now-validated * last entry in this block and continue upwards validation */ - cursor->level[this_level].hashval = be32_to_cpu(btree[entry].hashval); + cursor->level[this_level].hashval = hashval; return(verify_final_dir2_path(mp, cursor, this_level)); } -- 1.7.1 From sandeen@sandeen.net Wed Sep 9 14:34:17 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id B58047F37 for ; Wed, 9 Sep 2015 14:34:17 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id A246B304062 for ; Wed, 9 Sep 2015 12:34:17 -0700 (PDT) X-ASG-Debug-ID: 1441827255-04cb6c355a2b610001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id GIFDXEI7CsdefXI5 for ; Wed, 09 Sep 2015 12:34:16 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id 109F96523F5B; Wed, 9 Sep 2015 14:34:15 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 09/13] xfs_repair: better checking of v5 attributes Date: Wed, 9 Sep 2015 14:34:07 -0500 X-ASG-Orig-Subj: [PATCH 09/13] xfs_repair: better checking of v5 attributes Message-Id: <1441827251-13128-10-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827255 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- The commit: 0519f66 xfs_repair: better checking of v5 metadata fields added new corruption checks to dir2.c but missed the similar code in attr_repair.c; add that here. Signed-off-by: Eric Sandeen Signed-off-by: Eric Sandeen --- repair/attr_repair.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/repair/attr_repair.c b/repair/attr_repair.c index 2aafdf6..c8ba484 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -201,6 +201,15 @@ traverse_int_dablock(xfs_mount_t *mp, goto error_out; } + /* corrupt node; rebuild the dir. */ + if (bp->b_error == -EFSBADCRC || bp->b_error == -EFSCORRUPTED) { + libxfs_putbuf(bp); + do_warn( +_("corrupt tree block %u for directory inode %" PRIu64 "\n"), + bno, da_cursor->ino); + goto error_out; + } + if (nodehdr.count > geo->node_ents) { do_warn(_("bad record count in inode %" PRIu64 ", " "count = %d, max = %d\n"), -- 1.7.1 From sandeen@sandeen.net Wed Sep 9 14:34:17 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id C937C7F3F for ; Wed, 9 Sep 2015 14:34:17 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 74887AC004 for ; Wed, 9 Sep 2015 12:34:17 -0700 (PDT) X-ASG-Debug-ID: 1441827255-04bdf04db32e1a0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id naCYAbBbjcCO4qhX for ; Wed, 09 Sep 2015 12:34:16 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id 0256B6522A68; Wed, 9 Sep 2015 14:34:15 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 08/13] xfs_repair: catch bad level/depth in da node Date: Wed, 9 Sep 2015 14:34:06 -0500 X-ASG-Orig-Subj: [PATCH 08/13] xfs_repair: catch bad level/depth in da node Message-Id: <1441827251-13128-9-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827255 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Two tests added some time ago to dir2.c: 44dae5e xfs_repair: test for bad level in dir2 node 28148f6 xfs_repair: catch bad depth in traverse_int_dir2block never made it to the similar tree-walking code in attr_repair.c; fix that up here. The error string details will be fixed up later. Signed-off-by; Eric Sandeen Signed-off-by: Eric Sandeen --- repair/attr_repair.c | 12 ++++++++++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/repair/attr_repair.c b/repair/attr_repair.c index 5ae2356..2aafdf6 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -212,9 +212,17 @@ traverse_int_dablock(xfs_mount_t *mp, /* * maintain level counter */ - if (i == -1) + if (i == -1) { i = da_cursor->active = nodehdr.level; - else { + if (i < 1 || i >= XFS_DA_NODE_MAXDEPTH) { + do_warn( +_("bad header depth for directory inode %" PRIu64 "\n"), + da_cursor->ino); + libxfs_putbuf(bp); + i = -1; + goto error_out; + } + } else { if (nodehdr.level == i - 1) { i--; } else { -- 1.7.1 From sandeen@sandeen.net Wed Sep 9 14:34:18 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id DD0BE7F51 for ; Wed, 9 Sep 2015 14:34:17 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id BA1E28F8054 for ; Wed, 9 Sep 2015 12:34:17 -0700 (PDT) X-ASG-Debug-ID: 1441827255-04cb6c355d2b620001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id icX4VzWMFN8GzFoZ for ; Wed, 09 Sep 2015 12:34:16 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id 1E594653A137; Wed, 9 Sep 2015 14:34:15 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 10/13] xfs_repair: Remove more differences between attr & dir2 Date: Wed, 9 Sep 2015 14:34:08 -0500 X-ASG-Orig-Subj: [PATCH 10/13] xfs_repair: Remove more differences between attr & dir2 Message-Id: <1441827251-13128-11-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827255 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- This is a hodgepodge of unrelated but not-completely-trivial chagnes to both the dir2 and attr code to make their common code more similar. * It removes the whichfork checking in attr_repair, because we only get there with XFS_ATTR_FORK. * It changes the magic-checking logic slightly to match. * It swaps some (bp == NULL) tests for (!bp) These should be purely cosmetic changes. Signed-off-by: Eric Sandeen Signed-off-by: Eric Sandeen --- repair/attr_repair.c | 20 +++++--------------- repair/dir2.c | 14 ++++++++------ 2 files changed, 13 insertions(+), 21 deletions(-) diff --git a/repair/attr_repair.c b/repair/attr_repair.c index c8ba484..26a0e71 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -177,19 +177,13 @@ traverse_int_dablock(xfs_mount_t *mp, free(bmp); if (!bp) { - if (whichfork == XFS_DATA_FORK) - do_warn( - _("can't read block %u (fsbno %" PRIu64 ") for directory inode %" PRIu64 "\n"), - bno, fsbno, da_cursor->ino); - else - do_warn( + do_warn( _("can't read block %u (fsbno %" PRIu64 ") for attrbute fork of inode %" PRIu64 "\n"), bno, fsbno, da_cursor->ino); goto error_out; } node = bp->b_addr; - btree = M_DIROPS(mp)->node_tree_p(node); M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); if (nodehdr.magic != XFS_DA_NODE_MAGIC && @@ -210,6 +204,7 @@ _("corrupt tree block %u for directory inode %" PRIu64 "\n"), goto error_out; } + btree = M_DIROPS(mp)->node_tree_p(node); if (nodehdr.count > geo->node_ents) { do_warn(_("bad record count in inode %" PRIu64 ", " "count = %d, max = %d\n"), @@ -235,14 +230,9 @@ _("bad header depth for directory inode %" PRIu64 "\n"), if (nodehdr.level == i - 1) { i--; } else { - if (whichfork == XFS_DATA_FORK) - do_warn(_("bad directory btree for " - "directory inode %" PRIu64 "\n"), - da_cursor->ino); - else - do_warn(_("bad attribute fork btree " - "for inode %" PRIu64 "\n"), - da_cursor->ino); + do_warn(_("bad attribute fork btree " + "for inode %" PRIu64 "\n"), + da_cursor->ino); libxfs_putbuf(bp); goto error_out; } diff --git a/repair/dir2.c b/repair/dir2.c index 9398df5..8cf981f 100644 --- a/repair/dir2.c +++ b/repair/dir2.c @@ -172,7 +172,7 @@ traverse_int_dir2block(xfs_mount_t *mp, bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); if (bmp != &lbmp) free(bmp); - if (bp == NULL) { + if (!bp) { do_warn( _("can't read block %u for directory inode %" PRIu64 "\n"), bno, da_cursor->ino); @@ -192,8 +192,10 @@ _("found non-root LEAFN node in inode %" PRIu64 " bno = %u\n"), *rbno = 0; libxfs_putbuf(bp); return(1); - } else if (!(nodehdr.magic == XFS_DA_NODE_MAGIC || - nodehdr.magic == XFS_DA3_NODE_MAGIC)) { + } + + if (nodehdr.magic != XFS_DA_NODE_MAGIC && + nodehdr.magic != XFS_DA3_NODE_MAGIC) { libxfs_putbuf(bp); do_warn( _("bad dir magic number 0x%x in inode %" PRIu64 " bno = %u\n"), @@ -574,7 +576,7 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), if (bmp != &lbmp) free(bmp); - if (bp == NULL) { + if (!bp) { do_warn( _("can't read block %u for directory inode %" PRIu64 "\n"), dabno, cursor->ino); @@ -589,8 +591,8 @@ _("can't read block %u for directory inode %" PRIu64 "\n"), * entry count, verify level */ bad = 0; - if (!(nodehdr.magic == XFS_DA_NODE_MAGIC || - nodehdr.magic == XFS_DA3_NODE_MAGIC)) { + if (nodehdr.magic != XFS_DA_NODE_MAGIC && + nodehdr.magic != XFS_DA3_NODE_MAGIC) { do_warn( _("bad magic number %x in block %u for directory inode %" PRIu64 "\n"), nodehdr.magic, -- 1.7.1 From sandeen@sandeen.net Wed Sep 9 14:34:18 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 60A9B7F3F for ; Wed, 9 Sep 2015 14:34:18 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id F3799AC004 for ; Wed, 9 Sep 2015 12:34:17 -0700 (PDT) X-ASG-Debug-ID: 1441827255-04bdf04db42e1a0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id zTGoDAtu4r6N5foG for ; Wed, 09 Sep 2015 12:34:16 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id E8D0B63CBFED; Wed, 9 Sep 2015 14:34:14 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 07/13] xfs_repair: Remove BUF_PTR from attr_repair.c Date: Wed, 9 Sep 2015 14:34:05 -0500 X-ASG-Orig-Subj: [PATCH 07/13] xfs_repair: Remove BUF_PTR from attr_repair.c Message-Id: <1441827251-13128-8-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827255 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- The BUF_PTR macro was removed from kernelspace a while ago (6292604 xfs: Remove the macro XFS_BUF_PTR) but it lives on in some parts of xfsprogs. dir2.c doesn't use it, but similar code in attr_repair.c does. remove it from attr_repair.c to converge the code. Remove a related but unnecessary cast from a *void b_addr in dir2.c while we're at it. Signed-off-by: Eric Sandeen Signed-off-by: Eric Sandeen --- repair/attr_repair.c | 12 ++++++------ repair/dir2.c | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/repair/attr_repair.c b/repair/attr_repair.c index fe81df4..5ae2356 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -188,7 +188,7 @@ traverse_int_dablock(xfs_mount_t *mp, goto error_out; } - node = (xfs_da_intnode_t *)XFS_BUF_PTR(bp); + node = bp->b_addr; btree = M_DIROPS(mp)->node_tree_p(node); M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); @@ -335,7 +335,7 @@ verify_final_da_path(xfs_mount_t *mp, * in the block which should be the final (rightmost) entry */ entry = cursor->level[this_level].index; - node = (xfs_da_intnode_t *)XFS_BUF_PTR(cursor->level[this_level].bp); + node = cursor->level[this_level].bp->b_addr; btree = M_DIROPS(mp)->node_tree_p(node); M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); @@ -513,7 +513,7 @@ verify_da_path(xfs_mount_t *mp, * should be processed now in this level. */ entry = cursor->level[this_level].index; - node = (xfs_da_intnode_t *)XFS_BUF_PTR(cursor->level[this_level].bp); + node = cursor->level[this_level].bp->b_addr; btree = M_DIROPS(mp)->node_tree_p(node); M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); @@ -571,7 +571,7 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), return(1); } - newnode = (xfs_da_intnode_t *)XFS_BUF_PTR(bp); + newnode = bp->b_addr; btree = M_DIROPS(mp)->node_tree_p(newnode); M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, newnode); @@ -1040,7 +1040,7 @@ rmtval_get(xfs_mount_t *mp, xfs_ino_t ino, blkmap_t *blkmap, ASSERT(mp->m_sb.sb_blocksize == XFS_BUF_COUNT(bp)); length = MIN(XFS_BUF_COUNT(bp) - hdrsize, valuelen - amountdone); - memmove(value, XFS_BUF_PTR(bp) + hdrsize, length); + memmove(value, bp->b_addr + hdrsize, length); amountdone += length; value += length; i++; @@ -1620,7 +1620,7 @@ process_longform_attr( } /* verify leaf block */ - leaf = (xfs_attr_leafblock_t *)XFS_BUF_PTR(bp); + leaf = bp->b_addr; xfs_attr3_leaf_hdr_from_disk(mp->m_attr_geo, &leafhdr, leaf); /* check sibling pointers in leaf block or root block 0 before diff --git a/repair/dir2.c b/repair/dir2.c index d9bd5fc..9398df5 100644 --- a/repair/dir2.c +++ b/repair/dir2.c @@ -347,7 +347,7 @@ verify_final_dir2_path(xfs_mount_t *mp, * in the block which should be the final (rightmost) entry */ entry = cursor->level[this_level].index; - node = (xfs_da_intnode_t *)(cursor->level[this_level].bp->b_addr); + node = cursor->level[this_level].bp->b_addr; btree = M_DIROPS(mp)->node_tree_p(node); M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); -- 1.7.1 From sandeen@sandeen.net Wed Sep 9 14:34:18 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id B459B7F51 for ; Wed, 9 Sep 2015 14:34:18 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 3335CAC008 for ; Wed, 9 Sep 2015 12:34:18 -0700 (PDT) X-ASG-Debug-ID: 1441827254-04cb6c355b2b600001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id S25UEHuc8NScqTDv for ; Wed, 09 Sep 2015 12:34:14 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id C1DC663CBFD5; Wed, 9 Sep 2015 14:34:14 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 04/13] xfs_repair: use multibuffer read routines in attr_repair.c Date: Wed, 9 Sep 2015 14:34:02 -0500 X-ASG-Orig-Subj: [PATCH 04/13] xfs_repair: use multibuffer read routines in attr_repair.c Message-Id: <1441827251-13128-5-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827254 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- verify_da_path and traverse_int_dablock are similar to verify_dir2_path and traverse_int_dir2block, but one difference is that the dir2 code reads using the multibuffer capable da_read_buf() routine, whereas the attr code doesn't need to, and just calls libxfs_readbuf. The multibuffer code falls back just fine when the geometry indicates that it's not needed, so use that same code in the attribute routines, and remove another dir2 / da difference. We make da_read_buf() non-static to facilitate this. Finally, add a local *geo to these routines, to make the code even more similar at this point. The geometry will get passed in later in the series. Signed-off-by: Eric Sandeen Signed-off-by: Eric Sandeen --- repair/attr_repair.c | 49 +++++++++++++++++++++++++++++++++---------------- repair/dir2.c | 22 +++++++++++++--------- repair/dir2.h | 8 ++++++++ 3 files changed, 54 insertions(+), 25 deletions(-) diff --git a/repair/attr_repair.c b/repair/attr_repair.c index aba0782..fe81df4 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -138,14 +138,20 @@ traverse_int_dablock(xfs_mount_t *mp, xfs_dablk_t *rbno, int whichfork) { + bmap_ext_t *bmp; xfs_dablk_t bno; int i; + int nex; xfs_da_intnode_t *node; + bmap_ext_t lbmp; xfs_fsblock_t fsbno; xfs_buf_t *bp; + struct xfs_da_geometry *geo; struct xfs_da_node_entry *btree; struct xfs_da3_icnode_hdr nodehdr; + geo = mp->m_attr_geo; + /* * traverse down left-side of tree until we hit the * left-most leaf block setting up the btree cursor along @@ -160,13 +166,16 @@ traverse_int_dablock(xfs_mount_t *mp, /* * read in each block along the way and set up cursor */ - fsbno = blkmap_get(da_cursor->blkmap, bno); + nex = blkmap_getn(da_cursor->blkmap, bno, + geo->fsbcount, &bmp, &lbmp); - if (fsbno == NULLFSBLOCK) + if (nex == 0) goto error_out; - bp = libxfs_readbuf(mp->m_dev, XFS_FSB_TO_DADDR(mp, fsbno), - XFS_FSB_TO_BB(mp, 1), 0, &xfs_da3_node_buf_ops); + bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); + if (bmp != &lbmp) + free(bmp); + if (!bp) { if (whichfork == XFS_DATA_FORK) do_warn( @@ -192,12 +201,10 @@ traverse_int_dablock(xfs_mount_t *mp, goto error_out; } - if (nodehdr.count > mp->m_attr_geo->node_ents) { + if (nodehdr.count > geo->node_ents) { do_warn(_("bad record count in inode %" PRIu64 ", " "count = %d, max = %d\n"), - da_cursor->ino, - nodehdr.count, - mp->m_attr_geo->node_ents); + da_cursor->ino, nodehdr.count, geo->node_ents); libxfs_putbuf(bp); goto error_out; } @@ -492,9 +499,15 @@ verify_da_path(xfs_mount_t *mp, int bad; int entry; int this_level = p_level + 1; + bmap_ext_t *bmp; + int nex; + bmap_ext_t lbmp; + struct xfs_da_geometry *geo; struct xfs_da_node_entry *btree; struct xfs_da3_icnode_hdr nodehdr; + geo = mp->m_attr_geo; + /* * index is currently set to point to the entry that * should be processed now in this level. @@ -536,17 +549,21 @@ verify_da_path(xfs_mount_t *mp, */ dabno = nodehdr.forw; ASSERT(dabno != 0); - fsbno = blkmap_get(cursor->blkmap, dabno); - - if (fsbno == NULLFSBLOCK) { - do_warn(_("can't get map info for block %u " - "of directory inode %" PRIu64 "\n"), + nex = blkmap_getn(cursor->blkmap, dabno, geo->fsbcount, + &bmp, &lbmp); + if (nex == 0) { + do_warn( +_("can't get map info for block %u of directory inode %" PRIu64 "\n"), dabno, cursor->ino); return(1); } - bp = libxfs_readbuf(mp->m_dev, XFS_FSB_TO_DADDR(mp, fsbno), - XFS_FSB_TO_BB(mp, 1), 0, &xfs_da3_node_buf_ops); + fsbno = bmp[0].startblock; + + bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); + if (bmp != &lbmp) + free(bmp); + if (!bp) { do_warn( _("can't read block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), @@ -577,7 +594,7 @@ verify_da_path(xfs_mount_t *mp, dabno, fsbno, cursor->ino); bad++; } - if (nodehdr.count > mp->m_attr_geo->node_ents) { + if (nodehdr.count > geo->node_ents) { do_warn( _("entry count %d too large in block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), nodehdr.count, diff --git a/repair/dir2.c b/repair/dir2.c index 54c49eb..44367c6 100644 --- a/repair/dir2.c +++ b/repair/dir2.c @@ -92,7 +92,7 @@ namecheck(char *name, int length) * Multibuffer handling. * V2 directory blocks can be noncontiguous, needing multiple buffers. */ -static struct xfs_buf * +struct xfs_buf * da_read_buf( xfs_mount_t *mp, int nex, @@ -143,9 +143,12 @@ traverse_int_dir2block(xfs_mount_t *mp, int nex; xfs_da_intnode_t *node; bmap_ext_t lbmp; + struct xfs_da_geometry *geo; struct xfs_da_node_entry *btree; struct xfs_da3_icnode_hdr nodehdr; + geo = mp->m_dir_geo; + /* * traverse down left-side of tree until we hit the * left-most leaf block setting up the btree cursor along @@ -161,7 +164,7 @@ traverse_int_dir2block(xfs_mount_t *mp, * read in each block along the way and set up cursor */ nex = blkmap_getn(da_cursor->blkmap, bno, - mp->m_dir_geo->fsbcount, &bmp, &lbmp); + geo->fsbcount, &bmp, &lbmp); if (nex == 0) goto error_out; @@ -207,13 +210,11 @@ _("corrupt tree block %u for directory inode %" PRIu64 "\n"), goto error_out; } btree = M_DIROPS(mp)->node_tree_p(node); - if (nodehdr.count > mp->m_dir_geo->node_ents) { - libxfs_putbuf(bp); + if (nodehdr.count > geo->node_ents) { do_warn( _("bad record count in inode %" PRIu64 ", count = %d, max = %d\n"), - da_cursor->ino, - nodehdr.count, - mp->m_dir_geo->node_ents); + da_cursor->ino, nodehdr.count, geo->node_ents); + libxfs_putbuf(bp); goto error_out; } /* @@ -488,9 +489,12 @@ verify_dir2_path(xfs_mount_t *mp, bmap_ext_t *bmp; int nex; bmap_ext_t lbmp; + struct xfs_da_geometry *geo; struct xfs_da_node_entry *btree; struct xfs_da3_icnode_hdr nodehdr; + geo = mp->m_dir_geo; + /* * index is currently set to point to the entry that * should be processed now in this level. @@ -532,7 +536,7 @@ verify_dir2_path(xfs_mount_t *mp, */ dabno = nodehdr.forw; ASSERT(dabno != 0); - nex = blkmap_getn(cursor->blkmap, dabno, mp->m_dir_geo->fsbcount, + nex = blkmap_getn(cursor->blkmap, dabno, geo->fsbcount, &bmp, &lbmp); if (nex == 0) { do_warn( @@ -574,7 +578,7 @@ _("bad back pointer in block %u for directory inode %" PRIu64 "\n"), dabno, cursor->ino); bad++; } - if (nodehdr.count > mp->m_dir_geo->node_ents) { + if (nodehdr.count > geo->node_ents) { do_warn( _("entry count %d too large in block %u for directory inode %" PRIu64 "\n"), nodehdr.count, diff --git a/repair/dir2.h b/repair/dir2.h index 3cc1941..186633f 100644 --- a/repair/dir2.h +++ b/repair/dir2.h @@ -58,6 +58,14 @@ typedef struct dir2_bt_cursor { struct blkmap *blkmap; } dir2_bt_cursor_t; +#include "bmap.h" /* Goes away in later refactoring */ +struct xfs_buf * +da_read_buf( + xfs_mount_t *mp, + int nex, + bmap_ext_t *bmp, + const struct xfs_buf_ops *ops); + int process_dir2( xfs_mount_t *mp, -- 1.7.1 From sandeen@sandeen.net Wed Sep 9 14:34:19 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 144B27F5F for ; Wed, 9 Sep 2015 14:34:19 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id F30C5304062 for ; Wed, 9 Sep 2015 12:34:18 -0700 (PDT) X-ASG-Debug-ID: 1441827256-04cb6c355c2b620001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id ZEo9a6DJEroDL6VS for ; Wed, 09 Sep 2015 12:34:16 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id 2C7E4653A138; Wed, 9 Sep 2015 14:34:15 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 11/13] xfs_repair: whitespace & comments Date: Wed, 9 Sep 2015 14:34:09 -0500 X-ASG-Orig-Subj: [PATCH 11/13] xfs_repair: whitespace & comments Message-Id: <1441827251-13128-12-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- This patch does nothing but fix up whitespace and comments to match across dir2.c and attr_repair.c At this point, a diff of repair/dir2.c and attr_repair.c show them to be identical in function. Signed-off-by: Eric Sandeen Signed-off-by: Eric Sandeen --- repair/attr_repair.c | 36 ++++++++++++++++++------------------ repair/dir2.c | 46 ++++++++++++++++++++++++---------------------- 2 files changed, 42 insertions(+), 40 deletions(-) diff --git a/repair/attr_repair.c b/repair/attr_repair.c index 26a0e71..0804a22 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -187,7 +187,7 @@ traverse_int_dablock(xfs_mount_t *mp, M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); if (nodehdr.magic != XFS_DA_NODE_MAGIC && - nodehdr.magic != XFS_DA3_NODE_MAGIC) { + nodehdr.magic != XFS_DA3_NODE_MAGIC) { do_warn(_("bad dir/attr magic number in inode %" PRIu64 ", " "file bno = %u, fsbno = %" PRIu64 "\n"), da_cursor->ino, bno, fsbno); @@ -205,7 +205,7 @@ _("corrupt tree block %u for directory inode %" PRIu64 "\n"), } btree = M_DIROPS(mp)->node_tree_p(node); - if (nodehdr.count > geo->node_ents) { + if (nodehdr.count > geo->node_ents) { do_warn(_("bad record count in inode %" PRIu64 ", " "count = %d, max = %d\n"), da_cursor->ino, nodehdr.count, geo->node_ents); @@ -226,10 +226,10 @@ _("bad header depth for directory inode %" PRIu64 "\n"), i = -1; goto error_out; } - } else { - if (nodehdr.level == i - 1) { + } else { + if (nodehdr.level == i - 1) { i--; - } else { + } else { do_warn(_("bad attribute fork btree " "for inode %" PRIu64 "\n"), da_cursor->ino); @@ -256,7 +256,7 @@ _("bad header depth for directory inode %" PRIu64 "\n"), return(1); error_out: - while (i > 1 && i <= da_cursor->active) { + while (i > 1 && i <= da_cursor->active) { libxfs_putbuf(da_cursor->level[i].bp); i++; } @@ -351,7 +351,7 @@ verify_final_da_path(xfs_mount_t *mp, * that all entries are used, encountered and expected hashvals * match, etc. */ - if (entry != nodehdr.count - 1) { + if (entry != nodehdr.count - 1) { do_warn(_("directory/attribute block used/count " "inconsistency - %d/%hu\n"), entry, nodehdr.count); @@ -368,7 +368,7 @@ verify_final_da_path(xfs_mount_t *mp, be32_to_cpu(btree[entry].hashval)); bad++; } - if (nodehdr.forw != 0) { + if (nodehdr.forw != 0) { do_warn(_("bad directory/attribute forward block pointer, " "expected 0, saw %u\n"), nodehdr.forw); @@ -402,7 +402,7 @@ verify_final_da_path(xfs_mount_t *mp, } if (cursor->level[p_level].hashval != be32_to_cpu(btree[entry].hashval)) { - if (!no_modify) { + if (!no_modify) { do_warn(_("correcting bad hashval in non-leaf " "dir/attr block\n\tin (level %d) in " "inode %" PRIu64 ".\n"), @@ -410,7 +410,7 @@ verify_final_da_path(xfs_mount_t *mp, btree[entry].hashval = cpu_to_be32( cursor->level[p_level].hashval); cursor->level[this_level].dirty++; - } else { + } else { do_warn(_("would correct bad hashval in non-leaf " "dir/attr block\n\tin (level %d) in " "inode %" PRIu64 ".\n"), @@ -440,7 +440,7 @@ verify_final_da_path(xfs_mount_t *mp, /* * bail out if this is the root block (top of tree) */ - if (this_level >= cursor->active) { + if (this_level >= cursor->active) { #ifdef XR_DIR_TRACE fprintf(stderr, "verify_final_da_path returns 0 (ok)\n"); #endif @@ -529,7 +529,7 @@ verify_da_path(xfs_mount_t *mp, * block and move on to the next block. * and update cursor value for said level */ - if (entry >= nodehdr.count) { + if (entry >= nodehdr.count) { /* * update the hash value for this level before * validating it. bno value should be ok since @@ -588,7 +588,7 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), */ bad = 0; if (nodehdr.magic != XFS_DA_NODE_MAGIC && - nodehdr.magic != XFS_DA3_NODE_MAGIC) { + nodehdr.magic != XFS_DA3_NODE_MAGIC) { do_warn( _("bad magic number %x in block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), nodehdr.magic, @@ -615,7 +615,7 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), dabno, fsbno, cursor->ino); bad++; } - if (bad) { + if (bad) { #ifdef XR_DIR_TRACE fprintf(stderr, "verify_da_path returns 1 (bad) #4\n"); #endif @@ -654,7 +654,7 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), /* * ditto for block numbers */ - if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { + if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { #ifdef XR_DIR_TRACE fprintf(stderr, "bad directory btree pointer, child bno " "should be %d, block bno is %d, hashval is %u\n", @@ -670,8 +670,8 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), * block against the hashval in the current entry */ if (cursor->level[p_level].hashval != - be32_to_cpu(btree[entry].hashval)) { - if (!no_modify) { + be32_to_cpu(btree[entry].hashval)) { + if (!no_modify) { do_warn(_("correcting bad hashval in interior " "dir/attr block\n\tin (level %d) in " "inode %" PRIu64 ".\n"), @@ -679,7 +679,7 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), btree[entry].hashval = cpu_to_be32( cursor->level[p_level].hashval); cursor->level[this_level].dirty++; - } else { + } else { do_warn(_("would correct bad hashval in interior " "dir/attr block\n\tin (level %d) in " "inode %" PRIu64 ".\n"), diff --git a/repair/dir2.c b/repair/dir2.c index 8cf981f..7b47a9e 100644 --- a/repair/dir2.c +++ b/repair/dir2.c @@ -183,7 +183,7 @@ _("can't read block %u for directory inode %" PRIu64 "\n"), M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); if (nodehdr.magic == XFS_DIR2_LEAFN_MAGIC || - nodehdr.magic == XFS_DIR3_LEAFN_MAGIC) { + nodehdr.magic == XFS_DIR3_LEAFN_MAGIC) { if ( i != -1 ) { do_warn( _("found non-root LEAFN node in inode %" PRIu64 " bno = %u\n"), @@ -195,7 +195,7 @@ _("found non-root LEAFN node in inode %" PRIu64 " bno = %u\n"), } if (nodehdr.magic != XFS_DA_NODE_MAGIC && - nodehdr.magic != XFS_DA3_NODE_MAGIC) { + nodehdr.magic != XFS_DA3_NODE_MAGIC) { libxfs_putbuf(bp); do_warn( _("bad dir magic number 0x%x in inode %" PRIu64 " bno = %u\n"), @@ -212,7 +212,7 @@ _("corrupt tree block %u for directory inode %" PRIu64 "\n"), goto error_out; } btree = M_DIROPS(mp)->node_tree_p(node); - if (nodehdr.count > geo->node_ents) { + if (nodehdr.count > geo->node_ents) { do_warn( _("bad record count in inode %" PRIu64 ", count = %d, max = %d\n"), da_cursor->ino, nodehdr.count, geo->node_ents); @@ -233,9 +233,9 @@ _("bad header depth for directory inode %" PRIu64 "\n"), goto error_out; } } else { - if (nodehdr.level == i - 1) { + if (nodehdr.level == i - 1) { i--; - } else { + } else { do_warn( _("bad directory btree for directory inode %" PRIu64 "\n"), da_cursor->ino); @@ -262,7 +262,7 @@ _("bad directory btree for directory inode %" PRIu64 "\n"), return(1); error_out: - while (i > 1 && i <= da_cursor->active) { + while (i > 1 && i <= da_cursor->active) { libxfs_putbuf(da_cursor->level[i].bp); i++; } @@ -358,7 +358,7 @@ verify_final_dir2_path(xfs_mount_t *mp, * that all entries are used, encountered and expected hashvals * match, etc. */ - if (entry != nodehdr.count - 1) { + if (entry != nodehdr.count - 1) { do_warn( _("directory block used/count inconsistency - %d / %hu\n"), entry, nodehdr.count); @@ -368,20 +368,20 @@ verify_final_dir2_path(xfs_mount_t *mp, * hash values monotonically increasing ??? */ if (cursor->level[this_level].hashval >= - be32_to_cpu(btree[entry].hashval)) { + be32_to_cpu(btree[entry].hashval)) { do_warn(_("directory/attribute block hashvalue inconsistency, " "expected > %u / saw %u\n"), cursor->level[this_level].hashval, be32_to_cpu(btree[entry].hashval)); bad++; } - if (nodehdr.forw != 0) { + if (nodehdr.forw != 0) { do_warn(_("bad directory/attribute forward block pointer, " "expected 0, saw %u\n"), nodehdr.forw); bad++; } - if (bad) { + if (bad) { do_warn(_("bad directory block in inode %" PRIu64 "\n"), cursor->ino); return(1); } @@ -408,8 +408,8 @@ verify_final_dir2_path(xfs_mount_t *mp, } if (cursor->level[p_level].hashval != - be32_to_cpu(btree[entry].hashval)) { - if (!no_modify) { + be32_to_cpu(btree[entry].hashval)) { + if (!no_modify) { do_warn( _("correcting bad hashval in non-leaf dir block\n" "\tin (level %d) in inode %" PRIu64 ".\n"), @@ -417,7 +417,7 @@ _("correcting bad hashval in non-leaf dir block\n" btree[entry].hashval = cpu_to_be32( cursor->level[p_level].hashval); cursor->level[this_level].dirty++; - } else { + } else { do_warn( _("would correct bad hashval in non-leaf dir block\n" "\tin (level %d) in inode %" PRIu64 ".\n"), @@ -454,7 +454,7 @@ _("would correct bad hashval in non-leaf dir block\n" return(0); } /* - * set hashvalue to correctl reflect the now-validated + * set hashvalue to correctly reflect the now-validated * last entry in this block and continue upwards validation */ cursor->level[this_level].hashval = hashval; @@ -536,7 +536,7 @@ verify_dir2_path(xfs_mount_t *mp, * block and move on to the next block. * and update cursor value for said level */ - if (entry >= nodehdr.count) { + if (entry >= nodehdr.count) { /* * update the hash value for this level before * validating it. bno value should be ok since @@ -599,27 +599,27 @@ _("bad magic number %x in block %u for directory inode %" PRIu64 "\n"), dabno, cursor->ino); bad++; } - if (nodehdr.back != cursor->level[this_level].bno) { + if (nodehdr.back != cursor->level[this_level].bno) { do_warn( _("bad back pointer in block %u for directory inode %" PRIu64 "\n"), dabno, cursor->ino); bad++; } - if (nodehdr.count > geo->node_ents) { + if (nodehdr.count > geo->node_ents) { do_warn( _("entry count %d too large in block %u for directory inode %" PRIu64 "\n"), nodehdr.count, dabno, cursor->ino); bad++; } - if (nodehdr.level != this_level) { + if (nodehdr.level != this_level) { do_warn( _("bad level %d in block %u for directory inode %" PRIu64 "\n"), nodehdr.level, dabno, cursor->ino); bad++; } - if (bad) { + if (bad) { #ifdef XR_DIR_TRACE fprintf(stderr, "verify_dir2_path returns 1 (bad) #4\n"); #endif @@ -643,6 +643,8 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), libxfs_writebuf(cursor->level[this_level].bp, 0); else libxfs_putbuf(cursor->level[this_level].bp); + + /* switch cursor to point at the new buffer we just read */ cursor->level[this_level].bp = bp; cursor->level[this_level].dirty = 0; cursor->level[this_level].bno = dabno; @@ -670,8 +672,8 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), * block against the hashval in the current entry */ if (cursor->level[p_level].hashval != - be32_to_cpu(btree[entry].hashval)) { - if (!no_modify) { + be32_to_cpu(btree[entry].hashval)) { + if (!no_modify) { do_warn( _("correcting bad hashval in interior dir block\n" "\tin (level %d) in inode %" PRIu64 ".\n"), @@ -679,7 +681,7 @@ _("correcting bad hashval in interior dir block\n" btree[entry].hashval = cpu_to_be32( cursor->level[p_level].hashval); cursor->level[this_level].dirty++; - } else { + } else { do_warn( _("would correct bad hashval in interior dir block\n" "\tin (level %d) in inode %" PRIu64 ".\n"), -- 1.7.1 From sandeen@sandeen.net Wed Sep 9 14:34:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 34A327F6F for ; Wed, 9 Sep 2015 14:34:20 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id C41AEAC008 for ; Wed, 9 Sep 2015 12:34:16 -0700 (PDT) X-ASG-Debug-ID: 1441827254-04bdf04db62e1a0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id TzWQs14WznkwsgyI for ; Wed, 09 Sep 2015 12:34:15 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id 8CC0E63C77A5; Wed, 9 Sep 2015 14:34:14 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 01/13] xfs_repair: remove trace-only 'n' member from da_level_state Date: Wed, 9 Sep 2015 14:33:59 -0500 X-ASG-Orig-Subj: [PATCH 01/13] xfs_repair: remove trace-only 'n' member from da_level_state Message-Id: <1441827251-13128-2-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827254 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- The da_level_state structure contains an 'n' member when XR_DIR_TRACE is enabled, which is a) write only, and b) set by a macro which doesn't exist (XFS_BUF_TO_DA_INTNODE) Removing this structure member fixes compilation with XR_DIR_TRACE enabled, and also makes da_level_state identical to dir2_level_state, so the two can be combined later. Signed-off-by: Eric Sandeen Signed-off-by: Eric Sandeen --- repair/attr_repair.c | 9 --------- 1 files changed, 0 insertions(+), 9 deletions(-) diff --git a/repair/attr_repair.c b/repair/attr_repair.c index debe9e8..d63bc87 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -59,9 +59,6 @@ typedef unsigned char da_freemap_t; */ typedef struct da_level_state { xfs_buf_t *bp; /* block bp */ -#ifdef XR_DIR_TRACE - xfs_da_intnode_t *n; /* bp data */ -#endif xfs_dablk_t bno; /* file block number */ xfs_dahash_t hashval; /* last verified hashval */ int index; /* current index in block */ @@ -232,9 +229,6 @@ traverse_int_dablock(xfs_mount_t *mp, da_cursor->level[i].bp = bp; da_cursor->level[i].bno = bno; da_cursor->level[i].index = 0; -#ifdef XR_DIR_TRACE - da_cursor->level[i].n = XFS_BUF_TO_DA_INTNODE(bp); -#endif /* * set up new bno for next level down @@ -624,9 +618,6 @@ verify_da_path(xfs_mount_t *mp, cursor->level[this_level].bno = dabno; cursor->level[this_level].hashval = be32_to_cpu(btree[0].hashval); -#ifdef XR_DIR_TRACE - cursor->level[this_level].n = newnode; -#endif entry = cursor->level[this_level].index = 0; /* -- 1.7.1 From sandeen@sandeen.net Wed Sep 9 14:34:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 2C5897F5F for ; Wed, 9 Sep 2015 14:34:20 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id A07EDAC002 for ; Wed, 9 Sep 2015 12:34:19 -0700 (PDT) X-ASG-Debug-ID: 1441827255-04cb6c355a2b610002-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id 7upnzcexg3mjxXzH for ; Wed, 09 Sep 2015 12:34:17 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id 49CAE653B8A4; Wed, 9 Sep 2015 14:34:15 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 13/13] xfs_repair: Fix up warning strings in da_util.c Date: Wed, 9 Sep 2015 14:34:11 -0500 X-ASG-Orig-Subj: [PATCH 13/13] xfs_repair: Fix up warning strings in da_util.c Message-Id: <1441827251-13128-14-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Switch the warning messages based on which fork has encountered the problem. Signed-off-by: Eric Sandeen Signed-off-by: Eric Sandeen --- repair/attr_repair.c | 2 +- repair/da_util.c | 97 +++++++++++++++++++++++++++----------------------- repair/da_util.h | 3 +- repair/dir2.c | 2 +- 4 files changed, 56 insertions(+), 48 deletions(-) diff --git a/repair/attr_repair.c b/repair/attr_repair.c index 0d3b7a5..da2800d 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -849,7 +849,7 @@ process_leaf_attr_level(xfs_mount_t *mp, libxfs_putbuf(bp); } while (da_bno != 0); - if (verify_final_da_path(mp, da_cursor, 0)) { + if (verify_final_da_path(mp, da_cursor, 0, XFS_ATTR_FORK)) { /* * verify the final path up (right-hand-side) if still ok */ diff --git a/repair/da_util.c b/repair/da_util.c index e5d5535..89d41cc 100644 --- a/repair/da_util.c +++ b/repair/da_util.c @@ -67,6 +67,7 @@ namecheck(char *name, int length) /* * Multibuffer handling. * V2 directory blocks can be noncontiguous, needing multiple buffers. + * attr blocks are single blocks; this code handles that as well. */ struct xfs_buf * da_read_buf( @@ -101,6 +102,8 @@ da_read_buf( return bp; } +#define FORKNAME(type) (type == XFS_DATA_FORK ? _("directory") : _("attribute")) + /* * walk tree from root to the left-most leaf block reading in * blocks and setting up cursor. passes back file block number of the @@ -158,8 +161,8 @@ traverse_int_dablock( if (!bp) { do_warn( -_("can't read block %u for directory inode %" PRIu64 "\n"), - bno, da_cursor->ino); +_("can't read %s block %u for inode %" PRIu64 "\n"), + FORKNAME(whichfork), bno, da_cursor->ino); goto error_out; } @@ -182,8 +185,8 @@ _("found non-root LEAFN node in inode %" PRIu64 " bno = %u\n"), if (nodehdr.magic != XFS_DA_NODE_MAGIC && nodehdr.magic != XFS_DA3_NODE_MAGIC) { do_warn( -_("bad dir magic number 0x%x in inode %" PRIu64 " bno = %u\n"), - nodehdr.magic, +_("bad %s magic number 0x%x in inode %" PRIu64 " bno = %u\n"), + FORKNAME(whichfork), nodehdr.magic, da_cursor->ino, bno); libxfs_putbuf(bp); goto error_out; @@ -193,16 +196,17 @@ _("bad dir magic number 0x%x in inode %" PRIu64 " bno = %u\n"), if (bp->b_error == -EFSBADCRC || bp->b_error == -EFSCORRUPTED) { libxfs_putbuf(bp); do_warn( -_("corrupt tree block %u for directory inode %" PRIu64 "\n"), - bno, da_cursor->ino); +_("corrupt %s tree block %u for inode %" PRIu64 "\n"), + FORKNAME(whichfork), bno, da_cursor->ino); goto error_out; } btree = M_DIROPS(mp)->node_tree_p(node); if (nodehdr.count > geo->node_ents) { do_warn( -_("bad record count in inode %" PRIu64 ", count = %d, max = %d\n"), - da_cursor->ino, nodehdr.count, geo->node_ents); +_("bad %s record count in inode %" PRIu64 ", count = %d, max = %d\n"), + FORKNAME(whichfork), da_cursor->ino, + nodehdr.count, geo->node_ents); libxfs_putbuf(bp); goto error_out; } @@ -225,8 +229,8 @@ _("bad header depth for directory inode %" PRIu64 "\n"), i--; } else { do_warn( -_("bad directory btree for directory inode %" PRIu64 "\n"), - da_cursor->ino); +_("bad %s btree for inode %" PRIu64 "\n"), + FORKNAME(whichfork), da_cursor->ino); libxfs_putbuf(bp); goto error_out; } @@ -321,7 +325,8 @@ int verify_final_da_path( xfs_mount_t *mp, da_bt_cursor_t *cursor, - const int p_level) + const int p_level, + int whichfork) { xfs_da_intnode_t *node; xfs_dahash_t hashval; @@ -352,8 +357,8 @@ verify_final_da_path( */ if (entry != nodehdr.count - 1) { do_warn( - _("directory block used/count inconsistency - %d/%hu\n"), - entry, nodehdr.count); +_("%s block used/count inconsistency - %d/%hu\n"), + FORKNAME(whichfork), entry, nodehdr.count); bad++; } /* @@ -361,25 +366,27 @@ verify_final_da_path( */ if (cursor->level[this_level].hashval >= be32_to_cpu(btree[entry].hashval)) { - do_warn(_("directory/attribute block hashvalue inconsistency, " - "expected > %u / saw %u\n"), + do_warn( +_("%s block hashvalue inconsistency, expected > %u / saw %u\n"), + FORKNAME(whichfork), cursor->level[this_level].hashval, be32_to_cpu(btree[entry].hashval)); bad++; } if (nodehdr.forw != 0) { - do_warn(_("bad directory/attribute forward block pointer, " - "expected 0, saw %u\n"), - nodehdr.forw); + do_warn( +_("bad %s forward block pointer, expected 0, saw %u\n"), + FORKNAME(whichfork), nodehdr.forw); bad++; } if (bad) { - do_warn(_("bad directory block in inode %" PRIu64 "\n"), cursor->ino); + do_warn(_("bad %s block in inode %" PRIu64 "\n"), + FORKNAME(whichfork), cursor->ino); return 1; } /* * keep track of greatest block # -- that gets - * us the length of the directory + * us the length of the directory/attribute */ if (cursor->level[this_level].bno > cursor->greatest_bno) cursor->greatest_bno = cursor->level[this_level].bno; @@ -389,9 +396,9 @@ verify_final_da_path( */ if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { #ifdef XR_DIR_TRACE - fprintf(stderr, "bad directory btree pointer, child bno should " + fprintf(stderr, "bad %s btree pointer, child bno should " "be %d, block bno is %d, hashval is %u\n", - be16_to_cpu(btree[entry].before), + FORKNAME(whichfork), be16_to_cpu(btree[entry].before), cursor->level[p_level].bno, cursor->level[p_level].hashval); fprintf(stderr, "verify_final_da_path returns 1 (bad) #1a\n"); @@ -403,17 +410,17 @@ verify_final_da_path( be32_to_cpu(btree[entry].hashval)) { if (!no_modify) { do_warn( -_("correcting bad hashval in non-leaf dir block\n" +_("correcting bad hashval in non-leaf %s block\n" "\tin (level %d) in inode %" PRIu64 ".\n"), - this_level, cursor->ino); + FORKNAME(whichfork), this_level, cursor->ino); btree[entry].hashval = cpu_to_be32( cursor->level[p_level].hashval); cursor->level[this_level].dirty++; } else { do_warn( -_("would correct bad hashval in non-leaf dir block\n" +_("would correct bad hashval in non-leaf %s block\n" "\tin (level %d) in inode %" PRIu64 ".\n"), - this_level, cursor->ino); + FORKNAME(whichfork), this_level, cursor->ino); } } @@ -451,7 +458,7 @@ _("would correct bad hashval in non-leaf dir block\n" */ cursor->level[this_level].hashval = hashval; - return verify_final_da_path(mp, cursor, this_level); + return verify_final_da_path(mp, cursor, this_level, whichfork); } /* @@ -564,8 +571,8 @@ verify_da_path( &bmp, &lbmp); if (nex == 0) { do_warn( -_("can't get map info for block %u of directory inode %" PRIu64 "\n"), - dabno, cursor->ino); +_("can't get map info for %s block %u of inode %" PRIu64 "\n"), + FORKNAME(whichfork), dabno, cursor->ino); return 1; } @@ -575,8 +582,8 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), if (!bp) { do_warn( -_("can't read block %u for directory inode %" PRIu64 "\n"), - dabno, cursor->ino); +_("can't read %s block %u for inode %" PRIu64 "\n"), + FORKNAME(whichfork), dabno, cursor->ino); return 1; } @@ -592,28 +599,28 @@ _("can't read block %u for directory inode %" PRIu64 "\n"), if (nodehdr.magic != XFS_DA_NODE_MAGIC && nodehdr.magic != XFS_DA3_NODE_MAGIC) { do_warn( -_("bad magic number %x in block %u for directory inode %" PRIu64 "\n"), - nodehdr.magic, +_("bad magic number %x in %s block %u for inode %" PRIu64 "\n"), + nodehdr.magic, FORKNAME(whichfork), dabno, cursor->ino); bad++; } if (nodehdr.back != cursor->level[this_level].bno) { do_warn( -_("bad back pointer in block %u for directory inode %" PRIu64 "\n"), - dabno, cursor->ino); +_("bad back pointer in %s block %u for inode %" PRIu64 "\n"), + FORKNAME(whichfork), dabno, cursor->ino); bad++; } if (nodehdr.count > geo->node_ents) { do_warn( -_("entry count %d too large in block %u for directory inode %" PRIu64 "\n"), - nodehdr.count, +_("entry count %d too large in %s block %u for inode %" PRIu64 "\n"), + nodehdr.count, FORKNAME(whichfork), dabno, cursor->ino); bad++; } if (nodehdr.level != this_level) { do_warn( -_("bad level %d in block %u for directory inode %" PRIu64 "\n"), - nodehdr.level, +_("bad level %d in %s block %u for inode %" PRIu64 "\n"), + nodehdr.level, FORKNAME(whichfork), dabno, cursor->ino); bad++; } @@ -659,9 +666,9 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), */ if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { #ifdef XR_DIR_TRACE - fprintf(stderr, "bad directory btree pointer, child bno " + fprintf(stderr, "bad %s btree pointer, child bno " "should be %d, block bno is %d, hashval is %u\n", - be32_to_cpu(btree[entry].before), + FORKNAME(whichfork), be32_to_cpu(btree[entry].before), cursor->level[p_level].bno, cursor->level[p_level].hashval); fprintf(stderr, "verify_da_path returns 1 (bad) #1a\n"); @@ -676,17 +683,17 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), be32_to_cpu(btree[entry].hashval)) { if (!no_modify) { do_warn( -_("correcting bad hashval in interior dir block\n" +_("correcting bad hashval in interior %s block\n" "\tin (level %d) in inode %" PRIu64 ".\n"), - this_level, cursor->ino); + FORKNAME(whichfork), this_level, cursor->ino); btree[entry].hashval = cpu_to_be32( cursor->level[p_level].hashval); cursor->level[this_level].dirty++; } else { do_warn( -_("would correct bad hashval in interior dir block\n" +_("would correct bad hashval in interior %s block\n" "\tin (level %d) in inode %" PRIu64 ".\n"), - this_level, cursor->ino); + FORKNAME(whichfork), this_level, cursor->ino); } } /* diff --git a/repair/da_util.h b/repair/da_util.h index 7971d63..442f9f1 100644 --- a/repair/da_util.h +++ b/repair/da_util.h @@ -78,5 +78,6 @@ int verify_final_da_path( xfs_mount_t *mp, da_bt_cursor_t *cursor, - const int p_level); + const int p_level, + int whichfork); #endif /* _XR_DA_UTIL_H */ diff --git a/repair/dir2.c b/repair/dir2.c index 492b3e7..61912d1 100644 --- a/repair/dir2.c +++ b/repair/dir2.c @@ -1179,7 +1179,7 @@ _("bad sibling back pointer for block %u in directory inode %" PRIu64 "\n"), } else libxfs_putbuf(bp); } while (da_bno != 0); - if (verify_final_da_path(mp, da_cursor, 0)) { + if (verify_final_da_path(mp, da_cursor, 0, XFS_DATA_FORK)) { /* * Verify the final path up (right-hand-side) if still ok. */ -- 1.7.1 From sandeen@sandeen.net Wed Sep 9 14:34:19 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id C8D027F6D for ; Wed, 9 Sep 2015 14:34:19 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id B8A378F8049 for ; Wed, 9 Sep 2015 12:34:16 -0700 (PDT) X-ASG-Debug-ID: 1441827254-04cbb005ea2d2e0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id O8Hhu16bK0F02tqd for ; Wed, 09 Sep 2015 12:34:14 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id A38B263C77A6; Wed, 9 Sep 2015 14:34:14 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 02/13] xfs_repair: remove type from da & dir2 cursors Date: Wed, 9 Sep 2015 14:34:00 -0500 X-ASG-Orig-Subj: [PATCH 02/13] xfs_repair: remove type from da & dir2 cursors Message-Id: <1441827251-13128-3-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827254 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- The type field in these cursors is only set (and only in the attr code), and it's never read; just remove it. Signed-off-by: Eric Sandeen Signed-off-by: Eric Sandeen --- repair/attr_repair.c | 2 -- repair/dir2.h | 1 - 2 files changed, 0 insertions(+), 3 deletions(-) diff --git a/repair/attr_repair.c b/repair/attr_repair.c index d63bc87..f29a5bd 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -67,7 +67,6 @@ typedef struct da_level_state { typedef struct da_bt_cursor { int active; /* highest level in tree (# levels-1) */ - int type; /* 0 if dir, 1 if attr */ xfs_ino_t ino; xfs_dablk_t greatest_bno; xfs_dinode_t *dip; @@ -1477,7 +1476,6 @@ process_node_attr( */ memset(&da_cursor, 0, sizeof(da_bt_cursor_t)); da_cursor.active = 0; - da_cursor.type = 0; da_cursor.ino = ino; da_cursor.dip = dip; da_cursor.greatest_bno = 0; diff --git a/repair/dir2.h b/repair/dir2.h index df68d5c..3cc1941 100644 --- a/repair/dir2.h +++ b/repair/dir2.h @@ -51,7 +51,6 @@ typedef struct dir2_level_state { typedef struct dir2_bt_cursor { int active; /* highest level in tree (# levels-1) */ - int type; /* 0 if dir, 1 if attr */ xfs_ino_t ino; xfs_dablk_t greatest_bno; xfs_dinode_t *dip; -- 1.7.1 From sandeen@sandeen.net Wed Sep 9 14:34:21 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 5AD5B7F72 for ; Wed, 9 Sep 2015 14:34:20 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id D98BAAC004 for ; Wed, 9 Sep 2015 12:34:16 -0700 (PDT) X-ASG-Debug-ID: 1441827254-04cbb005e92d2e0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id BLU3bAEXifQSnZPn for ; Wed, 09 Sep 2015 12:34:14 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id B165863CBFD4; Wed, 9 Sep 2015 14:34:14 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 03/13] xfs_repair: make CRC checking consistent in path verification Date: Wed, 9 Sep 2015 14:34:01 -0500 X-ASG-Orig-Subj: [PATCH 03/13] xfs_repair: make CRC checking consistent in path verification Message-Id: <1441827251-13128-4-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827254 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- verify_da_path and verify_dir2_path both take steps to re-compute the CRC of the block if it otherwise looks ok and no other changes are needed. They do this inside a loop, but the approach differs; verify_da_path expects its caller to check the first buffer prior to the loop, and verify_dir2_path expects its caller to check the last buffer after the loop. Make this consistent by semi-arbitrarily choosing to make verify_da_path (and its caller) match the method used by verify_dir2_path, and check the last buffer after the loop is done. Signed-off-by: Eric Sandeen Signed-off-by: Eric Sandeen --- repair/attr_repair.c | 24 ++++++++++++++---------- 1 files changed, 14 insertions(+), 10 deletions(-) diff --git a/repair/attr_repair.c b/repair/attr_repair.c index f29a5bd..aba0782 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -606,6 +606,14 @@ verify_da_path(xfs_mount_t *mp, ASSERT(cursor->level[this_level].dirty == 0 || (cursor->level[this_level].dirty && !no_modify)); + /* + * If block looks ok but CRC didn't match, make sure to + * recompute it. + */ + if (!no_modify && + cursor->level[this_level].bp->b_error == -EFSBADCRC) + cursor->level[this_level].dirty = 1; + if (cursor->level[this_level].dirty && !no_modify) libxfs_writebuf(cursor->level[this_level].bp, 0); else @@ -618,14 +626,6 @@ verify_da_path(xfs_mount_t *mp, cursor->level[this_level].hashval = be32_to_cpu(btree[0].hashval); entry = cursor->level[this_level].index = 0; - - /* - * We want to rewrite the buffer on a CRC error seeing as it - * contains what appears to be a valid node block, but only if - * we are fixing errors. - */ - if (bp->b_error == -EFSBADCRC && !no_modify) - cursor->level[this_level].dirty++; } /* * ditto for block numbers @@ -1363,8 +1363,6 @@ process_leaf_attr_level(xfs_mount_t *mp, da_bno, dev_bno, ino); goto error_out; } - if (bp->b_error == -EFSBADCRC) - repair++; leaf = bp->b_addr; xfs_attr3_leaf_hdr_from_disk(mp->m_attr_geo, &leafhdr, leaf); @@ -1419,6 +1417,12 @@ process_leaf_attr_level(xfs_mount_t *mp, } current_hashval = greatest_hashval; + /* + * If block looks ok but CRC didn't match, make sure to + * recompute it. + */ + if (!no_modify && bp->b_error == -EFSBADCRC) + repair++; if (repair && !no_modify) libxfs_writebuf(bp, 0); -- 1.7.1 From sandeen@sandeen.net Wed Sep 9 14:34:26 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 804407F59 for ; Wed, 9 Sep 2015 14:34:26 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id C5DD9AC008 for ; Wed, 9 Sep 2015 12:34:25 -0700 (PDT) X-ASG-Debug-ID: 1441827256-04cb6c355b2b620001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id 6tUcqX3n1CEcNwFf for ; Wed, 09 Sep 2015 12:34:16 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: by sandeen.net (Postfix, from userid 500) id 3BB62653A9A5; Wed, 9 Sep 2015 14:34:15 -0500 (CDT) From: Eric Sandeen To: xfs@oss.sgi.com Subject: [PATCH 12/13] xfs_repair: move common dir2 and attr_repair code to da_util.c Date: Wed, 9 Sep 2015 14:34:10 -0500 X-ASG-Orig-Subj: [PATCH 12/13] xfs_repair: move common dir2 and attr_repair code to da_util.c Message-Id: <1441827251-13128-13-git-send-email-sandeen@sandeen.net> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441827256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Now that dir2.c and attr_repair.c are functionally identical, move the duplicate code into a new file da_util.c, with da_util.h as a header file for the common functions. Last step will be to fix up comments and printfs' to be appropriate for code that checks both dirs and attrs. Signed-off-by: Eric Sandeen Signed-off-by: Eric Sandeen --- repair/Makefile | 6 +- repair/attr_repair.c | 617 +------------------------------------------- repair/da_util.c | 701 ++++++++++++++++++++++++++++++++++++++++++++++++++ repair/da_util.h | 82 ++++++ repair/dir2.c | 649 +--------------------------------------------- repair/dir2.h | 49 ---- 6 files changed, 801 insertions(+), 1303 deletions(-) create mode 100644 repair/da_util.c create mode 100644 repair/da_util.h diff --git a/repair/Makefile b/repair/Makefile index 6d84ade..251722b 100644 --- a/repair/Makefile +++ b/repair/Makefile @@ -10,11 +10,11 @@ LSRCFILES = README LTCOMMAND = xfs_repair HFILES = agheader.h attr_repair.h avl.h avl64.h bmap.h btree.h \ - dinode.h dir2.h err_protos.h globals.h incore.h protos.h rt.h \ - progress.h scan.h versions.h prefetch.h threads.h + da_util.h dinode.h dir2.h err_protos.h globals.h incore.h protos.h \ + rt.h progress.h scan.h versions.h prefetch.h threads.h CFILES = agheader.c attr_repair.c avl.c avl64.c bmap.c btree.c \ - dino_chunks.c dinode.c dir2.c globals.c incore.c \ + da_util.c dino_chunks.c dinode.c dir2.c globals.c incore.c \ incore_bmc.c init.c incore_ext.c incore_ino.c phase1.c \ phase2.c phase3.c phase4.c phase5.c phase6.c phase7.c \ progress.c prefetch.c rt.c sb.c scan.c threads.c \ diff --git a/repair/attr_repair.c b/repair/attr_repair.c index 0804a22..0d3b7a5 100644 --- a/repair/attr_repair.c +++ b/repair/attr_repair.c @@ -24,6 +24,7 @@ #include "bmap.h" #include "protos.h" #include "dir2.h" +#include "da_util.h" static int xfs_acl_valid(struct xfs_mount *mp, struct xfs_acl *daclp); static int xfs_mac_valid(xfs_mac_label_t *lp); @@ -39,43 +40,6 @@ static int xfs_mac_valid(xfs_mac_label_t *lp); typedef unsigned char da_freemap_t; /* - * the cursor gets passed up and down the da btree processing - * routines. The interior block processing routines use the - * cursor to determine if the pointers to and from the preceding - * and succeeding sibling blocks are ok and whether the values in - * the current block are consistent with the entries in the parent - * nodes. When a block is traversed, a parent-verification routine - * is called to verify if the next logical entry in the next level up - * is consistent with the greatest hashval in the next block of the - * current level. The verification routine is itself recursive and - * calls itself if it has to traverse an interior block to get - * the next logical entry. The routine recurses upwards through - * the tree until it finds a block where it can simply step to - * the next entry. The hashval in that entry should be equal to - * the hashval being passed to it (the greatest hashval in the block - * that the entry points to). If that isn't true, then the tree - * is blown and we need to trash it, salvage and trash it, or fix it. - * Currently, we just trash it. - */ -typedef struct da_level_state { - xfs_buf_t *bp; /* block bp */ - xfs_dablk_t bno; /* file block number */ - xfs_dahash_t hashval; /* last verified hashval */ - int index; /* current index in block */ - int dirty; /* is buffer dirty ? (1 == yes) */ -} da_level_state_t; - -typedef struct da_bt_cursor { - int active; /* highest level in tree (# levels-1) */ - xfs_ino_t ino; - xfs_dablk_t greatest_bno; - xfs_dinode_t *dip; - da_level_state_t level[XFS_DA_NODE_MAXDEPTH]; - struct blkmap *blkmap; -} da_bt_cursor_t; - - -/* * Allocate a freespace map for directory or attr leaf blocks (1 bit per byte) * 1 == used, 0 == free. */ @@ -127,577 +91,6 @@ set_da_freemap(xfs_mount_t *mp, da_freemap_t *map, int start, int stop) } /* - * walk tree from root to the left-most leaf block reading in - * blocks and setting up cursor. passes back file block number of the - * left-most leaf block if successful (bno). returns 1 if successful, - * 0 if unsuccessful. - */ -static int -traverse_int_dablock(xfs_mount_t *mp, - da_bt_cursor_t *da_cursor, - xfs_dablk_t *rbno, - int whichfork) -{ - bmap_ext_t *bmp; - xfs_dablk_t bno; - int i; - int nex; - xfs_da_intnode_t *node; - bmap_ext_t lbmp; - xfs_fsblock_t fsbno; - xfs_buf_t *bp; - struct xfs_da_geometry *geo; - struct xfs_da_node_entry *btree; - struct xfs_da3_icnode_hdr nodehdr; - - geo = mp->m_attr_geo; - - /* - * traverse down left-side of tree until we hit the - * left-most leaf block setting up the btree cursor along - * the way. - */ - bno = 0; - i = -1; - node = NULL; - da_cursor->active = 0; - - do { - /* - * read in each block along the way and set up cursor - */ - nex = blkmap_getn(da_cursor->blkmap, bno, - geo->fsbcount, &bmp, &lbmp); - - if (nex == 0) - goto error_out; - - bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); - if (bmp != &lbmp) - free(bmp); - - if (!bp) { - do_warn( - _("can't read block %u (fsbno %" PRIu64 ") for attrbute fork of inode %" PRIu64 "\n"), - bno, fsbno, da_cursor->ino); - goto error_out; - } - - node = bp->b_addr; - M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); - - if (nodehdr.magic != XFS_DA_NODE_MAGIC && - nodehdr.magic != XFS_DA3_NODE_MAGIC) { - do_warn(_("bad dir/attr magic number in inode %" PRIu64 ", " - "file bno = %u, fsbno = %" PRIu64 "\n"), - da_cursor->ino, bno, fsbno); - libxfs_putbuf(bp); - goto error_out; - } - - /* corrupt node; rebuild the dir. */ - if (bp->b_error == -EFSBADCRC || bp->b_error == -EFSCORRUPTED) { - libxfs_putbuf(bp); - do_warn( -_("corrupt tree block %u for directory inode %" PRIu64 "\n"), - bno, da_cursor->ino); - goto error_out; - } - - btree = M_DIROPS(mp)->node_tree_p(node); - if (nodehdr.count > geo->node_ents) { - do_warn(_("bad record count in inode %" PRIu64 ", " - "count = %d, max = %d\n"), - da_cursor->ino, nodehdr.count, geo->node_ents); - libxfs_putbuf(bp); - goto error_out; - } - - /* - * maintain level counter - */ - if (i == -1) { - i = da_cursor->active = nodehdr.level; - if (i < 1 || i >= XFS_DA_NODE_MAXDEPTH) { - do_warn( -_("bad header depth for directory inode %" PRIu64 "\n"), - da_cursor->ino); - libxfs_putbuf(bp); - i = -1; - goto error_out; - } - } else { - if (nodehdr.level == i - 1) { - i--; - } else { - do_warn(_("bad attribute fork btree " - "for inode %" PRIu64 "\n"), - da_cursor->ino); - libxfs_putbuf(bp); - goto error_out; - } - } - - da_cursor->level[i].hashval = be32_to_cpu(btree[0].hashval); - da_cursor->level[i].bp = bp; - da_cursor->level[i].bno = bno; - da_cursor->level[i].index = 0; - - /* - * set up new bno for next level down - */ - bno = be32_to_cpu(btree[0].before); - } while (node != NULL && i > 1); - - /* - * now return block number and get out - */ - *rbno = da_cursor->level[0].bno = bno; - return(1); - -error_out: - while (i > 1 && i <= da_cursor->active) { - libxfs_putbuf(da_cursor->level[i].bp); - i++; - } - - return(0); -} - -/* - * blow out buffer for this level and all the rest above as well - * if error == 0, we are not expecting to encounter any unreleased - * buffers (e.g. if we do, it's a mistake). if error == 1, we're - * in an error-handling case so unreleased buffers may exist. - */ -static void -release_da_cursor_int(xfs_mount_t *mp, - da_bt_cursor_t *cursor, - int prev_level, - int error) -{ - int level = prev_level + 1; - - if (cursor->level[level].bp != NULL) { - if (!error) { - do_warn(_("release_da_cursor_int got unexpected " - "non-null bp, dabno = %u\n"), - cursor->level[level].bno); - } - ASSERT(error != 0); - - libxfs_putbuf(cursor->level[level].bp); - cursor->level[level].bp = NULL; - } - - if (level < cursor->active) - release_da_cursor_int(mp, cursor, level, error); - - return; -} - -static void -release_da_cursor(xfs_mount_t *mp, - da_bt_cursor_t *cursor, - int prev_level) -{ - release_da_cursor_int(mp, cursor, prev_level, 0); -} - -static void -err_release_da_cursor(xfs_mount_t *mp, - da_bt_cursor_t *cursor, - int prev_level) -{ - release_da_cursor_int(mp, cursor, prev_level, 1); -} - -/* - * make sure that all entries in all blocks along the right side of - * of the tree are used and hashval's are consistent. level is the - * level of the descendent block. returns 0 if good (even if it had - * to be fixed up), and 1 if bad. The right edge of the tree is - * technically a block boundary. this routine should be used then - * instead of verify_da_path(). - */ -static int -verify_final_da_path(xfs_mount_t *mp, - da_bt_cursor_t *cursor, - const int p_level) -{ - xfs_da_intnode_t *node; - xfs_dahash_t hashval; - int bad = 0; - int entry; - int this_level = p_level + 1; - struct xfs_da_node_entry *btree; - struct xfs_da3_icnode_hdr nodehdr; - -#ifdef XR_DIR_TRACE - fprintf(stderr, "in verify_final_da_path, this_level = %d\n", - this_level); -#endif - /* - * the index should point to the next "unprocessed" entry - * in the block which should be the final (rightmost) entry - */ - entry = cursor->level[this_level].index; - node = cursor->level[this_level].bp->b_addr; - btree = M_DIROPS(mp)->node_tree_p(node); - M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); - - /* - * check internal block consistency on this level -- ensure - * that all entries are used, encountered and expected hashvals - * match, etc. - */ - if (entry != nodehdr.count - 1) { - do_warn(_("directory/attribute block used/count " - "inconsistency - %d/%hu\n"), - entry, nodehdr.count); - bad++; - } - /* - * hash values monotonically increasing ??? - */ - if (cursor->level[this_level].hashval >= - be32_to_cpu(btree[entry].hashval)) { - do_warn(_("directory/attribute block hashvalue inconsistency, " - "expected > %u / saw %u\n"), - cursor->level[this_level].hashval, - be32_to_cpu(btree[entry].hashval)); - bad++; - } - if (nodehdr.forw != 0) { - do_warn(_("bad directory/attribute forward block pointer, " - "expected 0, saw %u\n"), - nodehdr.forw); - bad++; - } - if (bad) { - do_warn(_("bad directory block in dir ino %" PRIu64 "\n"), - cursor->ino); - return(1); - } - /* - * keep track of greatest block # -- that gets - * us the length of the directory - */ - if (cursor->level[this_level].bno > cursor->greatest_bno) - cursor->greatest_bno = cursor->level[this_level].bno; - - /* - * ok, now check descendant block number against this level - */ - if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { -#ifdef XR_DIR_TRACE - fprintf(stderr, "bad directory btree pointer, child bno should " - "be %d, block bno is %d, hashval is %u\n", - be16_to_cpu(btree[entry].before), - cursor->level[p_level].bno, - cursor->level[p_level].hashval); - fprintf(stderr, "verify_final_da_path returns 1 (bad) #1a\n"); -#endif - return(1); - } - - if (cursor->level[p_level].hashval != be32_to_cpu(btree[entry].hashval)) { - if (!no_modify) { - do_warn(_("correcting bad hashval in non-leaf " - "dir/attr block\n\tin (level %d) in " - "inode %" PRIu64 ".\n"), - this_level, cursor->ino); - btree[entry].hashval = cpu_to_be32( - cursor->level[p_level].hashval); - cursor->level[this_level].dirty++; - } else { - do_warn(_("would correct bad hashval in non-leaf " - "dir/attr block\n\tin (level %d) in " - "inode %" PRIu64 ".\n"), - this_level, cursor->ino); - } - } - - /* - * Note: squirrel hashval away _before_ releasing the - * buffer, preventing a use-after-free problem. - */ - hashval = be32_to_cpu(btree[entry].hashval); - - /* - * release/write buffer - */ - ASSERT(cursor->level[this_level].dirty == 0 || - (cursor->level[this_level].dirty && !no_modify)); - - if (cursor->level[this_level].dirty && !no_modify) - libxfs_writebuf(cursor->level[this_level].bp, 0); - else - libxfs_putbuf(cursor->level[this_level].bp); - - cursor->level[this_level].bp = NULL; - - /* - * bail out if this is the root block (top of tree) - */ - if (this_level >= cursor->active) { -#ifdef XR_DIR_TRACE - fprintf(stderr, "verify_final_da_path returns 0 (ok)\n"); -#endif - return(0); - } - /* - * set hashvalue to correctly reflect the now-validated - * last entry in this block and continue upwards validation - */ - cursor->level[this_level].hashval = hashval; - return(verify_final_da_path(mp, cursor, this_level)); -} - -/* - * Verifies the path from a descendant block up to the root. - * Should be called when the descendant level traversal hits - * a block boundary before crossing the boundary (reading in a new - * block). - * - * the directory/attr btrees work differently to the other fs btrees. - * each interior block contains records that are - * pairs. The bno is a file bno, not a filesystem bno. The last - * hashvalue in the block will be . BUT unlike - * the freespace btrees, the *last* value in each block gets - * propagated up the tree instead of the first value in each block. - * that is, the interior records point to child blocks and the *greatest* - * hash value contained by the child block is the one the block above - * uses as the key for the child block. - * - * level is the level of the descendent block. returns 0 if good, - * and 1 if bad. The descendant block may be a leaf block. - * - * the invariant here is that the values in the cursor for the - * levels beneath this level (this_level) and the cursor index - * for this level *must* be valid. - * - * that is, the hashval/bno info is accurate for all - * DESCENDANTS and match what the node[index] information - * for the current index in the cursor for this level. - * - * the index values in the cursor for the descendant level - * are allowed to be off by one as they will reflect the - * next entry at those levels to be processed. - * - * the hashvalue for the current level can't be set until - * we hit the last entry in the block so, it's garbage - * until set by this routine. - * - * bno and bp for the current block/level are always valid - * since they have to be set so we can get a buffer for the - * block. - */ -static int -verify_da_path(xfs_mount_t *mp, - da_bt_cursor_t *cursor, - const int p_level) -{ - xfs_da_intnode_t *node; - xfs_da_intnode_t *newnode; - xfs_fsblock_t fsbno; - xfs_dablk_t dabno; - xfs_buf_t *bp; - int bad; - int entry; - int this_level = p_level + 1; - bmap_ext_t *bmp; - int nex; - bmap_ext_t lbmp; - struct xfs_da_geometry *geo; - struct xfs_da_node_entry *btree; - struct xfs_da3_icnode_hdr nodehdr; - - geo = mp->m_attr_geo; - - /* - * index is currently set to point to the entry that - * should be processed now in this level. - */ - entry = cursor->level[this_level].index; - node = cursor->level[this_level].bp->b_addr; - btree = M_DIROPS(mp)->node_tree_p(node); - M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); - - /* - * if this block is out of entries, validate this - * block and move on to the next block. - * and update cursor value for said level - */ - if (entry >= nodehdr.count) { - /* - * update the hash value for this level before - * validating it. bno value should be ok since - * it was set when the block was first read in. - */ - cursor->level[this_level].hashval = - be32_to_cpu(btree[entry - 1].hashval); - - /* - * keep track of greatest block # -- that gets - * us the length of the directory - */ - if (cursor->level[this_level].bno > cursor->greatest_bno) - cursor->greatest_bno = cursor->level[this_level].bno; - - /* - * validate the path for the current used-up block - * before we trash it - */ - if (verify_da_path(mp, cursor, this_level)) - return(1); - /* - * ok, now get the next buffer and check sibling pointers - */ - dabno = nodehdr.forw; - ASSERT(dabno != 0); - nex = blkmap_getn(cursor->blkmap, dabno, geo->fsbcount, - &bmp, &lbmp); - if (nex == 0) { - do_warn( -_("can't get map info for block %u of directory inode %" PRIu64 "\n"), - dabno, cursor->ino); - return(1); - } - - fsbno = bmp[0].startblock; - - bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); - if (bmp != &lbmp) - free(bmp); - - if (!bp) { - do_warn( - _("can't read block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), - dabno, fsbno, cursor->ino); - return(1); - } - - newnode = bp->b_addr; - btree = M_DIROPS(mp)->node_tree_p(newnode); - M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, newnode); - - /* - * verify magic number and back pointer, sanity-check - * entry count, verify level - */ - bad = 0; - if (nodehdr.magic != XFS_DA_NODE_MAGIC && - nodehdr.magic != XFS_DA3_NODE_MAGIC) { - do_warn( - _("bad magic number %x in block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), - nodehdr.magic, - dabno, fsbno, cursor->ino); - bad++; - } - if (nodehdr.back != cursor->level[this_level].bno) { - do_warn( - _("bad back pointer in block %u (%"PRIu64 ") for directory inode %" PRIu64 "\n"), - dabno, fsbno, cursor->ino); - bad++; - } - if (nodehdr.count > geo->node_ents) { - do_warn( - _("entry count %d too large in block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), - nodehdr.count, - dabno, fsbno, cursor->ino); - bad++; - } - if (nodehdr.level != this_level) { - do_warn( - _("bad level %d in block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), - nodehdr.level, - dabno, fsbno, cursor->ino); - bad++; - } - if (bad) { -#ifdef XR_DIR_TRACE - fprintf(stderr, "verify_da_path returns 1 (bad) #4\n"); -#endif - libxfs_putbuf(bp); - return(1); - } - - /* - * update cursor, write out the *current* level if - * required. don't write out the descendant level - */ - ASSERT(cursor->level[this_level].dirty == 0 || - (cursor->level[this_level].dirty && !no_modify)); - - /* - * If block looks ok but CRC didn't match, make sure to - * recompute it. - */ - if (!no_modify && - cursor->level[this_level].bp->b_error == -EFSBADCRC) - cursor->level[this_level].dirty = 1; - - if (cursor->level[this_level].dirty && !no_modify) - libxfs_writebuf(cursor->level[this_level].bp, 0); - else - libxfs_putbuf(cursor->level[this_level].bp); - - /* switch cursor to point at the new buffer we just read */ - cursor->level[this_level].bp = bp; - cursor->level[this_level].dirty = 0; - cursor->level[this_level].bno = dabno; - cursor->level[this_level].hashval = - be32_to_cpu(btree[0].hashval); - entry = cursor->level[this_level].index = 0; - } - /* - * ditto for block numbers - */ - if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { -#ifdef XR_DIR_TRACE - fprintf(stderr, "bad directory btree pointer, child bno " - "should be %d, block bno is %d, hashval is %u\n", - be32_to_cpu(btree[entry].before), - cursor->level[p_level].bno, - cursor->level[p_level].hashval); - fprintf(stderr, "verify_da_path returns 1 (bad) #1a\n"); -#endif - return(1); - } - /* - * ok, now validate last hashvalue in the descendant - * block against the hashval in the current entry - */ - if (cursor->level[p_level].hashval != - be32_to_cpu(btree[entry].hashval)) { - if (!no_modify) { - do_warn(_("correcting bad hashval in interior " - "dir/attr block\n\tin (level %d) in " - "inode %" PRIu64 ".\n"), - this_level, cursor->ino); - btree[entry].hashval = cpu_to_be32( - cursor->level[p_level].hashval); - cursor->level[this_level].dirty++; - } else { - do_warn(_("would correct bad hashval in interior " - "dir/attr block\n\tin (level %d) in " - "inode %" PRIu64 ".\n"), - this_level, cursor->ino); - } - } - /* - * increment index for this level to point to next entry - * (which should point to the next descendant block) - */ - cursor->level[this_level].index++; -#ifdef XR_DIR_TRACE - fprintf(stderr, "verify_da_path returns 0 (ok)\n"); -#endif - return(0); -} - -/* * For attribute repair, there are 3 formats to worry about. First, is * shortform attributes which reside in the inode. Second is the leaf * form, and lastly the btree. Much of this models after the directory @@ -1435,9 +828,11 @@ process_leaf_attr_level(xfs_mount_t *mp, prev_bno = da_bno; da_bno = leafhdr.forw; - if (da_bno != 0 && verify_da_path(mp, da_cursor, 0)) { - libxfs_putbuf(bp); - goto error_out; + if (da_bno != 0) { + if (verify_da_path(mp, da_cursor, 0, XFS_ATTR_FORK)) { + libxfs_putbuf(bp); + goto error_out; + } } current_hashval = greatest_hashval; diff --git a/repair/da_util.c b/repair/da_util.c new file mode 100644 index 0000000..e5d5535 --- /dev/null +++ b/repair/da_util.c @@ -0,0 +1,701 @@ +/* + * Copyright (c) 2015 Red Hat, Inc. + * All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. + */ + +/* Various utilities for repair of directory and attribute metadata */ + +#include "libxfs.h" +#include "globals.h" +#include "err_protos.h" +#include "bmap.h" +#include "da_util.h" + +/* + * takes a name and length (name need not be null-terminated) + * and returns 1 if the name contains a '/' or a \0, returns 0 + * otherwise + */ +int +namecheck(char *name, int length) +{ + char *c; + int i; + + ASSERT(length < MAXNAMELEN); + + for (c = name, i = 0; i < length; i++, c++) { + if (*c == '/' || *c == '\0') + return 1; + } + + return 0; +} + +/* + * the cursor gets passed up and down the da btree processing + * routines. The interior block processing routines use the + * cursor to determine if the pointers to and from the preceding + * and succeeding sibling blocks are ok and whether the values in + * the current block are consistent with the entries in the parent + * nodes. When a block is traversed, a parent-verification routine + * is called to verify if the next logical entry in the next level up + * is consistent with the greatest hashval in the next block of the + * current level. The verification routine is itself recursive and + * calls itself if it has to traverse an interior block to get + * the next logical entry. The routine recurses upwards through + * the tree until it finds a block where it can simply step to + * the next entry. The hashval in that entry should be equal to + * the hashval being passed to it (the greatest hashval in the block + * that the entry points to). If that isn't true, then the tree + * is blown and we need to trash it, salvage and trash it, or fix it. + * Currently, we just trash it. + */ + +/* + * Multibuffer handling. + * V2 directory blocks can be noncontiguous, needing multiple buffers. + */ +struct xfs_buf * +da_read_buf( + xfs_mount_t *mp, + int nex, + bmap_ext_t *bmp, + const struct xfs_buf_ops *ops) +{ +#define MAP_ARRAY_SZ 4 + struct xfs_buf_map map_array[MAP_ARRAY_SZ]; + struct xfs_buf_map *map; + struct xfs_buf *bp; + int i; + + if (nex > MAP_ARRAY_SZ) { + map = calloc(nex, sizeof(*map)); + if (map == NULL) { + do_error(_("couldn't malloc dir2 buffer list\n")); + exit(1); + } + } else { + /* common case avoids calloc/free */ + map = map_array; + } + for (i = 0; i < nex; i++) { + map[i].bm_bn = XFS_FSB_TO_DADDR(mp, bmp[i].startblock); + map[i].bm_len = XFS_FSB_TO_BB(mp, bmp[i].blockcount); + } + bp = libxfs_readbuf_map(mp->m_dev, map, nex, 0, ops); + if (map != map_array) + free(map); + return bp; +} + +/* + * walk tree from root to the left-most leaf block reading in + * blocks and setting up cursor. passes back file block number of the + * left-most leaf block if successful (bno). returns 1 if successful, + * 0 if unsuccessful. + */ +int +traverse_int_dablock( + xfs_mount_t *mp, + da_bt_cursor_t *da_cursor, + xfs_dablk_t *rbno, + int whichfork) +{ + bmap_ext_t *bmp; + xfs_dablk_t bno; + struct xfs_buf *bp; + int i; + int nex; + xfs_da_intnode_t *node; + bmap_ext_t lbmp; + struct xfs_da_geometry *geo; + struct xfs_da_node_entry *btree; + struct xfs_da3_icnode_hdr nodehdr; + + if (whichfork == XFS_DATA_FORK) { + geo = mp->m_dir_geo; + bno = geo->leafblk; + } else { + geo = mp->m_attr_geo; + bno = 0; + } + + /* + * traverse down left-side of tree until we hit the + * left-most leaf block setting up the btree cursor along + * the way. + */ + i = -1; + node = NULL; + da_cursor->active = 0; + + do { + /* + * read in each block along the way and set up cursor + */ + nex = blkmap_getn(da_cursor->blkmap, bno, + geo->fsbcount, &bmp, &lbmp); + + if (nex == 0) + goto error_out; + + bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); + if (bmp != &lbmp) + free(bmp); + + if (!bp) { + do_warn( +_("can't read block %u for directory inode %" PRIu64 "\n"), + bno, da_cursor->ino); + goto error_out; + } + + node = bp->b_addr; + M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); + + if (whichfork == XFS_DATA_FORK && + (nodehdr.magic == XFS_DIR2_LEAFN_MAGIC || + nodehdr.magic == XFS_DIR3_LEAFN_MAGIC)) { + if (i != -1) { + do_warn( +_("found non-root LEAFN node in inode %" PRIu64 " bno = %u\n"), + da_cursor->ino, bno); + } + *rbno = 0; + libxfs_putbuf(bp); + return 1; + } + + if (nodehdr.magic != XFS_DA_NODE_MAGIC && + nodehdr.magic != XFS_DA3_NODE_MAGIC) { + do_warn( +_("bad dir magic number 0x%x in inode %" PRIu64 " bno = %u\n"), + nodehdr.magic, + da_cursor->ino, bno); + libxfs_putbuf(bp); + goto error_out; + } + + /* corrupt node; rebuild the dir. */ + if (bp->b_error == -EFSBADCRC || bp->b_error == -EFSCORRUPTED) { + libxfs_putbuf(bp); + do_warn( +_("corrupt tree block %u for directory inode %" PRIu64 "\n"), + bno, da_cursor->ino); + goto error_out; + } + + btree = M_DIROPS(mp)->node_tree_p(node); + if (nodehdr.count > geo->node_ents) { + do_warn( +_("bad record count in inode %" PRIu64 ", count = %d, max = %d\n"), + da_cursor->ino, nodehdr.count, geo->node_ents); + libxfs_putbuf(bp); + goto error_out; + } + + /* + * maintain level counter + */ + if (i == -1) { + i = da_cursor->active = nodehdr.level; + if (i < 1 || i >= XFS_DA_NODE_MAXDEPTH) { + do_warn( +_("bad header depth for directory inode %" PRIu64 "\n"), + da_cursor->ino); + libxfs_putbuf(bp); + i = -1; + goto error_out; + } + } else { + if (nodehdr.level == i - 1) { + i--; + } else { + do_warn( +_("bad directory btree for directory inode %" PRIu64 "\n"), + da_cursor->ino); + libxfs_putbuf(bp); + goto error_out; + } + } + + da_cursor->level[i].hashval = be32_to_cpu(btree[0].hashval); + da_cursor->level[i].bp = bp; + da_cursor->level[i].bno = bno; + da_cursor->level[i].index = 0; + + /* + * set up new bno for next level down + */ + bno = be32_to_cpu(btree[0].before); + } while (node != NULL && i > 1); + + /* + * now return block number and get out + */ + *rbno = da_cursor->level[0].bno = bno; + return 1; + +error_out: + while (i > 1 && i <= da_cursor->active) { + libxfs_putbuf(da_cursor->level[i].bp); + i++; + } + + return 0; +} + +/* + * blow out buffer for this level and all the rest above as well + * if error == 0, we are not expecting to encounter any unreleased + * buffers (e.g. if we do, it's a mistake). if error == 1, we're + * in an error-handling case so unreleased buffers may exist. + */ +static void +release_da_cursor_int( + xfs_mount_t *mp, + da_bt_cursor_t *cursor, + int prev_level, + int error) +{ + int level = prev_level + 1; + + if (cursor->level[level].bp != NULL) { + if (!error) { + do_warn(_("release_da_cursor_int got unexpected " + "non-null bp, dabno = %u\n"), + cursor->level[level].bno); + } + ASSERT(error != 0); + + libxfs_putbuf(cursor->level[level].bp); + cursor->level[level].bp = NULL; + } + + if (level < cursor->active) + release_da_cursor_int(mp, cursor, level, error); + + return; +} + +void +release_da_cursor( + xfs_mount_t *mp, + da_bt_cursor_t *cursor, + int prev_level) +{ + release_da_cursor_int(mp, cursor, prev_level, 0); +} + +void +err_release_da_cursor( + xfs_mount_t *mp, + da_bt_cursor_t *cursor, + int prev_level) +{ + release_da_cursor_int(mp, cursor, prev_level, 1); +} + +/* + * make sure that all entries in all blocks along the right side of + * of the tree are used and hashval's are consistent. level is the + * level of the descendent block. returns 0 if good (even if it had + * to be fixed up), and 1 if bad. The right edge of the tree is + * technically a block boundary. This routine should be used then + * instead of verify_da_path(). + */ +int +verify_final_da_path( + xfs_mount_t *mp, + da_bt_cursor_t *cursor, + const int p_level) +{ + xfs_da_intnode_t *node; + xfs_dahash_t hashval; + int bad = 0; + int entry; + int this_level = p_level + 1; + struct xfs_da_node_entry *btree; + struct xfs_da3_icnode_hdr nodehdr; + +#ifdef XR_DIR_TRACE + fprintf(stderr, "in verify_final_da_path, this_level = %d\n", + this_level); +#endif + + /* + * the index should point to the next "unprocessed" entry + * in the block which should be the final (rightmost) entry + */ + entry = cursor->level[this_level].index; + node = cursor->level[this_level].bp->b_addr; + btree = M_DIROPS(mp)->node_tree_p(node); + M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); + + /* + * check internal block consistency on this level -- ensure + * that all entries are used, encountered and expected hashvals + * match, etc. + */ + if (entry != nodehdr.count - 1) { + do_warn( + _("directory block used/count inconsistency - %d/%hu\n"), + entry, nodehdr.count); + bad++; + } + /* + * hash values monotonically increasing ??? + */ + if (cursor->level[this_level].hashval >= + be32_to_cpu(btree[entry].hashval)) { + do_warn(_("directory/attribute block hashvalue inconsistency, " + "expected > %u / saw %u\n"), + cursor->level[this_level].hashval, + be32_to_cpu(btree[entry].hashval)); + bad++; + } + if (nodehdr.forw != 0) { + do_warn(_("bad directory/attribute forward block pointer, " + "expected 0, saw %u\n"), + nodehdr.forw); + bad++; + } + if (bad) { + do_warn(_("bad directory block in inode %" PRIu64 "\n"), cursor->ino); + return 1; + } + /* + * keep track of greatest block # -- that gets + * us the length of the directory + */ + if (cursor->level[this_level].bno > cursor->greatest_bno) + cursor->greatest_bno = cursor->level[this_level].bno; + + /* + * ok, now check descendant block number against this level + */ + if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { +#ifdef XR_DIR_TRACE + fprintf(stderr, "bad directory btree pointer, child bno should " + "be %d, block bno is %d, hashval is %u\n", + be16_to_cpu(btree[entry].before), + cursor->level[p_level].bno, + cursor->level[p_level].hashval); + fprintf(stderr, "verify_final_da_path returns 1 (bad) #1a\n"); +#endif + return 1; + } + + if (cursor->level[p_level].hashval != + be32_to_cpu(btree[entry].hashval)) { + if (!no_modify) { + do_warn( +_("correcting bad hashval in non-leaf dir block\n" + "\tin (level %d) in inode %" PRIu64 ".\n"), + this_level, cursor->ino); + btree[entry].hashval = cpu_to_be32( + cursor->level[p_level].hashval); + cursor->level[this_level].dirty++; + } else { + do_warn( +_("would correct bad hashval in non-leaf dir block\n" + "\tin (level %d) in inode %" PRIu64 ".\n"), + this_level, cursor->ino); + } + } + + /* + * Note: squirrel hashval away _before_ releasing the + * buffer, preventing a use-after-free problem. + */ + hashval = be32_to_cpu(btree[entry].hashval); + + /* + * release/write buffer + */ + ASSERT(cursor->level[this_level].dirty == 0 || + (cursor->level[this_level].dirty && !no_modify)); + + if (cursor->level[this_level].dirty && !no_modify) + libxfs_writebuf(cursor->level[this_level].bp, 0); + else + libxfs_putbuf(cursor->level[this_level].bp); + + cursor->level[this_level].bp = NULL; + + /* + * bail out if this is the root block (top of tree) + */ + if (this_level >= cursor->active) { +#ifdef XR_DIR_TRACE + fprintf(stderr, "verify_final_da_path returns 0 (ok)\n"); +#endif + return 0; + } + /* + * set hashvalue to correctly reflect the now-validated + * last entry in this block and continue upwards validation + */ + cursor->level[this_level].hashval = hashval; + + return verify_final_da_path(mp, cursor, this_level); +} + +/* + * Verifies the path from a descendant block up to the root. + * Should be called when the descendant level traversal hits + * a block boundary before crossing the boundary (reading in a new + * block). + * + * the directory/attr btrees work differently to the other fs btrees. + * each interior block contains records that are + * pairs. The bno is a file bno, not a filesystem bno. The last + * hashvalue in the block will be . BUT unlike + * the freespace btrees, the *last* value in each block gets + * propagated up the tree instead of the first value in each block. + * that is, the interior records point to child blocks and the *greatest* + * hash value contained by the child block is the one the block above + * uses as the key for the child block. + * + * level is the level of the descendent block. returns 0 if good, + * and 1 if bad. The descendant block may be a leaf block. + * + * the invariant here is that the values in the cursor for the + * levels beneath this level (this_level) and the cursor index + * for this level *must* be valid. + * + * that is, the hashval/bno info is accurate for all + * DESCENDANTS and match what the node[index] information + * for the current index in the cursor for this level. + * + * the index values in the cursor for the descendant level + * are allowed to be off by one as they will reflect the + * next entry at those levels to be processed. + * + * the hashvalue for the current level can't be set until + * we hit the last entry in the block so, it's garbage + * until set by this routine. + * + * bno and bp for the current block/level are always valid + * since they have to be set so we can get a buffer for the + * block. + */ +int +verify_da_path( + xfs_mount_t *mp, + da_bt_cursor_t *cursor, + const int p_level, + int whichfork) +{ + xfs_da_intnode_t *node; + xfs_da_intnode_t *newnode; + xfs_dablk_t dabno; + struct xfs_buf *bp; + int bad; + int entry; + int this_level = p_level + 1; + bmap_ext_t *bmp; + int nex; + bmap_ext_t lbmp; + struct xfs_da_geometry *geo; + struct xfs_da_node_entry *btree; + struct xfs_da3_icnode_hdr nodehdr; + + if (whichfork == XFS_DATA_FORK) + geo = mp->m_dir_geo; + else + geo = mp->m_attr_geo; + + /* + * index is currently set to point to the entry that + * should be processed now in this level. + */ + entry = cursor->level[this_level].index; + node = cursor->level[this_level].bp->b_addr; + btree = M_DIROPS(mp)->node_tree_p(node); + M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); + + /* + * if this block is out of entries, validate this + * block and move on to the next block. + * and update cursor value for said level + */ + if (entry >= nodehdr.count) { + /* + * update the hash value for this level before + * validating it. bno value should be ok since + * it was set when the block was first read in. + */ + cursor->level[this_level].hashval = + be32_to_cpu(btree[entry - 1].hashval); + + /* + * keep track of greatest block # -- that gets + * us the length of the directory + */ + if (cursor->level[this_level].bno > cursor->greatest_bno) + cursor->greatest_bno = cursor->level[this_level].bno; + + /* + * validate the path for the current used-up block + * before we trash it + */ + if (verify_da_path(mp, cursor, this_level, whichfork)) + return 1; + /* + * ok, now get the next buffer and check sibling pointers + */ + dabno = nodehdr.forw; + ASSERT(dabno != 0); + nex = blkmap_getn(cursor->blkmap, dabno, geo->fsbcount, + &bmp, &lbmp); + if (nex == 0) { + do_warn( +_("can't get map info for block %u of directory inode %" PRIu64 "\n"), + dabno, cursor->ino); + return 1; + } + + bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); + if (bmp != &lbmp) + free(bmp); + + if (!bp) { + do_warn( +_("can't read block %u for directory inode %" PRIu64 "\n"), + dabno, cursor->ino); + return 1; + } + + newnode = bp->b_addr; + btree = M_DIROPS(mp)->node_tree_p(newnode); + M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, newnode); + + /* + * verify magic number and back pointer, sanity-check + * entry count, verify level + */ + bad = 0; + if (nodehdr.magic != XFS_DA_NODE_MAGIC && + nodehdr.magic != XFS_DA3_NODE_MAGIC) { + do_warn( +_("bad magic number %x in block %u for directory inode %" PRIu64 "\n"), + nodehdr.magic, + dabno, cursor->ino); + bad++; + } + if (nodehdr.back != cursor->level[this_level].bno) { + do_warn( +_("bad back pointer in block %u for directory inode %" PRIu64 "\n"), + dabno, cursor->ino); + bad++; + } + if (nodehdr.count > geo->node_ents) { + do_warn( +_("entry count %d too large in block %u for directory inode %" PRIu64 "\n"), + nodehdr.count, + dabno, cursor->ino); + bad++; + } + if (nodehdr.level != this_level) { + do_warn( +_("bad level %d in block %u for directory inode %" PRIu64 "\n"), + nodehdr.level, + dabno, cursor->ino); + bad++; + } + if (bad) { +#ifdef XR_DIR_TRACE + fprintf(stderr, "verify_da_path returns 1 (bad) #4\n"); +#endif + libxfs_putbuf(bp); + return 1; + } + + /* + * update cursor, write out the *current* level if + * required. don't write out the descendant level + */ + ASSERT(cursor->level[this_level].dirty == 0 || + (cursor->level[this_level].dirty && !no_modify)); + + /* + * If block looks ok but CRC didn't match, make sure to + * recompute it. + */ + if (!no_modify && + cursor->level[this_level].bp->b_error == -EFSBADCRC) + cursor->level[this_level].dirty = 1; + + if (cursor->level[this_level].dirty && !no_modify) + libxfs_writebuf(cursor->level[this_level].bp, 0); + else + libxfs_putbuf(cursor->level[this_level].bp); + + /* switch cursor to point at the new buffer we just read */ + cursor->level[this_level].bp = bp; + cursor->level[this_level].dirty = 0; + cursor->level[this_level].bno = dabno; + cursor->level[this_level].hashval = + be32_to_cpu(btree[0].hashval); + + entry = cursor->level[this_level].index = 0; + } + /* + * ditto for block numbers + */ + if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { +#ifdef XR_DIR_TRACE + fprintf(stderr, "bad directory btree pointer, child bno " + "should be %d, block bno is %d, hashval is %u\n", + be32_to_cpu(btree[entry].before), + cursor->level[p_level].bno, + cursor->level[p_level].hashval); + fprintf(stderr, "verify_da_path returns 1 (bad) #1a\n"); +#endif + return 1; + } + /* + * ok, now validate last hashvalue in the descendant + * block against the hashval in the current entry + */ + if (cursor->level[p_level].hashval != + be32_to_cpu(btree[entry].hashval)) { + if (!no_modify) { + do_warn( +_("correcting bad hashval in interior dir block\n" + "\tin (level %d) in inode %" PRIu64 ".\n"), + this_level, cursor->ino); + btree[entry].hashval = cpu_to_be32( + cursor->level[p_level].hashval); + cursor->level[this_level].dirty++; + } else { + do_warn( +_("would correct bad hashval in interior dir block\n" + "\tin (level %d) in inode %" PRIu64 ".\n"), + this_level, cursor->ino); + } + } + /* + * increment index for this level to point to next entry + * (which should point to the next descendant block) + */ + cursor->level[this_level].index++; +#ifdef XR_DIR_TRACE + fprintf(stderr, "verify_da_path returns 0 (ok)\n"); +#endif + return 0; +} diff --git a/repair/da_util.h b/repair/da_util.h new file mode 100644 index 0000000..7971d63 --- /dev/null +++ b/repair/da_util.h @@ -0,0 +1,82 @@ +/* + * Copyright (c) 2015 Red Hat, Inc. + * All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef _XR_DA_UTIL_H +#define _XR_DA_UTIL_H + +struct da_level_state { + xfs_buf_t *bp; /* block bp */ + xfs_dablk_t bno; /* file block number */ + xfs_dahash_t hashval; /* last verified hashval */ + int index; /* current index in block */ + int dirty; /* is buffer dirty ? (1 == yes) */ +}; + +typedef struct da_bt_cursor { + int active; /* highest level in tree (# levels-1) */ + xfs_ino_t ino; + xfs_dablk_t greatest_bno; + xfs_dinode_t *dip; + struct da_level_state level[XFS_DA_NODE_MAXDEPTH]; + struct blkmap *blkmap; +} da_bt_cursor_t; + +int +namecheck( + char *name, + int length); + +struct xfs_buf * +da_read_buf( + xfs_mount_t *mp, + int nex, + bmap_ext_t *bmp, + const struct xfs_buf_ops *ops); + +void +release_da_cursor( + xfs_mount_t *mp, + da_bt_cursor_t *cursor, + int prev_level); + +void +err_release_da_cursor( + xfs_mount_t *mp, + da_bt_cursor_t *cursor, + int prev_level); + +int +traverse_int_dablock( + xfs_mount_t *mp, + da_bt_cursor_t *da_cursor, + xfs_dablk_t *rbno, + int whichfork); + +int +verify_da_path( + xfs_mount_t *mp, + da_bt_cursor_t *cursor, + const int p_level, + int whichfork); + +int +verify_final_da_path( + xfs_mount_t *mp, + da_bt_cursor_t *cursor, + const int p_level); +#endif /* _XR_DA_UTIL_H */ diff --git a/repair/dir2.c b/repair/dir2.c index 7b47a9e..492b3e7 100644 --- a/repair/dir2.c +++ b/repair/dir2.c @@ -24,6 +24,7 @@ #include "dinode.h" #include "dir2.h" #include "bmap.h" +#include "da_util.h" #include "prefetch.h" #include "progress.h" @@ -68,638 +69,6 @@ dir2_is_badino( } /* - * takes a name and length (name need not be null-terminated) - * and returns 1 if the name contains a '/' or a \0, returns 0 - * otherwise - */ -int -namecheck(char *name, int length) -{ - char *c; - int i; - - ASSERT(length < MAXNAMELEN); - - for (c = name, i = 0; i < length; i++, c++) { - if (*c == '/' || *c == '\0') - return(1); - } - - return(0); -} - -/* - * Multibuffer handling. - * V2 directory blocks can be noncontiguous, needing multiple buffers. - */ -struct xfs_buf * -da_read_buf( - xfs_mount_t *mp, - int nex, - bmap_ext_t *bmp, - const struct xfs_buf_ops *ops) -{ -#define MAP_ARRAY_SZ 4 - struct xfs_buf_map map_array[MAP_ARRAY_SZ]; - struct xfs_buf_map *map; - struct xfs_buf *bp; - int i; - - if (nex > MAP_ARRAY_SZ) { - map = calloc(nex, sizeof(*map)); - if (map == NULL) { - do_error(_("couldn't malloc dir2 buffer list\n")); - exit(1); - } - } else { - /* common case avoids calloc/free */ - map = map_array; - } - for (i = 0; i < nex; i++) { - map[i].bm_bn = XFS_FSB_TO_DADDR(mp, bmp[i].startblock); - map[i].bm_len = XFS_FSB_TO_BB(mp, bmp[i].blockcount); - } - bp = libxfs_readbuf_map(mp->m_dev, map, nex, 0, ops); - if (map != map_array) - free(map); - return bp; -} - -/* - * walk tree from root to the left-most leaf block reading in - * blocks and setting up cursor. passes back file block number of the - * left-most leaf block if successful (bno). returns 1 if successful, - * 0 if unsuccessful. - */ -static int -traverse_int_dir2block(xfs_mount_t *mp, - dir2_bt_cursor_t *da_cursor, - xfs_dablk_t *rbno) -{ - bmap_ext_t *bmp; - xfs_dablk_t bno; - struct xfs_buf *bp; - int i; - int nex; - xfs_da_intnode_t *node; - bmap_ext_t lbmp; - struct xfs_da_geometry *geo; - struct xfs_da_node_entry *btree; - struct xfs_da3_icnode_hdr nodehdr; - - geo = mp->m_dir_geo; - - /* - * traverse down left-side of tree until we hit the - * left-most leaf block setting up the btree cursor along - * the way. - */ - bno = mp->m_dir_geo->leafblk; - i = -1; - node = NULL; - da_cursor->active = 0; - - do { - /* - * read in each block along the way and set up cursor - */ - nex = blkmap_getn(da_cursor->blkmap, bno, - geo->fsbcount, &bmp, &lbmp); - - if (nex == 0) - goto error_out; - - bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); - if (bmp != &lbmp) - free(bmp); - if (!bp) { - do_warn( -_("can't read block %u for directory inode %" PRIu64 "\n"), - bno, da_cursor->ino); - goto error_out; - } - - node = bp->b_addr; - M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); - - if (nodehdr.magic == XFS_DIR2_LEAFN_MAGIC || - nodehdr.magic == XFS_DIR3_LEAFN_MAGIC) { - if ( i != -1 ) { - do_warn( -_("found non-root LEAFN node in inode %" PRIu64 " bno = %u\n"), - da_cursor->ino, bno); - } - *rbno = 0; - libxfs_putbuf(bp); - return(1); - } - - if (nodehdr.magic != XFS_DA_NODE_MAGIC && - nodehdr.magic != XFS_DA3_NODE_MAGIC) { - libxfs_putbuf(bp); - do_warn( -_("bad dir magic number 0x%x in inode %" PRIu64 " bno = %u\n"), - nodehdr.magic, - da_cursor->ino, bno); - goto error_out; - } - /* corrupt node; rebuild the dir. */ - if (bp->b_error == -EFSBADCRC || bp->b_error == -EFSCORRUPTED) { - libxfs_putbuf(bp); - do_warn( -_("corrupt tree block %u for directory inode %" PRIu64 "\n"), - bno, da_cursor->ino); - goto error_out; - } - btree = M_DIROPS(mp)->node_tree_p(node); - if (nodehdr.count > geo->node_ents) { - do_warn( -_("bad record count in inode %" PRIu64 ", count = %d, max = %d\n"), - da_cursor->ino, nodehdr.count, geo->node_ents); - libxfs_putbuf(bp); - goto error_out; - } - /* - * maintain level counter - */ - if (i == -1) { - i = da_cursor->active = nodehdr.level; - if (i < 1 || i >= XFS_DA_NODE_MAXDEPTH) { - do_warn( -_("bad header depth for directory inode %" PRIu64 "\n"), - da_cursor->ino); - libxfs_putbuf(bp); - i = -1; - goto error_out; - } - } else { - if (nodehdr.level == i - 1) { - i--; - } else { - do_warn( -_("bad directory btree for directory inode %" PRIu64 "\n"), - da_cursor->ino); - libxfs_putbuf(bp); - goto error_out; - } - } - - da_cursor->level[i].hashval = be32_to_cpu(btree[0].hashval); - da_cursor->level[i].bp = bp; - da_cursor->level[i].bno = bno; - da_cursor->level[i].index = 0; - - /* - * set up new bno for next level down - */ - bno = be32_to_cpu(btree[0].before); - } while (node != NULL && i > 1); - - /* - * now return block number and get out - */ - *rbno = da_cursor->level[0].bno = bno; - return(1); - -error_out: - while (i > 1 && i <= da_cursor->active) { - libxfs_putbuf(da_cursor->level[i].bp); - i++; - } - - return(0); -} - -/* - * blow out buffer for this level and all the rest above as well - * if error == 0, we are not expecting to encounter any unreleased - * buffers (e.g. if we do, it's a mistake). if error == 1, we're - * in an error-handling case so unreleased buffers may exist. - */ -static void -release_dir2_cursor_int(xfs_mount_t *mp, - dir2_bt_cursor_t *cursor, - int prev_level, - int error) -{ - int level = prev_level + 1; - - if (cursor->level[level].bp != NULL) { - if (!error) { - do_warn(_("release_dir2_cursor_int got unexpected " - "non-null bp, dabno = %u\n"), - cursor->level[level].bno); - } - ASSERT(error != 0); - - libxfs_putbuf(cursor->level[level].bp); - cursor->level[level].bp = NULL; - } - - if (level < cursor->active) - release_dir2_cursor_int(mp, cursor, level, error); - - return; -} - -static void -release_dir2_cursor(xfs_mount_t *mp, - dir2_bt_cursor_t *cursor, - int prev_level) -{ - release_dir2_cursor_int(mp, cursor, prev_level, 0); -} - -static void -err_release_dir2_cursor(xfs_mount_t *mp, - dir2_bt_cursor_t *cursor, - int prev_level) -{ - release_dir2_cursor_int(mp, cursor, prev_level, 1); -} - -/* - * make sure that all entries in all blocks along the right side of - * of the tree are used and hashval's are consistent. level is the - * level of the descendent block. returns 0 if good (even if it had - * to be fixed up), and 1 if bad. The right edge of the tree is - * technically a block boundary. This routine should be used then - * instead of verify_dir2_path(). - */ -static int -verify_final_dir2_path(xfs_mount_t *mp, - dir2_bt_cursor_t *cursor, - const int p_level) -{ - xfs_da_intnode_t *node; - xfs_dahash_t hashval; - int bad = 0; - int entry; - int this_level = p_level + 1; - struct xfs_da_node_entry *btree; - struct xfs_da3_icnode_hdr nodehdr; - -#ifdef XR_DIR_TRACE - fprintf(stderr, "in verify_final_dir2_path, this_level = %d\n", - this_level); -#endif - - /* - * the index should point to the next "unprocessed" entry - * in the block which should be the final (rightmost) entry - */ - entry = cursor->level[this_level].index; - node = cursor->level[this_level].bp->b_addr; - btree = M_DIROPS(mp)->node_tree_p(node); - M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); - - /* - * check internal block consistency on this level -- ensure - * that all entries are used, encountered and expected hashvals - * match, etc. - */ - if (entry != nodehdr.count - 1) { - do_warn( - _("directory block used/count inconsistency - %d / %hu\n"), - entry, nodehdr.count); - bad++; - } - /* - * hash values monotonically increasing ??? - */ - if (cursor->level[this_level].hashval >= - be32_to_cpu(btree[entry].hashval)) { - do_warn(_("directory/attribute block hashvalue inconsistency, " - "expected > %u / saw %u\n"), - cursor->level[this_level].hashval, - be32_to_cpu(btree[entry].hashval)); - bad++; - } - if (nodehdr.forw != 0) { - do_warn(_("bad directory/attribute forward block pointer, " - "expected 0, saw %u\n"), - nodehdr.forw); - bad++; - } - if (bad) { - do_warn(_("bad directory block in inode %" PRIu64 "\n"), cursor->ino); - return(1); - } - /* - * keep track of greatest block # -- that gets - * us the length of the directory - */ - if (cursor->level[this_level].bno > cursor->greatest_bno) - cursor->greatest_bno = cursor->level[this_level].bno; - - /* - * ok, now check descendant block number against this level - */ - if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { -#ifdef XR_DIR_TRACE - fprintf(stderr, "bad directory btree pointer, child bno should " - "be %d, block bno is %d, hashval is %u\n", - be16_to_cpu(btree[entry].before), - cursor->level[p_level].bno, - cursor->level[p_level].hashval); - fprintf(stderr, "verify_final_dir2_path returns 1 (bad) #1a\n"); -#endif - return(1); - } - - if (cursor->level[p_level].hashval != - be32_to_cpu(btree[entry].hashval)) { - if (!no_modify) { - do_warn( -_("correcting bad hashval in non-leaf dir block\n" - "\tin (level %d) in inode %" PRIu64 ".\n"), - this_level, cursor->ino); - btree[entry].hashval = cpu_to_be32( - cursor->level[p_level].hashval); - cursor->level[this_level].dirty++; - } else { - do_warn( -_("would correct bad hashval in non-leaf dir block\n" - "\tin (level %d) in inode %" PRIu64 ".\n"), - this_level, cursor->ino); - } - } - - /* - * Note: squirrel hashval away _before_ releasing the - * buffer, preventing a use-after-free problem. - */ - hashval = be32_to_cpu(btree[entry].hashval); - - /* - * release/write buffer - */ - ASSERT(cursor->level[this_level].dirty == 0 || - (cursor->level[this_level].dirty && !no_modify)); - - if (cursor->level[this_level].dirty && !no_modify) - libxfs_writebuf(cursor->level[this_level].bp, 0); - else - libxfs_putbuf(cursor->level[this_level].bp); - - cursor->level[this_level].bp = NULL; - - /* - * bail out if this is the root block (top of tree) - */ - if (this_level >= cursor->active) { -#ifdef XR_DIR_TRACE - fprintf(stderr, "verify_final_dir2_path returns 0 (ok)\n"); -#endif - return(0); - } - /* - * set hashvalue to correctly reflect the now-validated - * last entry in this block and continue upwards validation - */ - cursor->level[this_level].hashval = hashval; - - return(verify_final_dir2_path(mp, cursor, this_level)); -} - -/* - * Verifies the path from a descendant block up to the root. - * Should be called when the descendant level traversal hits - * a block boundary before crossing the boundary (reading in a new - * block). - * - * the directory/attr btrees work differently to the other fs btrees. - * each interior block contains records that are - * pairs. The bno is a file bno, not a filesystem bno. The last - * hashvalue in the block will be . BUT unlike - * the freespace btrees, the *last* value in each block gets - * propagated up the tree instead of the first value in each block. - * that is, the interior records point to child blocks and the *greatest* - * hash value contained by the child block is the one the block above - * uses as the key for the child block. - * - * level is the level of the descendent block. returns 0 if good, - * and 1 if bad. The descendant block may be a leaf block. - * - * the invariant here is that the values in the cursor for the - * levels beneath this level (this_level) and the cursor index - * for this level *must* be valid. - * - * that is, the hashval/bno info is accurate for all - * DESCENDANTS and match what the node[index] information - * for the current index in the cursor for this level. - * - * the index values in the cursor for the descendant level - * are allowed to be off by one as they will reflect the - * next entry at those levels to be processed. - * - * the hashvalue for the current level can't be set until - * we hit the last entry in the block so, it's garbage - * until set by this routine. - * - * bno and bp for the current block/level are always valid - * since they have to be set so we can get a buffer for the - * block. - */ -static int -verify_dir2_path(xfs_mount_t *mp, - dir2_bt_cursor_t *cursor, - const int p_level) -{ - xfs_da_intnode_t *node; - xfs_da_intnode_t *newnode; - xfs_dablk_t dabno; - struct xfs_buf *bp; - int bad; - int entry; - int this_level = p_level + 1; - bmap_ext_t *bmp; - int nex; - bmap_ext_t lbmp; - struct xfs_da_geometry *geo; - struct xfs_da_node_entry *btree; - struct xfs_da3_icnode_hdr nodehdr; - - geo = mp->m_dir_geo; - - /* - * index is currently set to point to the entry that - * should be processed now in this level. - */ - entry = cursor->level[this_level].index; - node = cursor->level[this_level].bp->b_addr; - btree = M_DIROPS(mp)->node_tree_p(node); - M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); - - /* - * if this block is out of entries, validate this - * block and move on to the next block. - * and update cursor value for said level - */ - if (entry >= nodehdr.count) { - /* - * update the hash value for this level before - * validating it. bno value should be ok since - * it was set when the block was first read in. - */ - cursor->level[this_level].hashval = - be32_to_cpu(btree[entry - 1].hashval); - - /* - * keep track of greatest block # -- that gets - * us the length of the directory - */ - if (cursor->level[this_level].bno > cursor->greatest_bno) - cursor->greatest_bno = cursor->level[this_level].bno; - - /* - * validate the path for the current used-up block - * before we trash it - */ - if (verify_dir2_path(mp, cursor, this_level)) - return(1); - /* - * ok, now get the next buffer and check sibling pointers - */ - dabno = nodehdr.forw; - ASSERT(dabno != 0); - nex = blkmap_getn(cursor->blkmap, dabno, geo->fsbcount, - &bmp, &lbmp); - if (nex == 0) { - do_warn( -_("can't get map info for block %u of directory inode %" PRIu64 "\n"), - dabno, cursor->ino); - return(1); - } - - bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); - if (bmp != &lbmp) - free(bmp); - - if (!bp) { - do_warn( -_("can't read block %u for directory inode %" PRIu64 "\n"), - dabno, cursor->ino); - return(1); - } - - newnode = bp->b_addr; - btree = M_DIROPS(mp)->node_tree_p(newnode); - M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, newnode); - /* - * verify magic number and back pointer, sanity-check - * entry count, verify level - */ - bad = 0; - if (nodehdr.magic != XFS_DA_NODE_MAGIC && - nodehdr.magic != XFS_DA3_NODE_MAGIC) { - do_warn( -_("bad magic number %x in block %u for directory inode %" PRIu64 "\n"), - nodehdr.magic, - dabno, cursor->ino); - bad++; - } - if (nodehdr.back != cursor->level[this_level].bno) { - do_warn( -_("bad back pointer in block %u for directory inode %" PRIu64 "\n"), - dabno, cursor->ino); - bad++; - } - if (nodehdr.count > geo->node_ents) { - do_warn( -_("entry count %d too large in block %u for directory inode %" PRIu64 "\n"), - nodehdr.count, - dabno, cursor->ino); - bad++; - } - if (nodehdr.level != this_level) { - do_warn( -_("bad level %d in block %u for directory inode %" PRIu64 "\n"), - nodehdr.level, - dabno, cursor->ino); - bad++; - } - if (bad) { -#ifdef XR_DIR_TRACE - fprintf(stderr, "verify_dir2_path returns 1 (bad) #4\n"); -#endif - libxfs_putbuf(bp); - return(1); - } - /* - * update cursor, write out the *current* level if - * required. don't write out the descendant level - */ - ASSERT(cursor->level[this_level].dirty == 0 || - (cursor->level[this_level].dirty && !no_modify)); - /* - * If block looks ok but CRC didn't match, make sure to - * recompute it. - */ - if (!no_modify && - cursor->level[this_level].bp->b_error == -EFSBADCRC) - cursor->level[this_level].dirty = 1; - if (cursor->level[this_level].dirty && !no_modify) - libxfs_writebuf(cursor->level[this_level].bp, 0); - else - libxfs_putbuf(cursor->level[this_level].bp); - - /* switch cursor to point at the new buffer we just read */ - cursor->level[this_level].bp = bp; - cursor->level[this_level].dirty = 0; - cursor->level[this_level].bno = dabno; - cursor->level[this_level].hashval = - be32_to_cpu(btree[0].hashval); - - entry = cursor->level[this_level].index = 0; - } - /* - * ditto for block numbers - */ - if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { -#ifdef XR_DIR_TRACE - fprintf(stderr, "bad directory btree pointer, child bno " - "should be %d, block bno is %d, hashval is %u\n", - be32_to_cpu(btree[entry].before), - cursor->level[p_level].bno, - cursor->level[p_level].hashval); - fprintf(stderr, "verify_dir2_path returns 1 (bad) #1a\n"); -#endif - return(1); - } - /* - * ok, now validate last hashvalue in the descendant - * block against the hashval in the current entry - */ - if (cursor->level[p_level].hashval != - be32_to_cpu(btree[entry].hashval)) { - if (!no_modify) { - do_warn( -_("correcting bad hashval in interior dir block\n" - "\tin (level %d) in inode %" PRIu64 ".\n"), - this_level, cursor->ino); - btree[entry].hashval = cpu_to_be32( - cursor->level[p_level].hashval); - cursor->level[this_level].dirty++; - } else { - do_warn( -_("would correct bad hashval in interior dir block\n" - "\tin (level %d) in inode %" PRIu64 ".\n"), - this_level, cursor->ino); - } - } - /* - * increment index for this level to point to next entry - * (which should point to the next descendant block) - */ - cursor->level[this_level].index++; -#ifdef XR_DIR_TRACE - fprintf(stderr, "verify_dir2_path returns 0 (ok)\n"); -#endif - return(0); -} - -/* * Fix up a shortform directory which was in long form (i8count set) * and is now in short form (i8count clear). * Return pointer to the end of the data when done. @@ -1697,7 +1066,7 @@ _("bad stale count in block %u of directory inode %" PRIu64 "\n"), static int process_leaf_level_dir2( xfs_mount_t *mp, - dir2_bt_cursor_t *da_cursor, + da_bt_cursor_t *da_cursor, int *repair) { bmap_ext_t *bmp; @@ -1791,7 +1160,7 @@ _("bad sibling back pointer for block %u in directory inode %" PRIu64 "\n"), prev_bno = da_bno; da_bno = leafhdr.forw; if (da_bno != 0) { - if (verify_dir2_path(mp, da_cursor, 0)) { + if (verify_da_path(mp, da_cursor, 0, XFS_DATA_FORK)) { libxfs_putbuf(bp); goto error_out; } @@ -1810,7 +1179,7 @@ _("bad sibling back pointer for block %u in directory inode %" PRIu64 "\n"), } else libxfs_putbuf(bp); } while (da_bno != 0); - if (verify_final_dir2_path(mp, da_cursor, 0)) { + if (verify_final_da_path(mp, da_cursor, 0)) { /* * Verify the final path up (right-hand-side) if still ok. */ @@ -1820,14 +1189,14 @@ _("bad sibling back pointer for block %u in directory inode %" PRIu64 "\n"), /* * Redundant but just for testing. */ - release_dir2_cursor(mp, da_cursor, 0); + release_da_cursor(mp, da_cursor, 0); return 0; error_out: /* * Release all buffers holding interior btree blocks. */ - err_release_dir2_cursor(mp, da_cursor, 0); + err_release_da_cursor(mp, da_cursor, 0); if (bmp && (bmp != &lbmp)) free(bmp); return 1; @@ -1846,7 +1215,7 @@ process_node_dir2( int *repair) { xfs_dablk_t bno; - dir2_bt_cursor_t da_cursor; + da_bt_cursor_t da_cursor; /* * Try again -- traverse down left-side of tree until we hit the @@ -1862,14 +1231,14 @@ process_node_dir2( /* * Now process interior node. */ - if (traverse_int_dir2block(mp, &da_cursor, &bno) == 0) + if (traverse_int_dablock(mp, &da_cursor, &bno, XFS_DATA_FORK) == 0) return 1; /* * Skip directories with a root marked XFS_DIR2_LEAFN_MAGIC */ if (bno == 0) { - release_dir2_cursor(mp, &da_cursor, 0); + release_da_cursor(mp, &da_cursor, 0); return 0; } else { /* diff --git a/repair/dir2.h b/repair/dir2.h index 186633f..e4d4eeb 100644 --- a/repair/dir2.h +++ b/repair/dir2.h @@ -22,50 +22,6 @@ struct blkmap; struct bmap_ext; -/* - * the cursor gets passed up and down the da btree processing - * routines. The interior block processing routines use the - * cursor to determine if the pointers to and from the preceding - * and succeeding sibling blocks are ok and whether the values in - * the current block are consistent with the entries in the parent - * nodes. When a block is traversed, a parent-verification routine - * is called to verify if the next logical entry in the next level up - * is consistent with the greatest hashval in the next block of the - * current level. The verification routine is itself recursive and - * calls itself if it has to traverse an interior block to get - * the next logical entry. The routine recurses upwards through - * the tree until it finds a block where it can simply step to - * the next entry. The hashval in that entry should be equal to - * the hashval being passed to it (the greatest hashval in the block - * that the entry points to). If that isn't true, then the tree - * is blown and we need to trash it, salvage and trash it, or fix it. - * Currently, we just trash it. - */ -typedef struct dir2_level_state { - xfs_buf_t *bp; /* block bp */ - xfs_dablk_t bno; /* file block number */ - xfs_dahash_t hashval; /* last verified hashval */ - int index; /* current index in block */ - int dirty; /* is buffer dirty ? (1 == yes) */ -} dir2_level_state_t; - -typedef struct dir2_bt_cursor { - int active; /* highest level in tree (# levels-1) */ - xfs_ino_t ino; - xfs_dablk_t greatest_bno; - xfs_dinode_t *dip; - dir2_level_state_t level[XFS_DA_NODE_MAXDEPTH]; - struct blkmap *blkmap; -} dir2_bt_cursor_t; - -#include "bmap.h" /* Goes away in later refactoring */ -struct xfs_buf * -da_read_buf( - xfs_mount_t *mp, - int nex, - bmap_ext_t *bmp, - const struct xfs_buf_ops *ops); - int process_dir2( xfs_mount_t *mp, @@ -87,9 +43,4 @@ int dir2_is_badino( xfs_ino_t ino); -int -namecheck( - char *name, - int length); - #endif /* _XR_DIR2_H */ -- 1.7.1 From home.roofing.deals-xfs=oss.sgi.com@afrenchinside.net Wed Sep 9 16:05:26 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=5.0 tests=HTML_IMAGE_RATIO_02, HTML_MESSAGE,T_DKIM_INVALID,T_REMOTE_IMAGE autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 0242C7F37 for ; Wed, 9 Sep 2015 16:05:26 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id E56B78F804C for ; Wed, 9 Sep 2015 14:05:22 -0700 (PDT) X-ASG-Debug-ID: 1441832717-04cbb005ec2f670001-NocioJ Received: from mail.afrenchinside.net (104.223.35.78.static.quadranet.com [104.223.35.78]) by cuda.sgi.com with ESMTP id FtCAyzqd0bWgaqCg for ; Wed, 09 Sep 2015 14:05:18 -0700 (PDT) X-Barracuda-Envelope-From: home.roofing.deals-xfs=oss.sgi.com@afrenchinside.net X-Barracuda-Apparent-Source-IP: 104.223.35.78 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=dkim; d=afrenchinside.net; h=Date:From:To:Subject:MIME-Version:Content-Type:Message-ID; i=home.roofing.deals@afrenchinside.net; bh=5ZWY12ikGDGhi169EmQZFP5hR/c=; b=Yuglx31wu+afsAp5Oli0C8rjWEhRmELwS/d0r5Ho/80ZAAUTIpRD6ZCiOa6zZN+elvmDwBClf/Kc UTvcOEr5zhrqaSryoqj1jbTdjtuXtevsTBBlevsvYGEKapDLzsfQ1p4mCuH16Fh+cIeJOaKh7LwL cPXUJsA8djbqP1RjxRU= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=dkim; d=afrenchinside.net; b=jvv555+lnvXVx48bEFu4ygPfHI1fpJc8+RgBt2Psatoe4ni5HqyaerTK8One36MISnV8KbikX9u3 c3gCjjZ65D+ugOyilR+7M+qsE0sZUbjZQDc2Z6zPhafpP6PQTdOXagjN62//mkarBuITTUhjUc2/ kG2mr6imScTT+XK3qkY=; Received: by mail.afrenchinside.net id hu2fh00001g2 for ; Wed, 9 Sep 2015 13:21:29 -0700 (envelope-from ) Date: Wed, 9 Sep 2015 13:21:29 -0700 From: "Home Roofing Deals" To: Subject: New 2015 Savings on Roofing Installation & Materials MIME-Version: 1.0 X-ASG-Orig-Subj: New 2015 Savings on Roofing Installation & Materials Content-Type: multipart/alternative; boundary="----=_Part_14551_630125262.1441829550578" Message-ID: <0.0.0.ABD.1D0EB3D1C71CF02.388D8C@mail.afrenchinside.net> X-Barracuda-Connect: 104.223.35.78.static.quadranet.com[104.223.35.78] X-Barracuda-Start-Time: 1441832717 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.65 X-Barracuda-Spam-Status: No, SCORE=0.65 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_COMMENT_TEXT_1K, BSF_SC0_SA085, DKIM_SIGNED, DKIM_VERIFIED, HTML_IMAGE_RATIO_02, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22384 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.55 HTML_IMAGE_RATIO_02 BODY: HTML has a low ratio of text to image area 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 BSF_SC0_SA085 Custom Rule SA085 0.00 BSF_SC0_COMMENT_TEXT_1K Custom Rule BSF_SC0_COMMENT_TEXT_1K ------=_Part_14551_630125262.1441829550578 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit New 2015 Savings on Roofing Installation & Materials http://www.afrenchinside.net/life/6GcI8C620y4aZsnFjnn0ntv0Mjhd1f Update Preferences- http://www.afrenchinside.net/drive/198TW8620M5T5ZsnFjnn0ntv0Mjh474 ------=_Part_14551_630125262.1441829550578 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

New 2015 Savings on Roofing Installation & Materials

Protect your home from the top down with a new roof.
Connect with experienced Roofing Contractors

OnlineRoofing Logo                                 Complimentary Info & Quotes >
Metal Roof Tile Roof
Slate Roof Shingle Roof
Get More Info Benefits of New Roofing



Safeguard your home, loved ones, and belongings with a durable new roof.
Explore various roofing options including: shingles, tiles, metal, slate and more.
Learn more about replacing your roof.



OnlineRoofingQuotes * 804 Congress Ave Ste 400 * Austin, Texas 78701










 


------=_Part_14551_630125262.1441829550578-- From zhaohongjiang@huawei.com Wed Sep 9 20:40:30 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 163AA7F37 for ; Wed, 9 Sep 2015 20:40:30 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id A5BECAC008 for ; Wed, 9 Sep 2015 18:40:26 -0700 (PDT) X-ASG-Debug-ID: 1441849220-04cbb005eb35360001-NocioJ Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by cuda.sgi.com with ESMTP id 6zirCb2jYLXVrQgd (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 09 Sep 2015 18:40:22 -0700 (PDT) X-Barracuda-Envelope-From: zhaohongjiang@huawei.com X-Barracuda-Apparent-Source-IP: 119.145.14.66 Received: from 172.24.1.47 (EHLO szxeml433-hub.china.huawei.com) ([172.24.1.47]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id BMQ08568; Thu, 10 Sep 2015 09:40:16 +0800 (CST) Received: from [10.177.28.216] (10.177.28.216) by smtpscn.huawei.com (10.82.67.210) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 10 Sep 2015 09:40:10 +0800 Message-ID: <55F0DF7A.7050404@huawei.com> Date: Thu, 10 Sep 2015 09:40:10 +0800 From: Zhaohongjiang User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: , CC: Subject: [PATCH] cancel the setfilesize transation when io error happen Content-Type: text/plain; charset="ISO-8859-1" X-ASG-Orig-Subj: [PATCH] cancel the setfilesize transation when io error happen Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.28.216] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.55F0DF83.007A,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 06cdbdf370457738ba8bf0f75a3f57f2 X-Barracuda-Connect: szxga03-in.huawei.com[119.145.14.66] X-Barracuda-Start-Time: 1441849221 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22393 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- When I ran xfstest/073 case, the remount process was blocked to wait transactions to be zero. I found there was a io error happened, and the setfilesize transaction was not released properly. We should add the changes to cancel the io error in this case. Reproduction steps: 1. dd if=/dev/zero of=xfs1.img bs=1M count=2048 2. mkfs.xfs xfs1.img 3. losetup -f ./xfs1.img /dev/loop0 4. mount -t xfs /dev/loop0 /home/test_dir/ 5. mkdir /home/test_dir/test 6. mkfs.xfs -dfile,name=image,size=2g 7. mount -t xfs -o loop image /home/test_dir/test 8. cp a file bigger than 2g to /home/test_dir/test 9. mount -t xfs -o remount,ro /home/test_dir/test Signed-off-by: Zhao Hongjiang --- fs/xfs/xfs_aops.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c index 50ab287..fab55da 100644 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -212,8 +212,21 @@ xfs_end_io( ioend->io_error = -EIO; goto done; } - if (ioend->io_error) + if (ioend->io_error) { + /* + * We should cancel the setfilesize transation when io error + * happen. + */ + if (ioend->io_append_trans) { + current_set_flags_nested(&ioend->io_append_trans->t_pflags, + PF_FSTRANS); + rwsem_acquire_read(&VFS_I(XFS_I(ioend->io_inode))->i_sb + ->s_writers.lock_map[SB_FREEZE_FS-1], 0, 1, _THIS_IP_); + xfs_trans_cancel(ioend->io_append_trans); + } + goto done; + } /* * For unwritten extents we need to issue transactions to convert a -- 1.8.3.1 -- version="9" logging="no" From c.baegert@lixium.fr Thu Sep 10 00:35:29 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 58C7F7F37 for ; Thu, 10 Sep 2015 00:35:29 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 47DA08F8050 for ; Wed, 9 Sep 2015 22:35:26 -0700 (PDT) X-ASG-Debug-ID: 1441863318-04cb6c355c377c0001-NocioJ Received: from mx2.lixium.fr (mx2.lixium.fr [79.98.96.12]) by cuda.sgi.com with ESMTP id NS3KTDt2BCH2IRnd for ; Wed, 09 Sep 2015 22:35:18 -0700 (PDT) X-Barracuda-Envelope-From: c.baegert@lixium.fr X-Barracuda-Apparent-Source-IP: 79.98.96.12 Received: from [192.168.1.21] (nsg93-h01-31-34-69-35.dsl.sta.abo.bbox.fr [31.34.69.35]) (Authenticated sender: europeanservers-c.baegert-maildrop@mx2.lixium.fr) by mx2.lixium.fr (Postfix) with ESMTPSA id 5EF5B61CBEBD for ; Thu, 10 Sep 2015 07:35:17 +0200 (CEST) Message-ID: <55F116A4.5080106@lixium.fr> Disposition-Notification-To: Christophe Baegert Date: Thu, 10 Sep 2015 07:35:32 +0200 From: Christophe Baegert Organization: Lixium User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: bug during xfs_repair -L on 1TB of strategic data Content-Type: text/plain; charset=utf-8; format=flowed X-ASG-Orig-Subj: bug during xfs_repair -L on 1TB of strategic data Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mx2.lixium.fr[79.98.96.12] X-Barracuda-Start-Time: 1441863318 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22397 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Hi, I see this message when repairing an XFS partition of 1TB of strategic data (on Debian Wheezy) What can I do ? corrupt dinode 1933282003, extent total = 1, nblocks = 0. This is a bug. Please capture the filesystem metadata with xfs_metadump and report it to xfs@oss.sgi.com. cache_node_purge: refcount was 1, not zero (node=0x7f7c55b35220) fatal error -- 117 - couldn't iget disconnected inode Regards, -- Christophe Baegert Lixium http://www.lixium.fr From tapani.j.tarvainen@jyu.fi Thu Sep 10 04:18:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 40CB57CBF for ; Thu, 10 Sep 2015 04:18:43 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id DC36BAC009 for ; Thu, 10 Sep 2015 02:18:39 -0700 (PDT) X-ASG-Debug-ID: 1441876716-04bdf04db63f8a0001-NocioJ Received: from posti5.jyu.fi (posti5.jyu.fi [130.234.4.34]) by cuda.sgi.com with ESMTP id IAxwi2Zn6F1JggnJ (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Sep 2015 02:18:37 -0700 (PDT) X-Barracuda-Envelope-From: tapani.j.tarvainen@jyu.fi X-Barracuda-Apparent-Source-IP: 130.234.4.34 Received: from localhost (localhost.localdomain [127.0.0.1]) by posti5.jyu.fi (8.13.8/8.13.8) with ESMTP id t8A9IZCW020826 for ; Thu, 10 Sep 2015 12:18:35 +0300 X-Virus-Scanned: amavisd-new at cc.jyu.fi Received: from posti5.jyu.fi ([127.0.0.1]) by localhost (posti5.jyu.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjrYQm0CssDu for ; Thu, 10 Sep 2015 12:18:35 +0300 (EEST) Received: from tehanu.it.jyu.fi (tehanu.it.jyu.fi [130.234.160.128]) by posti5.jyu.fi (8.13.8/8.13.8) with ESMTP id t8A9IYwF020822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Sep 2015 12:18:35 +0300 Received: (from tt@localhost) by tehanu.it.jyu.fi (8.14.4/8.14.4/Submit) id t8A9IYw6026290 for xfs@oss.sgi.com; Thu, 10 Sep 2015 12:18:34 +0300 X-Authentication-Warning: tehanu.it.jyu.fi: tt set sender to tapani.j.tarvainen@jyu.fi using -f Date: Thu, 10 Sep 2015 12:18:34 +0300 From: Tapani Tarvainen To: xfs@oss.sgi.com Subject: "This is a bug." Message-ID: <20150910091834.GC24937@tehanu.it.jyu.fi> X-ASG-Orig-Subj: "This is a bug." MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-12-10) X-Barracuda-Connect: posti5.jyu.fi[130.234.4.34] X-Barracuda-Start-Time: 1441876717 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22400 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Hi, After a rather spectacular crash we've got an xfs filesystem in unrepairable state: mount fails with "Structure needs cleaning", xfs_repair without options refuses to work (asks to mount first), and xfs_repair -L stopped with corrupt dinode 2151195170, extent total = 1, nblocks = 0. This is a bug. Please capture the filesystem metadata with xfs_metadump and report it to xfs@oss.sgi.com. I tried to dump the metadata and it failed, too: # xfs_metadump /dev/sdata1/data1 /data2/tmp/data1_metadump xfs_metadump: cannot init perag data (117) *** glibc detected *** xfs_db: double free or corruption (!prev): 0x0000000003361000 *** ======= Backtrace: ========= [...] Aborted At this point I'm going to give up trying to recover the data (recreate filesystem and restore from backup), but if you want to analyze it to find the bug, I have enough spare disk space to keep a copy for a while (took lvm snapshot of it before recovery attempt, could dd it to another location). The machine is running Debian Wheezy (7.8), kernel 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux, xfsprogs version 3.1.7+b1. And the filesystem is 6TB in size. If you want to take a look, please let me know what I can do to help. Thank you, -- Tapani Tarvainen From cmaiolino@redhat.com Thu Sep 10 04:22:33 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 3D86A7CBF for ; Thu, 10 Sep 2015 04:22:33 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 30913304039 for ; Thu, 10 Sep 2015 02:22:30 -0700 (PDT) X-ASG-Debug-ID: 1441876948-04cbb005ea3f8b0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id pe7dun57H8P37Qte (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 02:22:29 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 22147C0B2B49; Thu, 10 Sep 2015 09:22:28 +0000 (UTC) Received: from zion.usersys.redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8A9MP1A025630 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2015 05:22:27 -0400 Date: Thu, 10 Sep 2015 11:22:24 +0200 From: Carlos Maiolino To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c Message-ID: <20150910092224.GB2613@zion.usersys.redhat.com> X-ASG-Orig-Subj: Re: [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c Mail-Followup-To: Eric Sandeen , xfs@oss.sgi.com References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1441876949 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:33:58PM -0500, Eric Sandeen wrote: > repair/dir2.c and repair/attr_repair.c got cut and pasted > long, long ago and have diverged since. > > This series brings them back together, presumably fixes some > bugs, and loses a few hundred lines in the process. > > o/~ reunited, and it feels so so good ... o/~ > > The series accomplishes this through a combination of trivial changes > (removing unused structure members, whitespace, etc) as well > as by "cross-porting" changes & fixes which happened to one > file but not the other over the past many years. > > Along the way, a graphical diff of dir2 vs. attr_repair should > show the convergence. > > Up until the last patch, I don't worry about dir vs. attr naming > in comments or error messages; the goal is to make these chunks > of the two files sufficiently similar so that by patch 11, the > reviewer can do a diff and say "yeah, ok, those really are > substantially the same now." > > Also instructive is to apply up to patch 11, copy dir2.c and > attr_repair.c to /tmp, apply patch 12, and do a 3-way graphical > diff of the 3 files to see that the move really is OK and > didn't play any significant tricks. > > The last patch fixes up the dir vs. attr text in error messages > and comments. I do have a question about whether this is ok > for i8n: > > printf(_("This string is %s"), _("awesome")); This should be fine for i18n, I had used it a lot when I added i18n support in gfs2-utils, and _() is the default macro that should embrace every string that needs to be translated. It will be replaced by gettext("awesome"), and there is no problem in using it as printf() argument for format specifiers. What you should be careful though, is that how these strings will 'look' to the person translating it, which, in most of cases, they are not going to look at the code to get a better meaning of the string. So, the sentences to be translated, should make sense by itself. I particularly, don't like much the idea of split strings as you did in the example, exactly because how it might look to the translators, both strings makes the same sentence, but they will show to the translators as completely different strings, and the translator might not be able to find the proper grammatical construction. So, I'd do something like: printf(funny ? _("This string is awesome") : _("This string is boring")) I know that I might sound picky here, but, this is the best way to avoid weird and non-sense string translations. > > because that's essentially the trick I used... > > Thanks, > -Eric > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- Carlos From tapani.j.tarvainen@jyu.fi Thu Sep 10 05:31:53 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 5949B7F47 for ; Thu, 10 Sep 2015 05:31:53 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id C6EDDAC008 for ; Thu, 10 Sep 2015 03:31:49 -0700 (PDT) X-ASG-Debug-ID: 1441881103-04cb6c355b3dee0001-NocioJ Received: from posti5.jyu.fi (posti5.jyu.fi [130.234.4.34]) by cuda.sgi.com with ESMTP id wQsAH3rqFZWdBAFV (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Sep 2015 03:31:44 -0700 (PDT) X-Barracuda-Envelope-From: tapani.j.tarvainen@jyu.fi X-Barracuda-Apparent-Source-IP: 130.234.4.34 Received: from localhost (localhost.localdomain [127.0.0.1]) by posti5.jyu.fi (8.13.8/8.13.8) with ESMTP id t8AAVhRM032731 for ; Thu, 10 Sep 2015 13:31:43 +0300 X-Virus-Scanned: amavisd-new at cc.jyu.fi Received: from posti5.jyu.fi ([127.0.0.1]) by localhost (posti5.jyu.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17roYesaK6ff for ; Thu, 10 Sep 2015 13:31:42 +0300 (EEST) Received: from tehanu.it.jyu.fi (tehanu.it.jyu.fi [130.234.160.128]) by posti5.jyu.fi (8.13.8/8.13.8) with ESMTP id t8AAVgvC032717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Sep 2015 13:31:42 +0300 Received: (from tt@localhost) by tehanu.it.jyu.fi (8.14.4/8.14.4/Submit) id t8AAVgBs026892 for xfs@oss.sgi.com; Thu, 10 Sep 2015 13:31:42 +0300 X-Authentication-Warning: tehanu.it.jyu.fi: tt set sender to tapani.j.tarvainen@jyu.fi using -f Date: Thu, 10 Sep 2015 13:31:42 +0300 From: Tapani Tarvainen To: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910103142.GA26847@tehanu.it.jyu.fi> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910091834.GC24937@tehanu.it.jyu.fi> User-Agent: Mutt/1.5.20 (2009-12-10) X-Barracuda-Connect: posti5.jyu.fi[130.234.4.34] X-Barracuda-Start-Time: 1441881103 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22402 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- A perhaps interesting addition: xfs_metadump succeeds with the -o option (without it it fails consistently). If you think the dump would be useful to you I can probably send it unobfuscated (would have to check but I don't think there's anything sensitive in the filenames or attributes). -- Tapani Tarvainen On 10 Sep 12:18, Tapani Tarvainen (tapani.j.tarvainen@jyu.fi) wrote: > > Hi, > > After a rather spectacular crash we've got an xfs filesystem > in unrepairable state: mount fails with "Structure needs cleaning", > xfs_repair without options refuses to work (asks to mount first), > and xfs_repair -L stopped with > > corrupt dinode 2151195170, extent total = 1, nblocks = 0. This is a bug. > Please capture the filesystem metadata with xfs_metadump and > report it to xfs@oss.sgi.com. > > I tried to dump the metadata and it failed, too: > > # xfs_metadump /dev/sdata1/data1 /data2/tmp/data1_metadump > xfs_metadump: cannot init perag data (117) > *** glibc detected *** xfs_db: double free or corruption (!prev): 0x0000000003361000 *** > ======= Backtrace: ========= > [...] > Aborted > > > At this point I'm going to give up trying to recover the data > (recreate filesystem and restore from backup), but if you want to > analyze it to find the bug, I have enough spare disk space to keep a > copy for a while (took lvm snapshot of it before recovery attempt, > could dd it to another location). > > The machine is running Debian Wheezy (7.8), > kernel 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux, > xfsprogs version 3.1.7+b1. > And the filesystem is 6TB in size. > > If you want to take a look, please let me know what I can do to help. > > Thank you, > > -- > Tapani Tarvainen From jtulak@redhat.com Thu Sep 10 06:37:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id B79D17F47 for ; Thu, 10 Sep 2015 06:37:40 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 4FEDEAC008 for ; Thu, 10 Sep 2015 04:37:37 -0700 (PDT) X-ASG-Debug-ID: 1441885055-04bdf04db343350001-NocioJ Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by cuda.sgi.com with ESMTP id TGQVbFETa9kYJhB1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 10 Sep 2015 04:37:36 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-RBL-Trusted-Forwarder: 209.85.223.169 Received: by iofb144 with SMTP id b144so57030338iof.1 for ; Thu, 10 Sep 2015 04:37:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=Et4pvcCgy8mdw9wGo7uLgD3+6/gZoc9pJ4UNUTdF/hc=; b=OBlC/l/yBAclaA4AucRXeD+BldMkM0lrPmBvL0lNTgJGocMZGqqVpKh5clb1zooBUS U6OfISFsfILF0TfdeN4xvRbGUTqur+O8wiwS64HwzZ+dBKFnohNmeFFPf6drIy3uIub9 9O9XOw4AG/tnOaypLEEQqVJ3IE+yLPZcZpYkchUIxIaCzvZJA6afpwVytvNZiB216o8H 0c/qVAcXPyOOtsqH2ngmYqeY4cpM+sSLYhop14QmOWYxCgbcqkC4RZ9mZt2blRrWcRUh 1mP1sKvIXv2bGf9T5HacHRLobi+Qsy053PgI8ZDPrhbKExORQB3FBDfX4inqhDUwna3r 7xOg== X-Gm-Message-State: ALoCoQlVtROfUFj5Hiko0yJaI6cjf1sCNEo5PV7AR+SDlQas8N9ottK7NRRS2SLAshmgtM9vgQLi X-Received: by 10.107.25.71 with SMTP id 68mr31745394ioz.46.1441885055484; Thu, 10 Sep 2015 04:37:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Thu, 10 Sep 2015 04:37:16 -0700 (PDT) In-Reply-To: References: From: Jan Tulak Date: Thu, 10 Sep 2015 13:37:16 +0200 Message-ID: Subject: Re: xfsprogs - debug build with -O0 To: xfs-oss X-ASG-Orig-Subj: Re: xfsprogs - debug build with -O0 Content-Type: multipart/alternative; boundary=001a113ff20e8a263e051f6306ce X-Barracuda-Connect: mail-io0-f169.google.com[209.85.223.169] X-Barracuda-Start-Time: 1441885056 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22403 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --001a113ff20e8a263e051f6306ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 9, 2015 at 2:35 PM, Jan Tulak wrote: > Hi all, > > Is there a way how to disable compiler optimisation in xfsprogs? It shoul= d > be done with setting env variable OPTIMIZER=3D'-O0', however, even though > this is mentioned on few places in xfsprogs, it doesn't work and the > configure file always use "-O2" from autogenerated m4/libtool.m4. Other > environment variables works as expected. > > So far, when in need of debugging, I have been manually replacing -O2 wit= h > -O0 in configure, but this isn't a good solution. So, is there another wa= y, > or it is just broken? I find it strange that nobody would mind messed GDB > outputs... :-) > =E2=80=8BSo to reply to myself, it looks like it was an issue only on my ho= st. When I tried it on another pc, it worked ok and after some time with changing various global environment variables, it suddenly began to work on the first host too. I will keep an eye on it if the issue appears again, to find what really caused it. But for now, consider the previous email as a false alert. Cheers, Jan --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --001a113ff20e8a263e051f6306ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Se= p 9, 2015 at 2:35 PM, Jan Tulak <jtulak@redhat.com> wrote:
Hi all,

Is there a way how to disable compiler optimisation in xfsprogs? It sho= uld be done with setting env variable OPTIMIZER=3D'-O0', however, e= ven though this is mentioned on few places in xfsprogs, it doesn't work= and the configure file always use "-O2" from autogenerated m4/li= btool.m4. Other environment variables works as expected.

So far, when in need of debugging, I have bee= n manually replacing -O2 with -O0 in configure, but this isn't a good s= olution. So, is there another way, or it is just broken? I find it strange = that nobody would mind messed GDB outputs... :-)

=E2=80=8BSo to reply to myself, it look= s like it was an issue only on my host.=C2=A0

When I tried it on another pc, = it worked ok and after some time with changing various global environment v= ariables, it suddenly began to work on the first host too. I will keep an e= ye on it if the issue appears again, to find what really caused it. But for= now, consider the previous email as a false alert.

Cheers,
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;display:inline">Jan

--
--001a113ff20e8a263e051f6306ce-- From eflorac@intellique.com Thu Sep 10 06:47:01 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2285D7F47 for ; Thu, 10 Sep 2015 06:47:01 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 16939304039 for ; Thu, 10 Sep 2015 04:47:01 -0700 (PDT) X-ASG-Debug-ID: 1441885615-04cbb005ec43600001-NocioJ Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by cuda.sgi.com with ESMTP id FkMCYCDWuSBENh4U (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 04:46:55 -0700 (PDT) X-Barracuda-Envelope-From: eflorac@intellique.com X-Barracuda-Apparent-Source-IP: 66.39.3.162 Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id 2FACB2CA1B; Thu, 10 Sep 2015 07:46:55 -0400 (EDT) Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72]) by mail1.g1.pair.com (Postfix) with ESMTPSA id 797A22CA4B; Thu, 10 Sep 2015 07:46:54 -0400 (EDT) Date: Thu, 10 Sep 2015 13:46:57 +0200 From: Emmanuel Florac To: Christophe Baegert Cc: xfs@oss.sgi.com Subject: Re: bug during xfs_repair -L on 1TB of strategic data Message-ID: <20150910134657.4cac43ec@harpe.intellique.com> X-ASG-Orig-Subj: Re: bug during xfs_repair -L on 1TB of strategic data In-Reply-To: <55F116A4.5080106@lixium.fr> References: <55F116A4.5080106@lixium.fr> Organization: Intellique X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.20; i486-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail1.g1.pair.com[66.39.3.162] X-Barracuda-Start-Time: 1441885615 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22403 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Le Thu, 10 Sep 2015 07:35:32 +0200 Christophe Baegert =C3=A9crivait: > Hi, >=20 > I see this message when repairing an XFS partition of 1TB of > strategic data (on Debian Wheezy) >=20 > What can I do ? >=20 > corrupt dinode 1933282003, extent total =3D 1, nblocks =3D 0. This is a > bug. Please capture the filesystem metadata with xfs_metadump and > report it to xfs@oss.sgi.com. > cache_node_purge: refcount was 1, not zero (node=3D0x7f7c55b35220) >=20 > fatal error -- 117 - couldn't iget disconnected inode >=20 Don't use the ancient version of xfs_repair that comes with Wheezy, use a more recent version, at least a 3.2.x release. --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From eflorac@intellique.com Thu Sep 10 06:48:29 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 502C37F47 for ; Thu, 10 Sep 2015 06:48:29 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id DDB29AC009 for ; Thu, 10 Sep 2015 04:48:28 -0700 (PDT) X-ASG-Debug-ID: 1441885706-04cbb005e9436b0001-NocioJ Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by cuda.sgi.com with ESMTP id HewqirYBcmCxo2vl (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 04:48:27 -0700 (PDT) X-Barracuda-Envelope-From: eflorac@intellique.com X-Barracuda-Apparent-Source-IP: 66.39.3.162 Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id 85ED52CB4E; Thu, 10 Sep 2015 07:48:26 -0400 (EDT) Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72]) by mail1.g1.pair.com (Postfix) with ESMTPSA id B568D2CAF5; Thu, 10 Sep 2015 07:48:25 -0400 (EDT) Date: Thu, 10 Sep 2015 13:48:28 +0200 From: Emmanuel Florac To: Tapani Tarvainen Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910134828.0bdfcc4c@harpe.intellique.com> X-ASG-Orig-Subj: Re: "This is a bug." In-Reply-To: <20150910091834.GC24937@tehanu.it.jyu.fi> References: <20150910091834.GC24937@tehanu.it.jyu.fi> Organization: Intellique X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.20; i486-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail1.g1.pair.com[66.39.3.162] X-Barracuda-Start-Time: 1441885707 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22403 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Le Thu, 10 Sep 2015 12:18:34 +0300 Tapani Tarvainen =C3=A9crivait: > xfsprogs version 3.1.7+b1. Don't use that, it's much too old. Use at least a 3.2.x version, or if possible the very latest version of xfs_repair. You can copy over xfs_repair from another machine as it's a static binary. --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From eflorac@intellique.com Thu Sep 10 06:53:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id B6C207F47 for ; Thu, 10 Sep 2015 06:53:05 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 8B2628F804C for ; Thu, 10 Sep 2015 04:53:05 -0700 (PDT) X-ASG-Debug-ID: 1441885981-04bdf04db443bd0001-NocioJ Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by cuda.sgi.com with ESMTP id 8JbI7wAWl3hdDU4w (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 04:53:01 -0700 (PDT) X-Barracuda-Envelope-From: eflorac@intellique.com X-Barracuda-Apparent-Source-IP: 66.39.3.162 Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id 4CE452B6D2; Thu, 10 Sep 2015 07:53:01 -0400 (EDT) Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72]) by mail1.g1.pair.com (Postfix) with ESMTPSA id 88B842A844; Thu, 10 Sep 2015 07:53:00 -0400 (EDT) Date: Thu, 10 Sep 2015 13:53:03 +0200 From: Emmanuel Florac To: Tapani Tarvainen Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910135303.35362bc5@harpe.intellique.com> X-ASG-Orig-Subj: Re: "This is a bug." In-Reply-To: <20150910103142.GA26847@tehanu.it.jyu.fi> References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910103142.GA26847@tehanu.it.jyu.fi> Organization: Intellique X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.20; i486-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail1.g1.pair.com[66.39.3.162] X-Barracuda-Start-Time: 1441885981 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22403 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Le Thu, 10 Sep 2015 13:31:42 +0300 Tapani Tarvainen =C3=A9crivait: > > Hi, > >=20 > > After a rather spectacular crash we've got an xfs filesystem > > in unrepairable state: mount fails with "Structure needs cleaning", > > xfs_repair without options refuses to work (asks to mount first), > > and xfs_repair -L stopped with > >=20 > > corrupt dinode 2151195170, extent total =3D 1, nblocks =3D 0. This is > > a bug. Please capture the filesystem metadata with xfs_metadump and > > report it to xfs@oss.sgi.com. > >=20 If you're not afraid of binaries from the web, I've just compiled xfs-repair 4.2.0 on a Wheezy machine: http://update.intellique.com/pub/xfs_repair-4.2.0.gz --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From eflorac@intellique.com Thu Sep 10 06:53:55 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 1DEEC7F47 for ; Thu, 10 Sep 2015 06:53:55 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 103D3304039 for ; Thu, 10 Sep 2015 04:53:55 -0700 (PDT) X-ASG-Debug-ID: 1441886033-04cb6c355c3fe50001-NocioJ Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by cuda.sgi.com with ESMTP id YC3Wi4wuERWrq7ca (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 04:53:53 -0700 (PDT) X-Barracuda-Envelope-From: eflorac@intellique.com X-Barracuda-Apparent-Source-IP: 66.39.3.162 Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id 3E29D2CCB6; Thu, 10 Sep 2015 07:53:53 -0400 (EDT) Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72]) by mail1.g1.pair.com (Postfix) with ESMTPSA id 81F512CC36; Thu, 10 Sep 2015 07:53:52 -0400 (EDT) Date: Thu, 10 Sep 2015 13:53:55 +0200 From: Emmanuel Florac To: Christophe Baegert Cc: xfs@oss.sgi.com Subject: Re: bug during xfs_repair -L on 1TB of strategic data Message-ID: <20150910135355.4a49927c@harpe.intellique.com> X-ASG-Orig-Subj: Re: bug during xfs_repair -L on 1TB of strategic data In-Reply-To: <55F116A4.5080106@lixium.fr> References: <55F116A4.5080106@lixium.fr> Organization: Intellique X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.20; i486-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail1.g1.pair.com[66.39.3.162] X-Barracuda-Start-Time: 1441886033 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22403 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Le Thu, 10 Sep 2015 07:35:32 +0200 Christophe Baegert =C3=A9crivait: > corrupt dinode 1933282003, extent total =3D 1, nblocks =3D 0. This is a > bug. Please capture the filesystem metadata with xfs_metadump and > report it to xfs@oss.sgi.com. > cache_node_purge: refcount was 1, not zero (node=3D0x7f7c55b35220) >=20 > fatal error -- 117 - couldn't iget disconnected inode I've just compiled xfs_repair 4.2.0 on a wheezy, if you're not afraid of random binaries from strangers here it is: http://update.intellique.com/pub/xfs_repair-4.2.0.gz --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From tapani.j.tarvainen@jyu.fi Thu Sep 10 06:55:57 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 376687F47 for ; Thu, 10 Sep 2015 06:55:57 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 2742A304039 for ; Thu, 10 Sep 2015 04:55:57 -0700 (PDT) X-ASG-Debug-ID: 1441886152-04cb6c355d3ff50001-NocioJ Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by cuda.sgi.com with ESMTP id XDot1PrDAHek0SUa (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Sep 2015 04:55:53 -0700 (PDT) X-Barracuda-Envelope-From: tapani.j.tarvainen@jyu.fi X-Barracuda-Apparent-Source-IP: 130.234.4.43 Received: from localhost (localhost.localdomain [127.0.0.1]) by posti6.jyu.fi (8.13.8/8.13.8) with ESMTP id t8ABtnWx010029; Thu, 10 Sep 2015 14:55:49 +0300 X-Virus-Scanned: amavisd-new at cc.jyu.fi Received: from posti6.jyu.fi ([127.0.0.1]) by localhost (posti6.jyu.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBeCC6FIs0-Q; Thu, 10 Sep 2015 14:55:49 +0300 (EEST) Received: from tehanu.it.jyu.fi (tehanu.it.jyu.fi [130.234.160.128]) by posti6.jyu.fi (8.13.8/8.13.8) with ESMTP id t8ABtmx9010018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2015 14:55:49 +0300 Received: (from tt@localhost) by tehanu.it.jyu.fi (8.14.4/8.14.4/Submit) id t8ABtma3027773; Thu, 10 Sep 2015 14:55:48 +0300 X-Authentication-Warning: tehanu.it.jyu.fi: tt set sender to tapani.j.tarvainen@jyu.fi using -f Date: Thu, 10 Sep 2015 14:55:48 +0300 From: Tapani Tarvainen To: Emmanuel Florac Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910115548.GD26847@tehanu.it.jyu.fi> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910134828.0bdfcc4c@harpe.intellique.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910134828.0bdfcc4c@harpe.intellique.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-Barracuda-Connect: posti6.jyu.fi[130.234.4.43] X-Barracuda-Start-Time: 1441886153 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22403 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 10 Sep 13:48, Emmanuel Florac (eflorac@intellique.com) wrote: > > xfsprogs version 3.1.7+b1. > > Don't use that, it's much too old. Use at least a 3.2.x version, or if > possible the very latest version of xfs_repair. You can copy over > xfs_repair from another machine as it's a static binary. Seems it isn't static in Debian (copied over from a Jessie box): # /home/tt/xfs_repair -v /dev/sdata1/data1 /home/tt/xfs_repair: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /home/tt/xfs_repair) But if a new version is really likely to help I can build it from source. Thank you for the suggestion. -- Tapani Tarvainen From tapani.j.tarvainen@jyu.fi Thu Sep 10 07:05:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id A8ACD7F47 for ; Thu, 10 Sep 2015 07:05:22 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 8DCC9304048 for ; Thu, 10 Sep 2015 05:05:19 -0700 (PDT) X-ASG-Debug-ID: 1441886714-04cbb005ec43f90001-NocioJ Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by cuda.sgi.com with ESMTP id QDXdnM103FwhhC9s (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Sep 2015 05:05:16 -0700 (PDT) X-Barracuda-Envelope-From: tapani.j.tarvainen@jyu.fi X-Barracuda-Apparent-Source-IP: 130.234.4.43 Received: from localhost (localhost.localdomain [127.0.0.1]) by posti6.jyu.fi (8.13.8/8.13.8) with ESMTP id t8AC5CCC011538; Thu, 10 Sep 2015 15:05:12 +0300 X-Virus-Scanned: amavisd-new at cc.jyu.fi Received: from posti6.jyu.fi ([127.0.0.1]) by localhost (posti6.jyu.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egqRZlvrM-UD; Thu, 10 Sep 2015 15:05:12 +0300 (EEST) Received: from tehanu.it.jyu.fi (tehanu.it.jyu.fi [130.234.160.128]) by posti6.jyu.fi (8.13.8/8.13.8) with ESMTP id t8AC5Crc011534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2015 15:05:12 +0300 Received: (from tt@localhost) by tehanu.it.jyu.fi (8.14.4/8.14.4/Submit) id t8AC5CDB027927; Thu, 10 Sep 2015 15:05:12 +0300 X-Authentication-Warning: tehanu.it.jyu.fi: tt set sender to tapani.j.tarvainen@jyu.fi using -f Date: Thu, 10 Sep 2015 15:05:12 +0300 From: Tapani Tarvainen To: Emmanuel Florac Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910120512.GE26847@tehanu.it.jyu.fi> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910103142.GA26847@tehanu.it.jyu.fi> <20150910135303.35362bc5@harpe.intellique.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910135303.35362bc5@harpe.intellique.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-Barracuda-Connect: posti6.jyu.fi[130.234.4.43] X-Barracuda-Start-Time: 1441886715 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22403 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 10 Sep 13:53, Emmanuel Florac (eflorac@intellique.com) wrote: > If you're not afraid of binaries from the web, I've just compiled > xfs-repair 4.2.0 on a Wheezy machine: Thanks, but I'd just compiled it myself... waiting to see what it does. -- Tapani Tarvainen From tapani.j.tarvainen@jyu.fi Thu Sep 10 07:30:39 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id CD3F47F47 for ; Thu, 10 Sep 2015 07:30:39 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id AE49E8F804C for ; Thu, 10 Sep 2015 05:30:36 -0700 (PDT) X-ASG-Debug-ID: 1441888233-04bdf04db644f10001-NocioJ Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by cuda.sgi.com with ESMTP id oowgiXLDnzkHF1YD (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Sep 2015 05:30:34 -0700 (PDT) X-Barracuda-Envelope-From: tapani.j.tarvainen@jyu.fi X-Barracuda-Apparent-Source-IP: 130.234.4.43 Received: from localhost (localhost.localdomain [127.0.0.1]) by posti6.jyu.fi (8.13.8/8.13.8) with ESMTP id t8ACUVZI015319; Thu, 10 Sep 2015 15:30:31 +0300 X-Virus-Scanned: amavisd-new at cc.jyu.fi Received: from posti6.jyu.fi ([127.0.0.1]) by localhost (posti6.jyu.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGwiLLeIj6HK; Thu, 10 Sep 2015 15:30:31 +0300 (EEST) Received: from tehanu.it.jyu.fi (tehanu.it.jyu.fi [130.234.160.128]) by posti6.jyu.fi (8.13.8/8.13.8) with ESMTP id t8ACUU9w015315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2015 15:30:31 +0300 Received: (from tt@localhost) by tehanu.it.jyu.fi (8.14.4/8.14.4/Submit) id t8ACUUHt028135; Thu, 10 Sep 2015 15:30:30 +0300 X-Authentication-Warning: tehanu.it.jyu.fi: tt set sender to tapani.j.tarvainen@jyu.fi using -f Date: Thu, 10 Sep 2015 15:30:30 +0300 From: Tapani Tarvainen To: Emmanuel Florac Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910123030.GG26847@tehanu.it.jyu.fi> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910115548.GD26847@tehanu.it.jyu.fi> User-Agent: Mutt/1.5.20 (2009-12-10) X-Barracuda-Connect: posti6.jyu.fi[130.234.4.43] X-Barracuda-Start-Time: 1441888234 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22404 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 10 Sep 14:55, Tapani Tarvainen (tapani.j.tarvainen@jyu.fi) wrote: > On 10 Sep 13:48, Emmanuel Florac (eflorac@intellique.com) wrote: > > > > xfsprogs version 3.1.7+b1. > > > > Don't use that, it's much too old. Use at least a 3.2.x version, or if > > possible the very latest version of xfs_repair. With (self-compiled) 4.2.0 version xfs_repair without -L no longer refuses to run but after a while failed with [...] correcting nextents for inode 2152363147 xfs_repair: dinode.c:1961: process_inode_data_fork: Assertion `err == 0' failed. Aborted With -L ... same result. -- Tapani Tarvainen From bfoster@redhat.com Thu Sep 10 07:36:10 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 8C4C07F47 for ; Thu, 10 Sep 2015 07:36:10 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 24D07AC008 for ; Thu, 10 Sep 2015 05:36:07 -0700 (PDT) X-ASG-Debug-ID: 1441888565-04cb6c355b41020001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id HF2igtCpvvF5QFkO (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 05:36:06 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 905F7C0AA287; Thu, 10 Sep 2015 12:36:05 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8ACa5WB026303; Thu, 10 Sep 2015 08:36:05 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 4A5FD1236D9; Thu, 10 Sep 2015 08:36:04 -0400 (EDT) Date: Thu, 10 Sep 2015 08:36:04 -0400 From: Brian Foster To: Tapani Tarvainen Cc: Emmanuel Florac , xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910123603.GA27863@bfoster.bfoster> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910123030.GG26847@tehanu.it.jyu.fi> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441888566 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 10, 2015 at 03:30:30PM +0300, Tapani Tarvainen wrote: > On 10 Sep 14:55, Tapani Tarvainen (tapani.j.tarvainen@jyu.fi) wrote: > > On 10 Sep 13:48, Emmanuel Florac (eflorac@intellique.com) wrote: > > > > > > xfsprogs version 3.1.7+b1. > > > > > > Don't use that, it's much too old. Use at least a 3.2.x version, or if > > > possible the very latest version of xfs_repair. > > With (self-compiled) 4.2.0 version xfs_repair without -L no longer > refuses to run but after a while failed with > > [...] > correcting nextents for inode 2152363147 > xfs_repair: dinode.c:1961: process_inode_data_fork: Assertion `err == 0' failed. > Aborted > > With -L ... same result. > Care to post the metadump? Brian > -- > Tapani Tarvainen > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From tapani.j.tarvainen@jyu.fi Thu Sep 10 07:54:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id BA96E7F4E for ; Thu, 10 Sep 2015 07:54:48 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 235D0AC008 for ; Thu, 10 Sep 2015 05:54:48 -0700 (PDT) X-ASG-Debug-ID: 1441889685-04cb6c355d416f0001-NocioJ Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by cuda.sgi.com with ESMTP id JSfbAGGuGcNsWrXO (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Sep 2015 05:54:46 -0700 (PDT) X-Barracuda-Envelope-From: tapani.j.tarvainen@jyu.fi X-Barracuda-Apparent-Source-IP: 130.234.4.43 Received: from localhost (localhost.localdomain [127.0.0.1]) by posti6.jyu.fi (8.13.8/8.13.8) with ESMTP id t8ACsgDF018597; Thu, 10 Sep 2015 15:54:42 +0300 X-Virus-Scanned: amavisd-new at cc.jyu.fi Received: from posti6.jyu.fi ([127.0.0.1]) by localhost (posti6.jyu.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxSmnEuljkmh; Thu, 10 Sep 2015 15:54:42 +0300 (EEST) Received: from tehanu.it.jyu.fi (tehanu.it.jyu.fi [130.234.160.128]) by posti6.jyu.fi (8.13.8/8.13.8) with ESMTP id t8ACsfD5018592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2015 15:54:42 +0300 Received: (from tt@localhost) by tehanu.it.jyu.fi (8.14.4/8.14.4/Submit) id t8ACsfFE028434; Thu, 10 Sep 2015 15:54:41 +0300 X-Authentication-Warning: tehanu.it.jyu.fi: tt set sender to tapani.j.tarvainen@jyu.fi using -f Date: Thu, 10 Sep 2015 15:54:41 +0300 From: Tapani Tarvainen To: Brian Foster Cc: Emmanuel Florac , xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910125441.GA28374@tehanu.it.jyu.fi> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910123603.GA27863@bfoster.bfoster> User-Agent: Mutt/1.5.20 (2009-12-10) X-Barracuda-Connect: posti6.jyu.fi[130.234.4.43] X-Barracuda-Start-Time: 1441889685 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 2.00 X-Barracuda-Spam-Status: No, SCORE=2.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC7_MV0607 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22404 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 2.00 BSF_SC7_MV0607 URI: Custom rule MV0607 On 10 Sep 08:36, Brian Foster (bfoster@redhat.com) wrote: > Care to post the metadump? It is 2.5GB so not really nice to mail... but if you want to take a look, here it is: https://huom.it.jyu.fi/tmp/data1.metadump -- Tapani Tarvainen From bfoster@redhat.com Thu Sep 10 08:01:13 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6D2927F50 for ; Thu, 10 Sep 2015 08:01:13 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 5B0548F8035 for ; Thu, 10 Sep 2015 06:01:10 -0700 (PDT) X-ASG-Debug-ID: 1441890068-04cbb005e945990001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id u7ziUhXgATFLG41W (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 06:01:09 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 92B532F02C7; Thu, 10 Sep 2015 13:01:08 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8AD18ae013322; Thu, 10 Sep 2015 09:01:08 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 3423C1236D9; Thu, 10 Sep 2015 09:01:07 -0400 (EDT) Date: Thu, 10 Sep 2015 09:01:07 -0400 From: Brian Foster To: Tapani Tarvainen Cc: Emmanuel Florac , xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910130106.GB27863@bfoster.bfoster> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> <20150910125441.GA28374@tehanu.it.jyu.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910125441.GA28374@tehanu.it.jyu.fi> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1441890069 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 10, 2015 at 03:54:41PM +0300, Tapani Tarvainen wrote: > On 10 Sep 08:36, Brian Foster (bfoster@redhat.com) wrote: > > > Care to post the metadump? > > It is 2.5GB so not really nice to mail... but if you want > to take a look, here it is: > > https://huom.it.jyu.fi/tmp/data1.metadump > Can you compress it? Brian > -- > Tapani Tarvainen From tapani.j.tarvainen@jyu.fi Thu Sep 10 08:05:38 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 9BCE87F55 for ; Thu, 10 Sep 2015 08:05:38 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 799CB8F8037 for ; Thu, 10 Sep 2015 06:05:38 -0700 (PDT) X-ASG-Debug-ID: 1441890335-04cbb005ec45bb0001-NocioJ Received: from posti5.jyu.fi (posti5.jyu.fi [130.234.4.34]) by cuda.sgi.com with ESMTP id Nafk0XiXW1fYlVSc (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Sep 2015 06:05:36 -0700 (PDT) X-Barracuda-Envelope-From: tapani.j.tarvainen@jyu.fi X-Barracuda-Apparent-Source-IP: 130.234.4.34 Received: from localhost (localhost.localdomain [127.0.0.1]) by posti5.jyu.fi (8.13.8/8.13.8) with ESMTP id t8AD5Wre024142; Thu, 10 Sep 2015 16:05:32 +0300 X-Virus-Scanned: amavisd-new at cc.jyu.fi Received: from posti5.jyu.fi ([127.0.0.1]) by localhost (posti5.jyu.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYy6xI4dj-Gm; Thu, 10 Sep 2015 16:05:32 +0300 (EEST) Received: from tehanu.it.jyu.fi (tehanu.it.jyu.fi [130.234.160.128]) by posti5.jyu.fi (8.13.8/8.13.8) with ESMTP id t8AD5UWj024136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2015 16:05:31 +0300 Received: (from tt@localhost) by tehanu.it.jyu.fi (8.14.4/8.14.4/Submit) id t8AD5U1b028551; Thu, 10 Sep 2015 16:05:30 +0300 X-Authentication-Warning: tehanu.it.jyu.fi: tt set sender to tapani.j.tarvainen@jyu.fi using -f Date: Thu, 10 Sep 2015 16:05:30 +0300 From: Tapani Tarvainen To: Brian Foster Cc: Emmanuel Florac , xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910130530.GB28374@tehanu.it.jyu.fi> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> <20150910125441.GA28374@tehanu.it.jyu.fi> <20150910130106.GB27863@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910130106.GB27863@bfoster.bfoster> User-Agent: Mutt/1.5.20 (2009-12-10) X-Barracuda-Connect: posti5.jyu.fi[130.234.4.34] X-Barracuda-Start-Time: 1441890335 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 2.00 X-Barracuda-Spam-Status: No, SCORE=2.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC7_MV0607 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22404 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 2.00 BSF_SC7_MV0607 URI: Custom rule MV0607 On 10 Sep 09:01, Brian Foster (bfoster@redhat.com) wrote: > > It is 2.5GB so not really nice to mail... > Can you compress it? Ah. Of course, should've done it in the first place. Still 250MB though: https://huom.it.jyu.fi/tmp/data1.metadump.gz -- Tapani Tarvainen From c.baegert@lixium.fr Thu Sep 10 09:10:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 86ECC7F4E for ; Thu, 10 Sep 2015 09:10:40 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 755568F8037 for ; Thu, 10 Sep 2015 07:10:37 -0700 (PDT) X-ASG-Debug-ID: 1441894235-04cbb005eb47d10001-NocioJ Received: from mx2.lixium.fr (mx2.lixium.fr [79.98.96.12]) by cuda.sgi.com with ESMTP id U4XgVpKryFBLYFRE for ; Thu, 10 Sep 2015 07:10:35 -0700 (PDT) X-Barracuda-Envelope-From: c.baegert@lixium.fr X-Barracuda-Apparent-Source-IP: 79.98.96.12 Received: from [192.168.1.21] (nsg93-h01-31-34-69-35.dsl.sta.abo.bbox.fr [31.34.69.35]) (Authenticated sender: europeanservers-c.baegert-maildrop@mx2.lixium.fr) by mx2.lixium.fr (Postfix) with ESMTPSA id 93EE761CBE87; Thu, 10 Sep 2015 16:10:34 +0200 (CEST) Message-ID: <55F18F68.408@lixium.fr> Date: Thu, 10 Sep 2015 16:10:48 +0200 From: Christophe Baegert User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Emmanuel Florac CC: xfs@oss.sgi.com Subject: Re: bug during xfs_repair -L on 1TB of strategic data References: <55F116A4.5080106@lixium.fr> <20150910135355.4a49927c@harpe.intellique.com> X-ASG-Orig-Subj: Re: bug during xfs_repair -L on 1TB of strategic data In-Reply-To: <20150910135355.4a49927c@harpe.intellique.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Barracuda-Connect: mx2.lixium.fr[79.98.96.12] X-Barracuda-Start-Time: 1441894235 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22405 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Hi Emmanuel Le 10/09/2015 13:53, Emmanuel Florac a écrit : > I've just compiled xfs_repair 4.2.0 on a wheezy, if you're not afraid > of random binaries from strangers here it is: > > http://update.intellique.com/pub/xfs_repair-4.2.0.gz Thanks, I found the same solution and it worked, thank your for your help ! Regards, Christophe From bfoster@redhat.com Thu Sep 10 09:51:58 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 8BB287F54 for ; Thu, 10 Sep 2015 09:51:58 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 781D68F8035 for ; Thu, 10 Sep 2015 07:51:58 -0700 (PDT) X-ASG-Debug-ID: 1441896716-04cbb005ea492c0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Rvb3a9lDjXvXKfUI (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 07:51:57 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id A48928F306; Thu, 10 Sep 2015 14:51:56 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8AEpuOZ022417; Thu, 10 Sep 2015 10:51:56 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 0058C1236D9; Thu, 10 Sep 2015 10:51:54 -0400 (EDT) Date: Thu, 10 Sep 2015 10:51:54 -0400 From: Brian Foster To: Tapani Tarvainen Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910145154.GC27863@bfoster.bfoster> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> <20150910125441.GA28374@tehanu.it.jyu.fi> <20150910130106.GB27863@bfoster.bfoster> <20150910130530.GB28374@tehanu.it.jyu.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910130530.GB28374@tehanu.it.jyu.fi> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441896717 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 10, 2015 at 04:05:30PM +0300, Tapani Tarvainen wrote: > On 10 Sep 09:01, Brian Foster (bfoster@redhat.com) wrote: > > > > It is 2.5GB so not really nice to mail... > > > Can you compress it? > > Ah. Of course, should've done it in the first place. > Still 250MB though: > > https://huom.it.jyu.fi/tmp/data1.metadump.gz > First off, I see ~60MB of corruption output before I even get to the reported repair failure, so this appears to be an extremely severe corruption and I wouldn't be surprised if ultimately beyond repair (not that it matters for you, since you are restoring from backups). The failure itself is an assert failure against an error return value that appears to have a fallback path, so I'm not really sure why it's there. I tried just removing it to see what happens. It ran to completion, but there was a ton of output, write verifier errors, etc., so I'm not totally sure how coherent the result is yet. I'll run another repair pass and do some directory traversals and whatnot and see if it explodes... I suspect what's more interesting at this point is what happened to cause this level of corruption? What kind of event lead to this? Was it a pure filesystem crash or some kind of hardware/raid failure? Also, do you happen to know the geometry (xfs_info) of the original fs? Repair was showing agno's up in the 20k's and now that I've mounted the repaired image, xfs_info shows the following: meta-data=/dev/loop0 isize=256 agcount=24576, agsize=65536 blks = sectsz=4096 attr=2, projid32bit=0 = crc=0 finobt=0 spinodes=0 data = bsize=4096 blocks=1610612736, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal bsize=4096 blocks=2560, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 So that's a 6TB fs with over 24000 allocation groups of size 256MB, as opposed to the mkfs default of 6 allocation groups of 1TB each. Is that intentional? Brian > -- > Tapani Tarvainen > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Thu Sep 10 10:05:32 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id EEC5E7F54 for ; Thu, 10 Sep 2015 10:05:31 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id DBB2A304051 for ; Thu, 10 Sep 2015 08:05:28 -0700 (PDT) X-ASG-Debug-ID: 1441897527-04cb6c355a45300001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id RoD0rxt4HlnDc87k (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 08:05:27 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 48B73C0AE693; Thu, 10 Sep 2015 15:05:27 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8AF5QOX002863; Thu, 10 Sep 2015 11:05:27 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id C72B71236D9; Thu, 10 Sep 2015 11:05:25 -0400 (EDT) Date: Thu, 10 Sep 2015 11:05:25 -0400 From: Brian Foster To: Tapani Tarvainen Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910150525.GD27863@bfoster.bfoster> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> <20150910125441.GA28374@tehanu.it.jyu.fi> <20150910130106.GB27863@bfoster.bfoster> <20150910130530.GB28374@tehanu.it.jyu.fi> <20150910145154.GC27863@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910145154.GC27863@bfoster.bfoster> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441897527 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 10, 2015 at 10:51:54AM -0400, Brian Foster wrote: > On Thu, Sep 10, 2015 at 04:05:30PM +0300, Tapani Tarvainen wrote: > > On 10 Sep 09:01, Brian Foster (bfoster@redhat.com) wrote: > > > > > > It is 2.5GB so not really nice to mail... > > > > > Can you compress it? > > > > Ah. Of course, should've done it in the first place. > > Still 250MB though: > > > > https://huom.it.jyu.fi/tmp/data1.metadump.gz > > > > First off, I see ~60MB of corruption output before I even get to the > reported repair failure, so this appears to be an extremely severe > corruption and I wouldn't be surprised if ultimately beyond repair (not > that it matters for you, since you are restoring from backups). > > The failure itself is an assert failure against an error return value > that appears to have a fallback path, so I'm not really sure why it's > there. I tried just removing it to see what happens. It ran to > completion, but there was a ton of output, write verifier errors, etc., > so I'm not totally sure how coherent the result is yet. I'll run another > repair pass and do some directory traversals and whatnot and see if it > explodes... > FWIW, the follow up repair did come up clean so it appears (so far) to have put the fs back together from a metadata standpoint. That said, >570k files end up in lost+found and who knows whether the files themselves would have contained the expected data once all of the bmaps are fixed up and whatnot. Brian > I suspect what's more interesting at this point is what happened to > cause this level of corruption? What kind of event lead to this? Was it > a pure filesystem crash or some kind of hardware/raid failure? > > Also, do you happen to know the geometry (xfs_info) of the original fs? > Repair was showing agno's up in the 20k's and now that I've mounted the > repaired image, xfs_info shows the following: > > meta-data=/dev/loop0 isize=256 agcount=24576, agsize=65536 blks > = sectsz=4096 attr=2, projid32bit=0 > = crc=0 finobt=0 spinodes=0 > data = bsize=4096 blocks=1610612736, imaxpct=25 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0 ftype=0 > log =internal bsize=4096 blocks=2560, version=2 > = sectsz=4096 sunit=1 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 > > So that's a 6TB fs with over 24000 allocation groups of size 256MB, as > opposed to the mkfs default of 6 allocation groups of 1TB each. Is that > intentional? > > Brian > > > -- > > Tapani Tarvainen > > > > _______________________________________________ > > xfs mailing list > > xfs@oss.sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From ivanbatzella@ivanbatzella.it Thu Sep 10 10:48:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_FONT_SIZE_HUGE, HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: Xfs@oss.sgi.com Delivered-To: Xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 0057D7F54 for ; Thu, 10 Sep 2015 10:48:08 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 91944AC00C for ; Thu, 10 Sep 2015 08:48:04 -0700 (PDT) X-ASG-Debug-ID: 1441900076-04bdf04db44bb40001-l4fVyf Received: from smtpauthrm1.interhost.it (smtpauthrm1.interhost.it [151.11.52.185]) by cuda.sgi.com with ESMTP id EYYCDqiM1IIhDLaY (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Sep 2015 08:47:57 -0700 (PDT) X-Barracuda-Envelope-From: ivanbatzella@ivanbatzella.it X-Barracuda-Apparent-Source-IP: 151.11.52.185 Received: by smtpauthrm1.interhost.it (Postfix, from userid 1000) id AFF0D210053; Thu, 10 Sep 2015 17:47:55 +0200 (CEST) Received: from [192.168.1.129] (93-50-115-70.ip152.fastwebnet.it [93.50.115.70]) by smtpauthrm1.interhost.it (Postfix) with ESMTPA id 4B140210086 for ; Thu, 10 Sep 2015 17:47:54 +0200 (CEST) Message-Id: Mime-Version: 1.0 From: IVAN To: "Recip Recip <> 1 2015-09-05 04:20:30 2015-09-05 04:20:30 51-55 Da 51347 A 6202-1^purge.mbm Xfs@oss.sgi.com 0 Xfs@oss.sgi.com 1 2015-09-05 05:10:18 2015-09-05 05:10:18 <> Xfs@oss.sgi.com Xfs@oss.sgi.com 51-55-Da 6202 A 6071-2^purge.mbm Recip <> Xfs@oss.sgi.com 1 2015-09-05 04:20:30 2015-09-05 04:20:30 51-55 Da 51347 A 6202-1^purge.mbm" Precedence: Bulk Subject: Curriculum Vitae Date: Thu, 10 Sep 2015 17:47:54 +0200 X-ASG-Orig-Subj: Curriculum Vitae X-Bounce-Tracking-Info: Content-type: multipart/alternative; Boundary="--=BOUNDARY_9101747_UKSF_ORTJ_IIAY_MJXE" X-Barracuda-Connect: smtpauthrm1.interhost.it[151.11.52.185] X-Barracuda-Start-Time: 1441900077 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.39 X-Barracuda-Spam-Status: No, SCORE=0.39 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_FONT_SIZE_HUGE, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22407 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.39 HTML_FONT_SIZE_HUGE BODY: HTML font size is huge 0.00 HTML_MESSAGE BODY: HTML included in message Questo messaggio è in formato MIME. Poichè la tua applicazione di posta non interpreta questo formato, una porta o tutto il messaggio potrebbe non essere leggibile. ----=BOUNDARY_9101747_UKSF_ORTJ_IIAY_MJXE Content-type: text/plain; charset=iso-8859-1; format=flowed Content-transfer-encoding: quoted-printable Buon giorno : Mi permetto di inviarvi il mio C=2E Vitae se doveste avere la= necessita' di personale per mansioni che di seguito vi ho descritto= =2E Grazie della vostra attenzione e buona giornata=2E CURRICULUM VITAE (Ricerca per zona Milano e provincia) (N=2EB=2Evogliate scusarmi se questa e-mail dovesse arrivare in province di= fferenti di MI /ad aziende non interessate/a persone estranee a questa rich= iesta) LA RICERCA E' ANCHE NON SPECIFICA AL SETTORE PER QUALSIASI LAVORO=2E(richiesta bassa**) PRESTAZIONI: -PRODUZIONE ED INSTALLAZIONE MACCHINE UTENSILI=2E (TRASFERTE) -BORDO MACCHINA=2E -MAGAZZINIERE -AUTISTA=2E (event=2E:OPERAIO GENERICO) GENERALITA' : NOME : Ivan COGNOME : Batzella NATO A : Milano ANNI : 49 RESIDENTE : Milano (zona V=2Ele Zara) SCUOLA : I=2ET=2EI=2ES=2E L=2E Galvani-Milano VOTAZIONE : 58/'60 INDIRIZZO Tec=2E : Perito Elettrotecnico LINGUE : Inglese appena suff=2E LAVORI SVOLTI : 1990-2001: Montaggio elettromeccanico di macchine per la produzione degli pneumatici+ = gestione pezzi di ricambio a magazzino (Magazziniere/Utilizzo tutti i tipi = di Muletto)=2EQuindi installazione macchina =2E 2001-2005: Installazione di macchine utensili : L'azienda vendeva macchine utensili ch= e commercializzava in tutta Italia=2E La mia mansione era di installare le = macchine utensili (elettroerosioni a filo,centrini di lavoro,=2E=2Eecc) in = Italia centro-settentrionale=2E 2006-2010: Assistenza elettrica/(meccanica) su treni T=2EA=2EV=2E per la manutenzione = ordinaria e straordinaria: mi occupavo della riparazione di componenti mecc= anici(piccole parti) ed elettrici=2E 2010-Ad oggi: Produzione macchine/parte:meccanica-elettrica (ritenuta d'acc= onto) per alcune aziende, tra cui, la principale, per la produzione di macc= hine taglio plasma=2ECommessa ormai terminata=2E DISPONIBILITA' : eventualmente anche immediata=2EDo' la disponibilita' anch= e ad apprendere parte di un lavoro non completamente conosciuto** RICERCA DI LAVORO : Stavo cercando un'azienda seria che assume personale,an= che non specifico al mio settore=2E RETRIBUZIONE : Richiesta bassa** REFERENZE : Buone=2E LAVORO : Serieta',precisione,onesta' e dedizione=2E CONTATTI : Se foste interessati : eventuale contatto, chiamare il numero : = 334/23=2E07=2E365 (Prima delle ore 15 : se spento o non c'e' linea ,lasciar= e 1 messaggio/Dopo le 15 : Sempre)=2E SE AL CONTRARIO NON FOSTE INTERESSATI, CORTESEMENTE SE POTETE SEGNALARLO / DARE MIO NOMINATIVO AD EVENTUALI DITTE = INTERESSATE-DO' MIO CONSENSO=2E GRAZIE TANTISSIMO PER LA VOSTRA CORTESE ATTENZIONE ! Colgo l'occasione per porgerVi i miei piu' Cordiali Saluti=2E Ivan Batzella=2E (N=2EB=2Evogliate scusarmi se questa e-mail dovesse arrivare in province di= fferenti di MI /ad aziende non interessate/a persone estranee a questa rich= iesta) N=2EB=2E : Do' il consenso al trattamento dei miei dati personali ai sensi = dell'articolo 23 del D=2E lgs=2E 196/03 per le finalit=E0 di selezione del = personale=2E ----=BOUNDARY_9101747_UKSF_ORTJ_IIAY_MJXE Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable HTML Message
Buon giorno : Mi permetto di in= viarvi il mio C=2E Vitae se doveste avere la necessita' di personale per ma= nsioni che di seguito vi ho descritto=2E
Grazie della vostra attenzione = e buona giornata=2E=

CURRICULUM VITAE
= (Ricerca per zona Milano e p= rovincia)
(N=2EB=2Evogliate scusarm= i se questa e-mail dovesse arrivare in province differenti di MI /ad aziend= e non interessate/a persone estranee a questa richiesta)
<= /font>


LA RICERCA E' ANCHE NON SPECIFICA AL SET= TORE
PER QUALSIASI LAVORO=2E(richiesta bassa**)


PRESTAZIONI:
-PRODUZIONE ED INSTALLAZIONE MACCH= INE UTENSILI=2E
(TRASFERTE)
-BORDO MACCHINA=2E
-MAGAZZINIERE -AUTISTA=2E
(event=2E:OPERAIO GENERICO)
=
=
=
GENERALITA' :


NOME : Ivan
COGNOME = : Batzella
NATO A : Milano
ANNI : 49
RESID= ENTE : Milano (zona V=2Ele Zara)
SCUOLA : I=2ET=2EI=2ES=2E L=2E Galvani= -Milano
VOTAZIONE : 58/'60
INDIRIZZO Tec=2E : Perito Elettrotecnic= o
LINGUE : Inglese appena suff=2E


LAV= ORI SVOLTI :

1990-2001:
Montaggio= elettromeccanico di macchine per la produzione degli pneumatici+ gestione = pezzi di ricambio a magazzino (Magazziniere/Utilizzo tutti i tipi di Mulett= o)=2EQuindi installazione macchina =2E


2001-2005:
Installazione di macchine utens= ili : L'azienda vendeva macchine utensili che commercializzava in tutta Ita= lia=2E La mia mansione era di installare le macchine utensili (elettroerosi= oni a filo,centrini di lavoro,=2E=2Eecc) in Italia centro-settentrionale= =2E


2006-2010:
Assistenza elettrica= /(meccanica) su treni T=2EA=2EV=2E per la manutenzione ordinaria e straordi= naria: mi occupavo della riparazione di componenti meccanici(piccole parti)= ed elettrici=2E


2010-Ad oggi: Produz= ione macchine/parte:meccanica-elettrica (ritenuta d'acconto) per alcune azi= ende, tra cui, la principale, per la produzione di macchine taglio plasma= =2ECommessa ormai terminata=2E


DISPONIBILITA'= : eventualmente anche immediata=2EDo' la disponibilita' anche ad ap= prendere parte di un lavoro non completamente conosciuto**
=

RICERCA DI LAVORO := Stavo cercando un'azienda seria che assume personale,anche non spec= ifico al mio settore=2E


RETRIBUZIONE<= /b> : Richiesta bassa**


REFERENZE : Buone= =2E


LAVORO : Serieta',precisione,= onesta' e dedizione=2E


CONTATT= I : Se foste interessati : eventuale contatto, chiamare il numero : 334/23=2E07=2E365 <= /u>(Prima delle or= e 15 : se spento o non c'e' linea ,lasciare 1 messaggio/Dopo le 15 : Sempre= )=2E


SE AL CONTRARIO NON FOSTE INTERESSATI,
CORTESEMENTE SE POTETE SEGNALAR= LO / DARE MIO NOMINATIVO AD EVENTUALI DITTE INTERESSATE-DO' MIO CONSENSO= =2E


GRAZIE TANTISSIMO PER LA VOSTRA CORT= ESE ATTENZIONE !


Colgo l'occasione per porgerVi i miei piu' Cordiali S= aluti=2E


Ivan Batzella=2E
<= br>

(N=2EB=2Evogliate scusarmi se questa e-mail dovesse arrivare in province d= ifferenti di MI /ad aziende non interessate/a persone estranee a questa ric= hiesta)


N=2EB=2E : Do' il consens= o al trattamento dei miei dati personali ai sensi dell'articolo 23 del D= =2E lgs=2E 196/03 per le finalit=E0 di selezione del personale=2E
=
----=BOUNDARY_9101747_UKSF_ORTJ_IIAY_MJXE-- From sandeen@sandeen.net Thu Sep 10 12:06:14 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 03AF57F47 for ; Thu, 10 Sep 2015 12:06:14 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 96424AC00A for ; Thu, 10 Sep 2015 10:06:10 -0700 (PDT) X-ASG-Debug-ID: 1441904768-04bdf04db34e6e0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id J2hy7ZSYtWCn3D3F for ; Thu, 10 Sep 2015 10:06:08 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from Liberator.local (unknown [10.0.0.195]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 0CB2F6371E26 for ; Thu, 10 Sep 2015 11:51:11 -0500 (CDT) Subject: Re: [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <20150910092224.GB2613@zion.usersys.redhat.com> From: Eric Sandeen Message-ID: <55F1B4FC.5040207@sandeen.net> Date: Thu, 10 Sep 2015 11:51:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150910092224.GB2613@zion.usersys.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441904768 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22411 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/10/15 4:22 AM, Carlos Maiolino wrote: > On Wed, Sep 09, 2015 at 02:33:58PM -0500, Eric Sandeen wrote: ... >> The last patch fixes up the dir vs. attr text in error messages >> and comments. I do have a question about whether this is ok >> for i8n: >> >> printf(_("This string is %s"), _("awesome")); > > This should be fine for i18n, I had used it a lot when I added i18n support in > gfs2-utils, and _() is the default macro that should embrace every string that > needs to be translated. It will be replaced by gettext("awesome"), and there is > no problem in using it as printf() argument for format specifiers. > > What you should be careful though, is that how these strings will 'look' to the > person translating it, which, in most of cases, they are not going to look at > the code to get a better meaning of the string. So, the sentences to be > translated, should make sense by itself. > > > I particularly, don't like much the idea of split strings as you did in the > example, exactly because how it might look to the translators, both strings > makes the same sentence, but they will show to the translators as completely > different strings, and the translator might not be able to find the proper > grammatical construction. So, I'd do something like: > > printf(funny ? _("This string is awesome") : _("This string is boring")) > > > I know that I might sound picky here, but, this is the best way to avoid weird > and non-sense string translations. No, that makes sense, but it kind of sucks, too - writing the same string twice everywhere, once for attr & once for dir, is a bit bleah. Maybe I can restructure it such that it's more easily translatable, something like using a prefix, i.e. %s: block %d is unreadable for inode %lld -> turns into -> dir: block %d is unreadable for inode %lld - or - attr: block %d is unreadable for inode %lld and then it's not cutting a sentence in half, to interfere with grammar from other languages ... -Eric From sandeen@sandeen.net Thu Sep 10 12:16:11 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id AAAA47F47 for ; Thu, 10 Sep 2015 12:16:11 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 35FDCAC00A for ; Thu, 10 Sep 2015 10:16:10 -0700 (PDT) X-ASG-Debug-ID: 1441905369-04cbb005ec4e130001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id bhHukc1UCECtZXTn for ; Thu, 10 Sep 2015 10:16:09 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from Liberator.local (unknown [10.0.0.195]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 0CB2F6371E26 for ; Thu, 10 Sep 2015 11:51:11 -0500 (CDT) Subject: Re: [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <20150910092224.GB2613@zion.usersys.redhat.com> From: Eric Sandeen Message-ID: <55F1B4FC.5040207@sandeen.net> Date: Thu, 10 Sep 2015 11:51:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150910092224.GB2613@zion.usersys.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441905369 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22411 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/10/15 4:22 AM, Carlos Maiolino wrote: > On Wed, Sep 09, 2015 at 02:33:58PM -0500, Eric Sandeen wrote: ... >> The last patch fixes up the dir vs. attr text in error messages >> and comments. I do have a question about whether this is ok >> for i8n: >> >> printf(_("This string is %s"), _("awesome")); > > This should be fine for i18n, I had used it a lot when I added i18n support in > gfs2-utils, and _() is the default macro that should embrace every string that > needs to be translated. It will be replaced by gettext("awesome"), and there is > no problem in using it as printf() argument for format specifiers. > > What you should be careful though, is that how these strings will 'look' to the > person translating it, which, in most of cases, they are not going to look at > the code to get a better meaning of the string. So, the sentences to be > translated, should make sense by itself. > > > I particularly, don't like much the idea of split strings as you did in the > example, exactly because how it might look to the translators, both strings > makes the same sentence, but they will show to the translators as completely > different strings, and the translator might not be able to find the proper > grammatical construction. So, I'd do something like: > > printf(funny ? _("This string is awesome") : _("This string is boring")) > > > I know that I might sound picky here, but, this is the best way to avoid weird > and non-sense string translations. No, that makes sense, but it kind of sucks, too - writing the same string twice everywhere, once for attr & once for dir, is a bit bleah. Maybe I can restructure it such that it's more easily translatable, something like using a prefix, i.e. %s: block %d is unreadable for inode %lld -> turns into -> dir: block %d is unreadable for inode %lld - or - attr: block %d is unreadable for inode %lld and then it's not cutting a sentence in half, to interfere with grammar from other languages ... -Eric From tapani@tapanitarvainen.fi Thu Sep 10 12:31:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 26BAA7CBF for ; Thu, 10 Sep 2015 12:31:48 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 07042304051 for ; Thu, 10 Sep 2015 10:31:44 -0700 (PDT) X-ASG-Debug-ID: 1441906301-04cb6c355c49920001-NocioJ Received: from hauki.tapanitarvainen.fi (hauki.tapanitarvainen.fi [80.68.90.32]) by cuda.sgi.com with ESMTP id OZ5u1bvC2zBY5hvp (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 10:31:43 -0700 (PDT) X-Barracuda-Envelope-From: tapani@tapanitarvainen.fi X-Barracuda-Apparent-Source-IP: 80.68.90.32 X-Envelope-From: tapani@tapanitarvainen.fi Received: from koti.tapanitarvainen.fi (koti.tapanitarvainen.fi [217.112.255.16]) by hauki.tapanitarvainen.fi (8.14.4/8.14.4/Debian-4) with ESMTP id t8AHVe9P002947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2015 18:31:41 +0100 Received: from tarvainen.info (soopeli.tarvainen.info [192.168.240.53]) by koti.tapanitarvainen.fi (8.14.4/8.14.4/Debian-4.1ubuntu1) with SMTP id t8AHVbKK002024; Thu, 10 Sep 2015 20:31:37 +0300 Received: (nullmailer pid 21503 invoked by uid 10461); Thu, 10 Sep 2015 17:31:38 -0000 Date: Thu, 10 Sep 2015 20:31:38 +0300 From: Tapani Tarvainen To: Brian Foster Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910173138.GB18940@tarvainen.info> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> <20150910125441.GA28374@tehanu.it.jyu.fi> <20150910130106.GB27863@bfoster.bfoster> <20150910130530.GB28374@tehanu.it.jyu.fi> <20150910145154.GC27863@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910145154.GC27863@bfoster.bfoster> User-Agent: Mutt/1.5.23 (2014-03-12) X-Barracuda-Connect: hauki.tapanitarvainen.fi[80.68.90.32] X-Barracuda-Start-Time: 1441906302 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22412 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Thu, Sep 10, 2015 at 10:51:54AM -0400, Brian Foster (bfoster@redhat.com) wrote: > First off, I see ~60MB of corruption output before I even get to the > reported repair failure, so this appears to be an extremely severe > corruption and I wouldn't be surprised if ultimately beyond repair I assumed as much already. > I suspect what's more interesting at this point is what happened to > cause this level of corruption? What kind of event lead to this? Was it > a pure filesystem crash or some kind of hardware/raid failure? Hardware failure. Details are still a bit unclear but apparently raid controller went haywire, offlining the array in the middle of heavy filesystem use. > Also, do you happen to know the geometry (xfs_info) of the original fs? No (and xfs_info doesn't work on the copy made after crash as it can't be mounted). > Repair was showing agno's up in the 20k's and now that I've mounted the > repaired image, xfs_info shows the following: [...] > So that's a 6TB fs with over 24000 allocation groups of size 256MB, as > opposed to the mkfs default of 6 allocation groups of 1TB each. Is that > intentional? Not to my knowledge. Unless I'm mistaken, the filesystem was created while the machine was running Debian Squeeze, using whatever defaults were back then. -- Tapani Tarvainen From tapani@tapanitarvainen.fi Thu Sep 10 12:52:28 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 152447CBF for ; Thu, 10 Sep 2015 12:52:28 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id A5B09AC00C for ; Thu, 10 Sep 2015 10:52:27 -0700 (PDT) X-ASG-Debug-ID: 1441907545-04cbb005ec4f160001-NocioJ Received: from hauki.tapanitarvainen.fi (hauki.tapanitarvainen.fi [80.68.90.32]) by cuda.sgi.com with ESMTP id seTk2jtpZJEFEZcD (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 10:52:25 -0700 (PDT) X-Barracuda-Envelope-From: tapani@tapanitarvainen.fi X-Barracuda-Apparent-Source-IP: 80.68.90.32 X-Envelope-From: tapani@tapanitarvainen.fi Received: from koti.tapanitarvainen.fi (koti.tapanitarvainen.fi [217.112.255.16]) by hauki.tapanitarvainen.fi (8.14.4/8.14.4/Debian-4) with ESMTP id t8AHqNXi003160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2015 18:52:23 +0100 Received: from tarvainen.info (soopeli.tarvainen.info [192.168.240.53]) by koti.tapanitarvainen.fi (8.14.4/8.14.4/Debian-4.1ubuntu1) with SMTP id t8AHqJs0005750; Thu, 10 Sep 2015 20:52:20 +0300 Received: (nullmailer pid 23102 invoked by uid 10461); Thu, 10 Sep 2015 17:52:20 -0000 Date: Thu, 10 Sep 2015 20:52:20 +0300 From: Tapani Tarvainen To: Brian Foster Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910175220.GD18940@tarvainen.info> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> <20150910125441.GA28374@tehanu.it.jyu.fi> <20150910130106.GB27863@bfoster.bfoster> <20150910130530.GB28374@tehanu.it.jyu.fi> <20150910145154.GC27863@bfoster.bfoster> <20150910150525.GD27863@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910150525.GD27863@bfoster.bfoster> User-Agent: Mutt/1.5.23 (2014-03-12) X-Barracuda-Connect: hauki.tapanitarvainen.fi[80.68.90.32] X-Barracuda-Start-Time: 1441907545 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22414 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Thu, Sep 10, 2015 at 11:05:25AM -0400, Brian Foster (bfoster@redhat.com) wrote: > FWIW, the follow up repair did come up clean so it appears (so far) to > have put the fs back together from a metadata standpoint. Indeed, now I can mount it. Not that I expect to find much useful there. Also, it turns out I have another similar case: another filesystem (in the same RAID set) failed also, even though it'd initially mounted without problems. Now it shows the same symptoms, neither mount nor repair works (have't tried repair -L yet). -- Tapani Tarvainen From bfoster@redhat.com Thu Sep 10 12:56:01 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 652B27CBF for ; Thu, 10 Sep 2015 12:56:01 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 421B7304039 for ; Thu, 10 Sep 2015 10:56:01 -0700 (PDT) X-ASG-Debug-ID: 1441907759-04cbb005eb4f380001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id MuWnHABaaAscbwF8 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 10:56:00 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id B628E2B785E; Thu, 10 Sep 2015 17:55:59 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8AHtxCo008993; Thu, 10 Sep 2015 13:55:59 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 151081236D9; Thu, 10 Sep 2015 13:55:58 -0400 (EDT) Date: Thu, 10 Sep 2015 13:55:58 -0400 From: Brian Foster To: Tapani Tarvainen Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910175557.GE27863@bfoster.bfoster> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910091834.GC24937@tehanu.it.jyu.fi> <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> <20150910125441.GA28374@tehanu.it.jyu.fi> <20150910130106.GB27863@bfoster.bfoster> <20150910130530.GB28374@tehanu.it.jyu.fi> <20150910145154.GC27863@bfoster.bfoster> <20150910173138.GB18940@tarvainen.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910173138.GB18940@tarvainen.info> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1441907760 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 10, 2015 at 08:31:38PM +0300, Tapani Tarvainen wrote: > On Thu, Sep 10, 2015 at 10:51:54AM -0400, Brian Foster (bfoster@redhat.com) wrote: > > > First off, I see ~60MB of corruption output before I even get to the > > reported repair failure, so this appears to be an extremely severe > > corruption and I wouldn't be surprised if ultimately beyond repair > > I assumed as much already. > > > I suspect what's more interesting at this point is what happened to > > cause this level of corruption? What kind of event lead to this? Was it > > a pure filesystem crash or some kind of hardware/raid failure? > > Hardware failure. Details are still a bit unclear but apparently raid > controller went haywire, offlining the array in the middle of > heavy filesystem use. > > > Also, do you happen to know the geometry (xfs_info) of the original fs? > > No (and xfs_info doesn't work on the copy made after crash as it > can't be mounted). > > > Repair was showing agno's up in the 20k's and now that I've mounted the > > repaired image, xfs_info shows the following: > [...] > > So that's a 6TB fs with over 24000 allocation groups of size 256MB, as > > opposed to the mkfs default of 6 allocation groups of 1TB each. Is that > > intentional? > > Not to my knowledge. Unless I'm mistaken, the filesystem was created > while the machine was running Debian Squeeze, using whatever defaults > were back then. > Strange... was the filesystem created small and then grown to a much larger size via xfs_growfs? I just formatted a 1GB fs that started with 4 allocation groups and ends with 24576 (same as above) AGs when grown to 6TB. Brian > -- > Tapani Tarvainen From tapani.j.tarvainen@jyu.fi Thu Sep 10 13:01:36 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 4B0717CBF for ; Thu, 10 Sep 2015 13:01:36 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 39333304039 for ; Thu, 10 Sep 2015 11:01:33 -0700 (PDT) X-ASG-Debug-ID: 1441908089-04cb6c355d4a780001-NocioJ Received: from hauki.tapanitarvainen.fi (hauki.tapanitarvainen.fi [80.68.90.32]) by cuda.sgi.com with ESMTP id GYpSksxuJ27ijV2W (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 11:01:30 -0700 (PDT) X-Barracuda-Envelope-From: tapani.j.tarvainen@jyu.fi X-Barracuda-Apparent-Source-IP: 80.68.90.32 X-Envelope-From: tapani.j.tarvainen@jyu.fi Received: from koti.tapanitarvainen.fi (koti.tapanitarvainen.fi [217.112.255.16]) by hauki.tapanitarvainen.fi (8.14.4/8.14.4/Debian-4) with ESMTP id t8AI1Sfn003223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2015 19:01:29 +0100 Received: from tarvainen.info (soopeli.tarvainen.info [192.168.240.53]) by koti.tapanitarvainen.fi (8.14.4/8.14.4/Debian-4.1ubuntu1) with SMTP id t8AI1QeQ007265; Thu, 10 Sep 2015 21:01:26 +0300 Received: (nullmailer pid 23363 invoked by uid 10461); Thu, 10 Sep 2015 18:01:28 -0000 Date: Thu, 10 Sep 2015 21:01:28 +0300 From: Tapani Tarvainen To: Brian Foster Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910180128.GE18940@tarvainen.info> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> <20150910125441.GA28374@tehanu.it.jyu.fi> <20150910130106.GB27863@bfoster.bfoster> <20150910130530.GB28374@tehanu.it.jyu.fi> <20150910145154.GC27863@bfoster.bfoster> <20150910150525.GD27863@bfoster.bfoster> <20150910175220.GD18940@tarvainen.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910175220.GD18940@tarvainen.info> User-Agent: Mutt/1.5.23 (2014-03-12) X-Barracuda-Connect: hauki.tapanitarvainen.fi[80.68.90.32] X-Barracuda-Start-Time: 1441908090 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22413 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Thu, Sep 10, 2015 at 08:52:20PM +0300, Tapani Tarvainen (tapani@tapanitarvainen.fi) wrote: > Also, it turns out I have another similar case: another filesystem > (in the same RAID set) failed also, even though it'd initially > mounted without problems. Now it shows the same symptoms, > neither mount nor repair works (have't tried repair -L yet). Apparently it only failed after someone tried to write on it. Potentially interesting stuff from dmesg: [31604.130052] XFS (dm-4): xfs_da_do_buf: bno 8388608 dir: inode 964 [31604.130080] XFS (dm-4): [00] br_startoff 8388608 br_startblock -2 br_blockcount 1 br_state 0 [31604.130126] XFS (dm-4): Internal error xfs_da_do_buf(1) at line 2011 of file /build/linux-4wkEzn/ linux-3.2.68/fs/xfs/xfs_da_btree.c. Caller 0xffffffffa0371b67 [31604.130127] [31604.130213] Pid: 18082, comm: du Not tainted 3.2.0-4-amd64 #1 Debian 3.2.68-1+deb7u1 [...] -- Tapani Tarvainen From tapani.j.tarvainen@jyu.fi Thu Sep 10 13:03:46 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id DD1127CBF for ; Thu, 10 Sep 2015 13:03:46 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id BBED78F8050 for ; Thu, 10 Sep 2015 11:03:43 -0700 (PDT) X-ASG-Debug-ID: 1441908221-04cbb005ea4f7c0001-NocioJ Received: from hauki.tapanitarvainen.fi (hauki.tapanitarvainen.fi [80.68.90.32]) by cuda.sgi.com with ESMTP id bNoGQ6BDR9ZwFNUB (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 11:03:41 -0700 (PDT) X-Barracuda-Envelope-From: tapani.j.tarvainen@jyu.fi X-Barracuda-Apparent-Source-IP: 80.68.90.32 X-Envelope-From: tapani.j.tarvainen@jyu.fi Received: from koti.tapanitarvainen.fi (koti.tapanitarvainen.fi [217.112.255.16]) by hauki.tapanitarvainen.fi (8.14.4/8.14.4/Debian-4) with ESMTP id t8AI3eY3003238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2015 19:03:40 +0100 Received: from tarvainen.info (soopeli.tarvainen.info [192.168.240.53]) by koti.tapanitarvainen.fi (8.14.4/8.14.4/Debian-4.1ubuntu1) with SMTP id t8AI3b0B007664; Thu, 10 Sep 2015 21:03:37 +0300 Received: (nullmailer pid 23478 invoked by uid 10461); Thu, 10 Sep 2015 18:03:39 -0000 Date: Thu, 10 Sep 2015 21:03:39 +0300 From: Tapani Tarvainen To: Brian Foster Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910180339.GB18739@tarvainen.info> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> <20150910125441.GA28374@tehanu.it.jyu.fi> <20150910130106.GB27863@bfoster.bfoster> <20150910130530.GB28374@tehanu.it.jyu.fi> <20150910145154.GC27863@bfoster.bfoster> <20150910173138.GB18940@tarvainen.info> <20150910175557.GE27863@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910175557.GE27863@bfoster.bfoster> User-Agent: Mutt/1.5.23 (2014-03-12) X-Barracuda-Connect: hauki.tapanitarvainen.fi[80.68.90.32] X-Barracuda-Start-Time: 1441908221 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22414 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Thu, Sep 10, 2015 at 01:55:58PM -0400, Brian Foster (bfoster@redhat.com) wrote: > > > So that's a 6TB fs with over 24000 allocation groups of size 256MB, as > > > opposed to the mkfs default of 6 allocation groups of 1TB each. Is that > > > intentional? > > > > Not to my knowledge. Unless I'm mistaken, the filesystem was created > > while the machine was running Debian Squeeze, using whatever defaults > > were back then. > Strange... was the filesystem created small and then grown to a much > larger size via xfs_growfs? Almost certainly yes, although how small it initially was I'm not sure. -- Tapani Tarvainen From bfoster@redhat.com Thu Sep 10 13:34:02 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id C60287CBF for ; Thu, 10 Sep 2015 13:34:02 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id A3B4C8F806F for ; Thu, 10 Sep 2015 11:34:02 -0700 (PDT) X-ASG-Debug-ID: 1441910041-04cb6c355a4b500001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id qORfNlOQTgGwwa6j (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Sep 2015 11:34:01 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id E7DFDA9A; Thu, 10 Sep 2015 18:34:00 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8AIY01Y031966; Thu, 10 Sep 2015 14:34:00 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 4EE401236D9; Thu, 10 Sep 2015 14:33:59 -0400 (EDT) Date: Thu, 10 Sep 2015 14:33:59 -0400 From: Brian Foster To: Tapani Tarvainen Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150910183358.GF27863@bfoster.bfoster> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> <20150910125441.GA28374@tehanu.it.jyu.fi> <20150910130106.GB27863@bfoster.bfoster> <20150910130530.GB28374@tehanu.it.jyu.fi> <20150910145154.GC27863@bfoster.bfoster> <20150910173138.GB18940@tarvainen.info> <20150910175557.GE27863@bfoster.bfoster> <20150910180339.GB18739@tarvainen.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910180339.GB18739@tarvainen.info> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1441910041 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 10, 2015 at 09:03:39PM +0300, Tapani Tarvainen wrote: > On Thu, Sep 10, 2015 at 01:55:58PM -0400, Brian Foster (bfoster@redhat.com) wrote: > > > > > So that's a 6TB fs with over 24000 allocation groups of size 256MB, as > > > > opposed to the mkfs default of 6 allocation groups of 1TB each. Is that > > > > intentional? > > > > > > Not to my knowledge. Unless I'm mistaken, the filesystem was created > > > while the machine was running Debian Squeeze, using whatever defaults > > > were back then. > > > Strange... was the filesystem created small and then grown to a much > > larger size via xfs_growfs? > > Almost certainly yes, although how small it initially was I'm not > sure. > That probably explains that then. While growfs is obviously supported, it's not usually a great idea to grow from something really small to really large like this precisely because you end up with this kind of weird geometry. mkfs tries to format the fs to an ideal default geometry based on the current size of the device, but the allocation group size cannot be modified once the filesystem is created. Therefore, growfs can only add more AGs of the original size. As a result, you end up with a 6TB filesystem with >24k allocation groups, whereas mkfs will format a 6TB device with 6 allocation groups by default (though I think specifying a stripe unit can tweak this). My understanding is that this could be increased sanely on large cpu count systems and such, but we're probably talking about going to something on the order of 32 or 64 allocation groups as opposed to thousands. I'd expect such a large filesystem with such small allocation groups to probably introduce overhead in terms of metadata usage (24k agi's, agf's, 2x free space btrees and 1x inode btree per AG), spending more time in AG selection algorithms for allocations and whatnot, increased fragmentation due to capping the maximum contiguous extent size, creating more work for userspace tools such as repair, etc., and probably to have other weird or non-obvious side effects that I'm not familiar with. Brian > -- > Tapani Tarvainen From sandeen@sandeen.net Thu Sep 10 19:12:49 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 33FB57CBF for ; Thu, 10 Sep 2015 19:12:49 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 23A1C304032 for ; Thu, 10 Sep 2015 17:12:45 -0700 (PDT) X-ASG-Debug-ID: 1441930360-04cbb005eb59040001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id dVPGG5Ap815Griqk for ; Thu, 10 Sep 2015 17:12:41 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 657E165EBB85 for ; Thu, 10 Sep 2015 19:12:40 -0500 (CDT) Subject: Re: "This is a bug." To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910134828.0bdfcc4c@harpe.intellique.com> <20150910115548.GD26847@tehanu.it.jyu.fi> <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> <20150910125441.GA28374@tehanu.it.jyu.fi> <20150910130106.GB27863@bfoster.bfoster> <20150910130530.GB28374@tehanu.it.jyu.fi> <20150910145154.GC27863@bfoster.bfoster> <20150910173138.GB18940@tarvainen.info> <20150910175557.GE27863@bfoster.bfoster> <20150910180339.GB18739@tarvainen.info> From: Eric Sandeen Message-ID: <55F21C77.6030009@sandeen.net> Date: Thu, 10 Sep 2015 19:12:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150910180339.GB18739@tarvainen.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1441930361 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22424 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/10/15 1:03 PM, Tapani Tarvainen wrote: > On Thu, Sep 10, 2015 at 01:55:58PM -0400, Brian Foster (bfoster@redhat.com) wrote: > >>>> So that's a 6TB fs with over 24000 allocation groups of size 256MB, as >>>> opposed to the mkfs default of 6 allocation groups of 1TB each. Is that >>>> intentional? >>> >>> Not to my knowledge. Unless I'm mistaken, the filesystem was created >>> while the machine was running Debian Squeeze, using whatever defaults >>> were back then. > >> Strange... was the filesystem created small and then grown to a much >> larger size via xfs_growfs? > > Almost certainly yes, although how small it initially was I'm not > sure. Oof; with a default of 4 AGs that means that this filesystem was likely grown from 1G to 6T. Like Brian says, that is definitely not recommended. ;) -Eric From ftpmaster@ftp-master.debian.org Thu Sep 10 21:04:35 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 4A00D7CBF for ; Thu, 10 Sep 2015 21:04:35 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 2A2308F8059 for ; Thu, 10 Sep 2015 19:04:32 -0700 (PDT) X-ASG-Debug-ID: 1441937068-04bdf04db55c070001-NocioJ Received: from muffat.debian.org (muffat.debian.org [206.12.19.146]) by cuda.sgi.com with ESMTP id ZcqsMiCDeHp1jb54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 10 Sep 2015 19:04:29 -0700 (PDT) X-Barracuda-Envelope-From: ftpmaster@ftp-master.debian.org X-Barracuda-Apparent-Source-IP: 206.12.19.146 Received: from franck.debian.org ([138.16.160.12]) from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=franck.debian.org,EMAIL=hostmaster@franck.debian.org (verified) by muffat.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZaDhU-0007Wo-18 for xfs@oss.sgi.com; Fri, 11 Sep 2015 02:04:28 +0000 Received: from dak-unpriv by franck.debian.org with local (Exim 4.84) (envelope-from ) id 1ZaDhT-0000Ai-5e for xfs@oss.sgi.com; Fri, 11 Sep 2015 02:04:27 +0000 To: xfs@oss.sgi.com From: Debian FTP Masters Subject: Processing of xfsprogs_4.2.0_amd64.changes Date: Fri, 11 Sep 2015 02:04:27 +0000 X-ASG-Orig-Subj: Processing of xfsprogs_4.2.0_amd64.changes X-Debian: DAK X-DAK: DAK Precedence: bulk Auto-Submitted: auto-generated X-Debian-Package: xfsprogs Message-Id: X-Barracuda-Connect: muffat.debian.org[206.12.19.146] X-Barracuda-Start-Time: 1441937069 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22427 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- xfsprogs_4.2.0_amd64.changes uploaded successfully to localhost along with the files: xfsprogs_4.2.0.dsc xfsprogs_4.2.0.tar.gz xfslibs-dev_4.2.0_amd64.deb xfsprogs-udeb_4.2.0_amd64.udeb xfsprogs_4.2.0_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) From envelope@ftp-master.debian.org Thu Sep 10 22:22:54 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 506767CBF for ; Thu, 10 Sep 2015 22:22:54 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3C4B68F804B for ; Thu, 10 Sep 2015 20:22:54 -0700 (PDT) X-ASG-Debug-ID: 1441941770-04cb6c355d57130001-NocioJ Received: from mailly.debian.org (mailly.debian.org [82.195.75.114]) by cuda.sgi.com with ESMTP id 4muIma3igIfPBpw1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 10 Sep 2015 20:22:51 -0700 (PDT) X-Barracuda-Envelope-From: envelope@ftp-master.debian.org X-Barracuda-Apparent-Source-IP: 82.195.75.114 Received: from franck.debian.org ([138.16.160.12]) from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=franck.debian.org,EMAIL=hostmaster@franck.debian.org (verified) by mailly.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZaEvI-0007YG-Js; Fri, 11 Sep 2015 03:22:48 +0000 Received: from dak by franck.debian.org with local (Exim 4.84) (envelope-from ) id 1ZaEvH-0003k6-Bw; Fri, 11 Sep 2015 03:22:47 +0000 From: Debian FTP Masters To: XFS Development Team , Nathan Scott X-DAK: dak process-upload X-Debian: DAK X-Debian-Package: xfsprogs Precedence: bulk Auto-Submitted: auto-generated MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: xfsprogs_4.2.0_amd64.changes ACCEPTED into unstable Message-Id: X-ASG-Orig-Subj: xfsprogs_4.2.0_amd64.changes ACCEPTED into unstable Date: Fri, 11 Sep 2015 03:22:47 +0000 X-Barracuda-Connect: mailly.debian.org[82.195.75.114] X-Barracuda-Start-Time: 1441941771 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22429 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Format: 1.8 Date: Mon, 07 Sep 2015 10:13:54 +1000 Source: xfsprogs Binary: xfsprogs xfslibs-dev xfsprogs-udeb Architecture: source amd64 Version: 4.2.0 Distribution: unstable Urgency: low Maintainer: XFS Development Team Changed-By: Nathan Scott Description: xfslibs-dev - XFS filesystem-specific static libraries and headers xfsprogs - Utilities for managing the XFS filesystem xfsprogs-udeb - A stripped-down version of xfsprogs, for debian-installer (udeb) Changes: xfsprogs (4.2.0) unstable; urgency=low . * New upstream release Checksums-Sha1: baddf27d5f7da2c2a2f9c85172a05504c7589a5a 1763 xfsprogs_4.2.0.dsc 361be3e814fbafd3fb6e988290fdf7f09b6e7012 1496586 xfsprogs_4.2.0.tar.gz 7da227ad31751a6d7ee364e3a85a0b91257c5660 54530 xfslibs-dev_4.2.0_amd64.deb 2491f60f16f6c5d00cead15abd637136db8fd3e6 132972 xfsprogs-udeb_4.2.0_amd64.udeb fe5e28890f590fdc5ecf0483219e76a1018ed743 715556 xfsprogs_4.2.0_amd64.deb Checksums-Sha256: a5fe44ced2465a6da0f8785e8a414e2c9f449ea0f176fa685a0d69b7aa44e241 1763 xfsprogs_4.2.0.dsc f31f28e0453f36b6452f639aa5578c62b338639b21b0acb5c340ab2a459f0df3 1496586 xfsprogs_4.2.0.tar.gz 692a15cb870b1a493f286a007254aa27a20bacb05307abf20e63439ea72f8a18 54530 xfslibs-dev_4.2.0_amd64.deb a007c1017b67b754e5eae486c9ac27d39d3822069851480605e2ae1ab6508c5b 132972 xfsprogs-udeb_4.2.0_amd64.udeb e6e80c88b1d047ecf7e4d68f86f253ebdfff341853ba04ee37e6648bbf50ee24 715556 xfsprogs_4.2.0_amd64.deb Files: 52907dc8f34ffe83a2f6103c9962e6e2 1763 admin optional xfsprogs_4.2.0.dsc 77edc79aebf97745810a2da085984744 1496586 admin optional xfsprogs_4.2.0.tar.gz 30538527923e2cef6d868cd806f64c89 54530 libdevel extra xfslibs-dev_4.2.0_amd64.deb 3f31090cf01724438b8fd93cb52cd7bf 132972 debian-installer optional xfsprogs-udeb_4.2.0_amd64.udeb cc43e385105fc2075686a69d4f65a8ff 715556 admin optional xfsprogs_4.2.0_amd64.deb Package-Type: udeb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV8jTvAAoJEP4IQu423YwMC0sP/i2FdRAODck8h4FfqZ11D+u8 6bRVi+r9HqS+Edlrc5aKu+WQFXyzrkQYo8sF1HtHvtE2/gU3FMQ0MSWG2xSvCd+Y M9+2MHAFR8+nj98te+j4l5q2srltQL0wL0zb8h7XfLqBoNttYXGKVftgC2tiMp5k rQEUCL5R68acIDcvbl52zrmY2UdmeVvKvVvGsJ8kmSFjeY9N33cqGCrytY+o+GWJ FQ5NfJ/g2dwiv4ZnEUaGVh1W89LG7X3uzmRKjXx7QLBck0yxn4eCi5JuacerNQqX 23aDcLEzqEvnkAwqAqUWOayVjypz+Jz4dV+seSmzzRtuLTwxq/wqGHRKSbcg0rP6 ROmf61F2gKE1nF0ougyn7xTfyBckIErwUh0SgXwKfU6lXFLLF8o0l4GcKSfdjej2 eV3Yht6Eag4ruFi+IrzPwn5qtZcBCiUS/G3z9cgvIiSR+7zHPdG0tk+dtS1SJ1Xy UT7Jln4wO1crSGWzzlakTIh0a/9dZ954r6+df1gpstiXV3u0qc5YzFkzKYdxQIDa LEItyOVDd6YQQvMZ5HvZRI1PhBX4noSpkk8Bg0AEWcmi2IkKlAznf+kDdlKRf60E z9cHe0I5EV4pDGroFALT98pJZ3Ky4Usp+uDmNRIZiydINFvb9rZqMyUcgu1PNn8l pANy/5CEz+2OtoSBzIGh =X937 -----END PGP SIGNATURE----- Thank you for your contribution to Debian. From tapani.j.tarvainen@jyu.fi Fri Sep 11 01:19:57 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id CE59D7F37 for ; Fri, 11 Sep 2015 01:19:57 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id BEDFE8F8049 for ; Thu, 10 Sep 2015 23:19:54 -0700 (PDT) X-ASG-Debug-ID: 1441952391-04cbb005ec609f0001-NocioJ Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by cuda.sgi.com with ESMTP id 8Z5KN3k2j2rYFrDE (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Sep 2015 23:19:52 -0700 (PDT) X-Barracuda-Envelope-From: tapani.j.tarvainen@jyu.fi X-Barracuda-Apparent-Source-IP: 130.234.4.43 Received: from localhost (localhost.localdomain [127.0.0.1]) by posti6.jyu.fi (8.13.8/8.13.8) with ESMTP id t8B6Jn2A022513; Fri, 11 Sep 2015 09:19:49 +0300 X-Virus-Scanned: amavisd-new at cc.jyu.fi Received: from posti6.jyu.fi ([127.0.0.1]) by localhost (posti6.jyu.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nSAIOndcwZH; Fri, 11 Sep 2015 09:19:49 +0300 (EEST) Received: from tehanu.it.jyu.fi (tehanu.it.jyu.fi [130.234.160.128]) by posti6.jyu.fi (8.13.8/8.13.8) with ESMTP id t8B6JlR8022504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Sep 2015 09:19:48 +0300 Received: (from tt@localhost) by tehanu.it.jyu.fi (8.14.4/8.14.4/Submit) id t8B6JlPp003708; Fri, 11 Sep 2015 09:19:47 +0300 X-Authentication-Warning: tehanu.it.jyu.fi: tt set sender to tapani.j.tarvainen@jyu.fi using -f Date: Fri, 11 Sep 2015 09:19:47 +0300 From: Tapani Tarvainen To: Brian Foster Cc: xfs@oss.sgi.com Subject: Re: "This is a bug." Message-ID: <20150911061947.GA3398@tehanu.it.jyu.fi> X-ASG-Orig-Subj: Re: "This is a bug." References: <20150910123030.GG26847@tehanu.it.jyu.fi> <20150910123603.GA27863@bfoster.bfoster> <20150910125441.GA28374@tehanu.it.jyu.fi> <20150910130106.GB27863@bfoster.bfoster> <20150910130530.GB28374@tehanu.it.jyu.fi> <20150910145154.GC27863@bfoster.bfoster> <20150910173138.GB18940@tarvainen.info> <20150910175557.GE27863@bfoster.bfoster> <20150910180339.GB18739@tarvainen.info> <20150910183358.GF27863@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910183358.GF27863@bfoster.bfoster> User-Agent: Mutt/1.5.20 (2009-12-10) X-Barracuda-Connect: posti6.jyu.fi[130.234.4.43] X-Barracuda-Start-Time: 1441952392 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22432 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 10 Sep 14:33, Brian Foster (bfoster@redhat.com) wrote: > > >... was the filesystem created small and then grown to a much > > > larger size via xfs_growfs? > > > > Almost certainly yes, although how small it initially was I'm not > > sure. It actually been grown several times over the years - the system is rather old. Indeed, all its disks have been replaced with bigger ones without reinstallation, so the filesystem could not have been initially created as big as it is now. > That probably explains that then. While growfs is obviously supported, > it's not usually a great idea to grow from something really small to > really large like this That's good to know - but sometimes you just can't plan ahead far enough. > I'd expect such a large filesystem with such small allocation groups to > probably introduce overhead in terms of metadata usage (24k agi's, > agf's, 2x free space btrees and 1x inode btree per AG), spending more > time in AG selection algorithms for allocations and whatnot, increased > fragmentation due to capping the maximum contiguous extent size, > creating more work for userspace tools such as repair, etc., and > probably to have other weird or non-obvious side effects that I'm not > familiar with. So it's likely to also make it more fragile and harder to repair in case of a disaster like this. So, my take from this is that (1) The bug was real but it was just in the old version of xfs_repair in Debian Wheezy, and even when the machine is updated to Jessie (due soon) it's better to install latest (4.20) xfsprogs from sources rather Jessie's packaged 3.20; and (2) When a filesystem grows a lot it is better to recreate it (at least every now and then if the growth is incremental) rather than keep growing it forever. If there's anything you'd like to add, and especially if there is something you'd still like to debug where I could help, please let me know. Thank you for your help, -- Tapani Tarvainen From cmaiolino@redhat.com Fri Sep 11 03:20:29 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 267877F37 for ; Fri, 11 Sep 2015 03:20:29 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 17261304032 for ; Fri, 11 Sep 2015 01:20:26 -0700 (PDT) X-ASG-Debug-ID: 1441959624-04cbb005ec64310001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id kT2i9zkjw5XAmXct (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 01:20:24 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 597BE8E6E1; Fri, 11 Sep 2015 08:20:24 +0000 (UTC) Received: from zion.usersys.redhat.com (vpn-224-163.phx2.redhat.com [10.3.224.163]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8B8KKiT002111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Sep 2015 04:20:23 -0400 Date: Fri, 11 Sep 2015 10:20:20 +0200 From: Carlos Maiolino To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c Message-ID: <20150911082020.GA2523@zion.usersys.redhat.com> X-ASG-Orig-Subj: Re: [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c Mail-Followup-To: Eric Sandeen , xfs@oss.sgi.com References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <20150910092224.GB2613@zion.usersys.redhat.com> <55F1B4FC.5040207@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F1B4FC.5040207@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1441959624 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 10, 2015 at 11:51:08AM -0500, Eric Sandeen wrote: > On 9/10/15 4:22 AM, Carlos Maiolino wrote: > > On Wed, Sep 09, 2015 at 02:33:58PM -0500, Eric Sandeen wrote: > > ... > > >> The last patch fixes up the dir vs. attr text in error messages > >> and comments. I do have a question about whether this is ok > >> for i8n: > >> > >> printf(_("This string is %s"), _("awesome")); > > > > This should be fine for i18n, I had used it a lot when I added i18n support in > > gfs2-utils, and _() is the default macro that should embrace every string that > > needs to be translated. It will be replaced by gettext("awesome"), and there is > > no problem in using it as printf() argument for format specifiers. > > > > What you should be careful though, is that how these strings will 'look' to the > > person translating it, which, in most of cases, they are not going to look at > > the code to get a better meaning of the string. So, the sentences to be > > translated, should make sense by itself. > > > > > > I particularly, don't like much the idea of split strings as you did in the > > example, exactly because how it might look to the translators, both strings > > makes the same sentence, but they will show to the translators as completely > > different strings, and the translator might not be able to find the proper > > grammatical construction. So, I'd do something like: > > > > printf(funny ? _("This string is awesome") : _("This string is boring")) > > > > > > I know that I might sound picky here, but, this is the best way to avoid weird > > and non-sense string translations. > > No, that makes sense, but it kind of sucks, too - writing the same string > twice everywhere, once for attr & once for dir, is a bit bleah. > > Maybe I can restructure it such that it's more easily translatable, > something like using a prefix, i.e. > > %s: block %d is unreadable for inode %lld > > -> turns into -> > > dir: block %d is unreadable for inode %lld > - or - > attr: block %d is unreadable for inode %lld > > and then it's not cutting a sentence in half, to interfere with grammar > from other languages ... > Yep, that makes sense. Or, you can play with variables, but, that would make the code only a huge spaghetti of strings and probably nobody would want to see things like that. > -Eric > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- Carlos From rjohnston@sgi.com Fri Sep 11 12:01:35 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id D89097F37 for ; Fri, 11 Sep 2015 12:01:35 -0500 (CDT) Received: from xmail.sgi.com (pv-excas3-dc21.corp.sgi.com [137.38.106.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 48200AC007; Fri, 11 Sep 2015 10:01:32 -0700 (PDT) Received: from [128.162.233.55] (128.162.233.55) by xmail.sgi.com (137.38.106.6) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 11 Sep 2015 12:01:31 -0500 Subject: Re: [PATCH V3] xfsrestore: fix fs uuid order check for incremental restores To: Brian Foster References: <20150826213133.GB3902@dastard> <55D5FB95.1280108@sgi.com> <20150902132112.GB23587@bfoster.bfoster> <20150903234346.2473A600006AF@gulag1.americas.sgi.com> <20150908124726.GA5305@bfoster.bfoster> CC: From: Rich Johnston Message-ID: <55F308EE.3010109@sgi.com> Date: Fri, 11 Sep 2015 12:01:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150908124726.GA5305@bfoster.bfoster> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [128.162.233.55] On 09/08/2015 07:47 AM, Brian Foster wrote: > On Thu, Sep 03, 2015 at 06:43:46PM -0500, Rich Johnston wrote: >> Restoring an incremental level 1 dump will fail with the following error >> if the fs uuid of the most recent level 0 dump in the inventory does not >> match level 1 dump we are restoring. ... >> Index: b/inventory/inv_api.c >> =================================================================== >> --- a/inventory/inv_api.c >> +++ b/inventory/inv_api.c >> @@ -596,69 +596,78 @@ inv_free_session( ... >> >> - return invmgr_query_all_sessions((void *) &level, /* in */ >> - (void **) ses, /* out */ >> - (search_callback_t) lastsess_level_lessthan); >> + return invmgr_query_all_sessions(fsidp /* fs uuid */ > > This doesn't compile because of a missing comma after fsidp above. > My mistake, happened while cleaning up whitespace. ... >> Index: b/inventory/inv_mgr.c >> =================================================================== >> --- a/inventory/inv_mgr.c >> +++ b/inventory/inv_mgr.c ... >> @@ -178,26 +180,27 @@ invmgr_query_all_sessions ( >> "INV: Open failed on %s\n"), >> fname >> ); >> - return BOOL_FALSE; >> + continue; >> } >> - result = search_invt( invfd, inarg, &objectfound, func ); >> + result = search_invt(fsidp, invfd, inarg, &objectfound, func); >> close(invfd); >> >> /* if error return BOOL_FALSE */ >> if (result < 0) { >> - return BOOL_FALSE; >> + return ret; > > Should this always return false? It's now possible to return true if an > error occurs after we've found one object. *nod* Thanks I missed that one. I'll have a V4 out shortly. --Rich > > The rest seems Ok to me. > > Brian > From rjohnston@sgi.com Fri Sep 11 12:14:54 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 7F55D7F37 for ; Fri, 11 Sep 2015 12:14:54 -0500 (CDT) Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay2.corp.sgi.com (Postfix) with ESMTP id 2E998304059; Fri, 11 Sep 2015 10:14:51 -0700 (PDT) Received: from gulag1.americas.sgi.com (gulag1.americas.sgi.com [128.162.236.41]) by estes.americas.sgi.com (Postfix) with ESMTP id DDDDE7002F74; Fri, 11 Sep 2015 12:14:50 -0500 (CDT) Received: by gulag1.americas.sgi.com (Postfix, from userid 48222) id C067C6073EA67; Fri, 11 Sep 2015 12:14:50 -0500 (CDT) Subject: [PATCH V4] xfsrestore: fix fs uuid order check for incremental restores From: Rich Johnston To: bfoster@redhat.com Cc: xfs@oss.sgi.com In-Reply-To: <20150908124726.GA5305@bfoster.bfoster> References: <20150826213133.GB3902@dastard> <55D5FB95.1280108@sgi.com> <20150902132112.GB23587@bfoster.bfoster> <20150903234346.2473A600006AF@gulag1.americas.sgi.com> <20150908124726.GA5305@bfoster.bfoster> Content-Disposition: inline; filename=xfsrestore-fix-fs-uuid-order-check-for-incremental-restores-v4.patch Message-Id: <20150911171450.C067C6073EA67@gulag1.americas.sgi.com> Date: Fri, 11 Sep 2015 12:14:50 -0500 (CDT) Restoring an incremental level 1 dump will fail with the following error if the fs uuid of the most recent level 0 dump in the inventory does not match level 1 dump we are restoring. xfsrestore: ERROR: selected dump not based on previously applied dump This can happen when you have multiple filesystems and you are restoring a level 1 or greater dump of filesystem FS1 but the most recent level 0 dump in the inventory was filesystem FS2 The fix is to ensure the fs uuid of the inventory entry and the dump to be restored match. Signed-off-by: Rich Johnston --- Changelog V2 wrong file sent V3 Address review comments from Brian: fix invmgr_query_all_sessions() returning true if these error cases persist throughout the loop make if check more readable and less overloaded in search_inv() and return an error if GET_REC_NOLOCK() fails use NULL instead of (uuid_t *)0 in Inv_validate_cmdline() remove any spaces around braces of code that was changed V4 fix compile error introduced when I removed any spaces around braces of code that was changed and cleaning up whitespace. we should be returning BOOL_FALSE on any errors. I missed one. dump/content.c | 16 +++--- inventory/inv_api.c | 130 +++++++++++++++++++++++++++++--------------------- inventory/inv_mgr.c | 53 +++++++++++++------- inventory/inv_priv.h | 7 +- inventory/inventory.h | 21 +++++--- restore/content.c | 23 +++++--- 6 files changed, 151 insertions(+), 99 deletions(-) Index: b/dump/content.c =================================================================== --- a/dump/content.c +++ b/dump/content.c @@ -872,7 +872,7 @@ content_init( intgen_t argc, sameinterruptedpr = BOOL_FALSE; interruptedpr = BOOL_FALSE; - ok = inv_get_session_byuuid( &baseuuid, &sessp ); + ok = inv_get_session_byuuid(&fsid, &baseuuid, &sessp); if ( ! ok ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "could not find specified base dump (%s) " @@ -983,9 +983,10 @@ content_init( intgen_t argc, "online inventory not available\n") ); return BOOL_FALSE; } - ok = inv_lastsession_level_lessthan( inv_idbt, - ( u_char_t )sc_level, - &sessp ); + ok = inv_lastsession_level_lessthan(&fsid, + inv_idbt, + (u_char_t)sc_level, + &sessp); if ( ! ok ) { sessp = 0; } @@ -1022,9 +1023,10 @@ content_init( intgen_t argc, if ( inv_idbt != INV_TOKEN_NULL ) { /* REFERENCED */ bool_t ok1; - ok = inv_lastsession_level_equalto( inv_idbt, - ( u_char_t )sc_level, - &sessp ); + ok = inv_lastsession_level_equalto(&fsid, + inv_idbt, + (u_char_t)sc_level, + &sessp); ok1 = inv_close( inv_idbt ); ASSERT( ok1 ); if ( ! ok ) { Index: b/inventory/inv_api.c =================================================================== --- a/inventory/inv_api.c +++ b/inventory/inv_api.c @@ -596,69 +596,78 @@ inv_free_session( /*----------------------------------------------------------------------*/ -/* inventory_lasttime_level_lessthan */ -/* */ -/* Given a token that refers to a file system, and a level, this returns*/ -/* the last time when a session of a lesser level was done. */ -/* */ -/* returns -1 on error. */ +/* inv_lasttime_level_lessthan */ +/* */ +/* Given a file system uuid, token that refers to a file system, and a */ +/* level, tm is populated with last time when a session of a lesser */ +/* level was done. */ +/* */ +/* Returns TRUE on success. */ /*----------------------------------------------------------------------*/ bool_t inv_lasttime_level_lessthan( - inv_idbtoken_t tok, - u_char level, - time32_t **tm ) + uuid_t *fsidp, + inv_idbtoken_t tok, + u_char level, + time32_t **tm) { int rval; if ( tok != INV_TOKEN_NULL ) { - rval = search_invt( tok->d_invindex_fd, &level, (void **) tm, - (search_callback_t) tm_level_lessthan ); + rval = search_invt(fsidp, tok->d_invindex_fd, &level, + (void **)tm, + (search_callback_t)tm_level_lessthan); return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; } - return invmgr_query_all_sessions((void *) &level, /* in */ - (void **) tm, /* out */ - (search_callback_t) tm_level_lessthan); + return invmgr_query_all_sessions(fsidp, /* fs uuid ptr */ + (void *)&level, /* in */ + (void **)tm, /* out */ + (search_callback_t)tm_level_lessthan); } - - - - /*----------------------------------------------------------------------*/ -/* */ -/* */ -/* */ +/* inv_lastsession_level_lessthan */ +/* */ +/* Given a file system uuid, token that refers to a file system, and a */ +/* level, ses is populated with a session of lesser than the level */ +/* passed in. */ +/* */ +/* Returns FALSE on an error, TRUE if not. If (*ses) is NULL, then the */ +/* search failed. */ /*----------------------------------------------------------------------*/ bool_t inv_lastsession_level_lessthan( - inv_idbtoken_t tok, + uuid_t *fsidp, + inv_idbtoken_t tok, u_char level, - inv_session_t **ses ) + inv_session_t **ses) { int rval; if ( tok != INV_TOKEN_NULL ) { - rval = search_invt( tok->d_invindex_fd, &level, (void **) ses, - (search_callback_t) lastsess_level_lessthan ); + rval = search_invt(fsidp, tok->d_invindex_fd, &level, + (void **)ses, + (search_callback_t)lastsess_level_lessthan); return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; } - return invmgr_query_all_sessions((void *) &level, /* in */ - (void **) ses, /* out */ - (search_callback_t) lastsess_level_lessthan); + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *)&level, /* in */ + (void **)ses, /* out */ + (search_callback_t)lastsess_level_lessthan); } - - - /*----------------------------------------------------------------------*/ -/* */ -/* */ +/* inv_lastsession_level_equalto */ +/* */ +/* Given a file system uuid, token that refers to a file system, and a */ +/* level, this populates ses with last time when a session of a lesser */ +/* level was done. */ +/* */ /* Return FALSE on an error, TRUE if not. If (*ses) is NULL, then the */ /* search failed. */ /*----------------------------------------------------------------------*/ @@ -666,21 +675,24 @@ inv_lastsession_level_lessthan( bool_t inv_lastsession_level_equalto( - inv_idbtoken_t tok, + uuid_t *fsidp, + inv_idbtoken_t tok, u_char level, inv_session_t **ses ) { int rval; if ( tok != INV_TOKEN_NULL ) { - rval = search_invt( tok->d_invindex_fd, &level, (void **) ses, - (search_callback_t) lastsess_level_equalto ); + rval = search_invt(fsidp, tok->d_invindex_fd, &level, + (void **)ses, + (search_callback_t)lastsess_level_equalto); return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; } - return invmgr_query_all_sessions((void *) &level, /* in */ - (void **) ses, /* out */ - (search_callback_t) lastsess_level_equalto); + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *)&level, /* in */ + (void **)ses, /* out */ + (search_callback_t)lastsess_level_equalto); } @@ -688,35 +700,45 @@ inv_lastsession_level_equalto( /*----------------------------------------------------------------------*/ /* inv_getsession_byuuid */ /* */ +/* Given a file system uuid and a session uuid , ses is populated with */ +/* the session that contains the matching system uuid. */ +/* */ +/* Returns FALSE on an error, TRUE if the session was found. */ /*----------------------------------------------------------------------*/ bool_t inv_get_session_byuuid( - uuid_t *sesid, - inv_session_t **ses) + uuid_t *fsidp, + uuid_t *sesid, + inv_session_t **ses) { - return (invmgr_query_all_sessions((void *)sesid, /* in */ - (void **) ses, /* out */ - (search_callback_t) stobj_getsession_byuuid)); + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *)sesid, /* in */ + (void **)ses, /* out */ + (search_callback_t)stobj_getsession_byuuid); } - - /*----------------------------------------------------------------------*/ -/* inv_getsession_byuuid */ +/* inv_getsession_bylabel */ /* */ +/* Given a file system uuid and a session uuid, ses is populated with */ +/* the session that contains the matching system label. */ +/* */ +/* Returns FALSE on an error, TRUE if the session was found. */ /*----------------------------------------------------------------------*/ bool_t inv_get_session_bylabel( - char *session_label, - inv_session_t **ses) + uuid_t *fsidp, + char *session_label, + inv_session_t **ses) { - return (invmgr_query_all_sessions((void *)session_label, /* in */ - (void **) ses, /* out */ - (search_callback_t) stobj_getsession_bylabel)); + return invmgr_query_all_sessions(fsidp, /* fs uuid */ + (void *)session_label, /* in */ + (void **)ses, /* out */ + (search_callback_t)stobj_getsession_bylabel); } @@ -786,8 +808,8 @@ inv_delete_mediaobj( uuid_t *moid ) return BOOL_FALSE; } - if ( search_invt( invfd, NULL, (void **)&moid, - (search_callback_t) stobj_delete_mobj ) + if (search_invt(&arr[i].ft_uuid, invfd, NULL, (void **)&moid, + (search_callback_t)stobj_delete_mobj) < 0 ) return BOOL_FALSE; /* we have to delete the session, etc */ Index: b/inventory/inv_mgr.c =================================================================== --- a/inventory/inv_mgr.c +++ b/inventory/inv_mgr.c @@ -134,8 +134,9 @@ get_sesstoken( inv_idbtoken_t tok ) /*---------------------------------------------------------------------------*/ bool_t invmgr_query_all_sessions ( - void *inarg, - void **outarg, + uuid_t *fsidp, + void *inarg, + void **outarg, search_callback_t func) { invt_counter_t *cnt; @@ -145,6 +146,7 @@ invmgr_query_all_sessions ( int result; inv_oflag_t forwhat = INV_SEARCH_ONLY; void *objectfound; + bool_t ret = BOOL_FALSE; /* if on return, this is still null, the search failed */ *outarg = NULL; @@ -157,7 +159,7 @@ invmgr_query_all_sessions ( } if ( fd < 0 || numfs <= 0 ) { mlog( MLOG_NORMAL | MLOG_INV, _("INV: Error in fstab\n") ); - return BOOL_FALSE; + return ret; } close( fd ); @@ -169,7 +171,7 @@ invmgr_query_all_sessions ( mlog( MLOG_NORMAL | MLOG_INV, _( "INV: Cant get inv-name for uuid\n") ); - return BOOL_FALSE; + continue; } strcat( fname, INV_INVINDEX_PREFIX ); invfd = open( fname, INV_OFLAG(forwhat) ); @@ -178,9 +180,9 @@ invmgr_query_all_sessions ( "INV: Open failed on %s\n"), fname ); - return BOOL_FALSE; + continue; } - result = search_invt( invfd, inarg, &objectfound, func ); + result = search_invt(fsidp, invfd, inarg, &objectfound, func); close(invfd); /* if error return BOOL_FALSE */ @@ -192,12 +194,13 @@ invmgr_query_all_sessions ( return BOOL_TRUE; } else if (result == 1) { *outarg = objectfound; + ret = BOOL_TRUE; } } /* return val indicates if there was an error or not. *buf says whether the search was successful */ - return BOOL_TRUE; + return ret; } @@ -213,10 +216,11 @@ invmgr_query_all_sessions ( intgen_t search_invt( - int invfd, - void *arg, - void **buf, - search_callback_t do_chkcriteria ) + uuid_t *fsidp, + int invfd, + void *arg, + void **buf, + search_callback_t do_chkcriteria) { int fd, i; @@ -247,7 +251,7 @@ search_invt( /* we need to get all the invindex headers and seshdrs in reverse order */ for (i = nindices - 1; i >= 0; i--) { - int nsess; + int nsess, j; invt_sescounter_t *scnt = NULL; invt_seshdr_t *harr = NULL; bool_t found; @@ -272,19 +276,34 @@ search_invt( } free ( scnt ); - while ( nsess ) { + for (j = nsess - 1; j >= 0; j--) { + invt_session_t ses; + /* fd is kept locked until we return from the callback routine */ /* Check to see if this session has been pruned * by xfsinvutil before checking it. */ - if ( harr[nsess - 1].sh_pruned ) { - --nsess; + if (harr[j].sh_pruned) { continue; } - found = (* do_chkcriteria ) ( fd, &harr[ --nsess ], - arg, buf ); + + /* if we need to check the fs uuid's and they don't + * match or we fail to get the session record, + * then keep looking + */ + if (fsidp) { + int ret = GET_REC_NOLOCK(fd, &ses, + sizeof(invt_session_t), + harr[j].sh_sess_off); + if (ret < 0) + return ret; + if (uuid_compare(ses.s_fsid, *fsidp)) + continue; + } + + found = (* do_chkcriteria)(fd, &harr[j], arg, buf); if (! found ) continue; /* we found what we need; just return */ Index: b/inventory/inv_priv.h =================================================================== --- a/inventory/inv_priv.h +++ b/inventory/inv_priv.h @@ -548,11 +548,12 @@ get_headerinfo( int fd, void **hdrs, voi size_t hdrsz, size_t cntsz, bool_t doblock ); bool_t -invmgr_query_all_sessions (void *inarg, void **outarg, search_callback_t func); +invmgr_query_all_sessions(uuid_t *fsidp, void *inarg, void **outarg, + search_callback_t func); intgen_t -search_invt( int invfd, void *arg, void **buf, - search_callback_t do_chkcriteria ); +search_invt(uuid_t *fsidp, int invfd, void *arg, void **buf, + search_callback_t do_chkcriteria); intgen_t invmgr_inv_print( int invfd, invt_pr_ctx_t *prctx); Index: b/inventory/inventory.h =================================================================== --- a/inventory/inventory.h +++ b/inventory/inventory.h @@ -247,32 +247,37 @@ inv_put_mediafile( */ extern bool_t inv_lasttime_level_lessthan( + uuid_t *fsidp, inv_idbtoken_t tok, - u_char level, - time32_t **time );/* out */ + u_char level, + time32_t **time); /* out */ extern bool_t inv_lastsession_level_lessthan( + uuid_t *fsidp, inv_idbtoken_t tok, u_char level, - inv_session_t **ses );/* out */ + inv_session_t **ses); /* out */ extern bool_t inv_lastsession_level_equalto( + uuid_t *fsidp, inv_idbtoken_t tok, u_char level, - inv_session_t **ses );/* out */ + inv_session_t **ses); /* out */ /* Given a uuid of a session, return the session structure.*/ extern bool_t inv_get_session_byuuid( - uuid_t *sesid, - inv_session_t **ses); + uuid_t *fsidp, + uuid_t *sesid, + inv_session_t **ses); extern bool_t inv_get_session_bylabel( - char *session_label, - inv_session_t **ses); + uuid_t *fsidp, + char *session_label, + inv_session_t **ses); /* on return, *ses is NULL */ Index: b/restore/content.c =================================================================== --- a/restore/content.c +++ b/restore/content.c @@ -2179,8 +2179,9 @@ content_stream_restore( ix_t thrdix ) if ( ! drivep->d_isnamedpipepr && ! drivep->d_isunnamedpipepr ) { - ok = inv_get_session_byuuid( &grhdrp->gh_dumpid, - &sessp ); + ok = inv_get_session_byuuid(NULL, + &grhdrp->gh_dumpid, + &sessp); if ( ok && sessp ) { mlog( MLOG_VERBOSE, _( "using online session inventory\n") ); @@ -3736,9 +3737,9 @@ Inv_validate_cmdline( void ) ok = BOOL_FALSE; sessp = 0; if ( tranp->t_reqdumpidvalpr ) { - ok = inv_get_session_byuuid( &tranp->t_reqdumpid, &sessp ); + ok = inv_get_session_byuuid(NULL, &tranp->t_reqdumpid, &sessp); } else if ( tranp->t_reqdumplabvalpr ) { - ok = inv_get_session_bylabel( tranp->t_reqdumplab, &sessp ); + ok = inv_get_session_bylabel(NULL, tranp->t_reqdumplab, &sessp); } rok = BOOL_FALSE; if ( ok && sessp ) { @@ -6812,13 +6813,15 @@ askinvforbaseof( uuid_t baseid, inv_sess /* get the base session */ if ( resumedpr ) { - ok = inv_lastsession_level_equalto( invtok, - ( u_char_t )level, - &basesessp ); + ok = inv_lastsession_level_equalto(&sessp->s_fsid, + invtok, + (u_char_t)level, + &basesessp); } else { - ok = inv_lastsession_level_lessthan( invtok, - ( u_char_t )level, - &basesessp ); + ok = inv_lastsession_level_lessthan(&sessp->s_fsid, + invtok, + (u_char_t)level, + &basesessp); } if ( ! ok ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_MEDIA, _( From bfoster@redhat.com Fri Sep 11 13:53:58 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 51C4C7F37 for ; Fri, 11 Sep 2015 13:53:58 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 428C3304039 for ; Fri, 11 Sep 2015 11:53:58 -0700 (PDT) X-ASG-Debug-ID: 1441997637-04cb6c355c6fb70001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id vnKUrIP7xgxgN1ia (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:53:57 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id D9F2991C0E for ; Fri, 11 Sep 2015 18:53:56 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BIrumv025857 for ; Fri, 11 Sep 2015 14:53:56 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 337391236D9; Fri, 11 Sep 2015 14:53:55 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [RFC v2 0/2] xfs: detect and warn about invalid metadata lsns Date: Fri, 11 Sep 2015 14:53:53 -0400 X-ASG-Orig-Subj: [RFC v2 0/2] xfs: detect and warn about invalid metadata lsns Message-Id: <1441997635-36644-1-git-send-email-bfoster@redhat.com> 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: 1441997637 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi all, Here's a second rfc pass at the kernel side of invalid metadata LSN detection for v5 supers. This is an rfc simply because my understanding is that the userspace code should probably go first so that the tools for repair are available before the kernel starts detecting and warning about this problem. The primary change in this version is how the problem is handled once detected. I've been a bit undecided on whether a shutdown is really warranted because if the fs doesn't crash, it will eventually self-correct. On the flipside, a WARN_ON_ONCE() is not sufficient because it could suppress warnings on separate filesystems once one filesystem has encountered the issue and fired a warning. Therefore, this version uses something of a happy medium. The filesystem is not shutdown but a mount flag is used to warn about the problem at least once per-mount. Any instances thereafter are ratelimited to a once per 24 hour period. Brian rfcv2: - Refactored lsn validation and warning code into separate helpers. - Updated warning mechanism to warn at least once per fs (ratelimited thereafter). - No longer shutdown the fs on invalid metadata lsn detection. rfcv1: http://oss.sgi.com/pipermail/xfs/2015-August/043396.html Brian Foster (2): xfs: create a daily warning mechanism xfs: validate metadata LSNs against log on v5 superblocks fs/xfs/libxfs/xfs_alloc.c | 9 +++++-- fs/xfs/libxfs/xfs_attr_leaf.c | 2 ++ fs/xfs/libxfs/xfs_btree.c | 14 +++++++++-- fs/xfs/libxfs/xfs_da_btree.c | 3 +++ fs/xfs/libxfs/xfs_dir2_block.c | 1 + fs/xfs/libxfs/xfs_dir2_data.c | 1 + fs/xfs/libxfs/xfs_dir2_leaf.c | 1 + fs/xfs/libxfs/xfs_dir2_node.c | 1 + fs/xfs/libxfs/xfs_ialloc.c | 8 +++++-- fs/xfs/libxfs/xfs_sb.c | 8 +++++++ fs/xfs/libxfs/xfs_symlink_remote.c | 3 +++ fs/xfs/xfs_log.c | 1 - fs/xfs/xfs_log_priv.h | 24 +++++++++++++++++++ fs/xfs/xfs_log_recover.c | 15 +++++++++++- fs/xfs/xfs_message.h | 18 ++++++++++---- fs/xfs/xfs_mount.c | 49 ++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_mount.h | 3 +++ 17 files changed, 149 insertions(+), 12 deletions(-) -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:53:59 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 93F107F37 for ; Fri, 11 Sep 2015 13:53:59 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 84CAF304039 for ; Fri, 11 Sep 2015 11:53:59 -0700 (PDT) X-ASG-Debug-ID: 1441997637-04cb6c355a6fb70001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id kXTjNFnMrFQ7veU9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:53:57 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 2AD248E3C0 for ; Fri, 11 Sep 2015 18:53:57 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BIruAT025859 for ; Fri, 11 Sep 2015 14:53:56 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 461D0122E0A; Fri, 11 Sep 2015 14:53:55 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [RFC v2 2/2] xfs: validate metadata LSNs against log on v5 superblocks Date: Fri, 11 Sep 2015 14:53:55 -0400 X-ASG-Orig-Subj: [RFC v2 2/2] xfs: validate metadata LSNs against log on v5 superblocks Message-Id: <1441997635-36644-3-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997635-36644-1-git-send-email-bfoster@redhat.com> References: <1441997635-36644-1-git-send-email-bfoster@redhat.com> 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: 1441997637 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Since the onset of v5 superblocks, the LSN of the last modification has been included in a variety of on-disk data structures. This LSN is used to provide log recovery ordering guarantees (e.g., to ensure an older log recovery item is not replayed over a newer target data structure). While this works correctly from the point a filesystem is formatted and mounted, userspace tools have some problematic behaviors that defeat this mechanism. For example, xfs_repair historically zeroes out the log unconditionally (regardless of whether corruption is detected). If this occurs, the LSN of the filesystem is reset and the log is now in a problematic state with respect to on-disk metadata structures that might have a larger LSN. Until either the log catches up to the highest previously used metadata LSN or each affected data structure is modified and written out without incident (which resets the metadata LSN), log recovery is susceptible to filesystem corruption. This problem is ultimately addressed and repaired in the associated userspace tools. The kernel is still responsible to detect the problem and notify the user that something is wrong. Check the superblock LSN at mount time and notify the user and fail the mount if it is invalid. >From that point on, simply warn the user if an invalid metadata LSN is detected from the various metadata I/O verifiers. A new xfs_mount flag is added to guarantee that a warning fires at least once for each affected filesystem mount. From that point forward, further instances of the problem are rate limited to a once per 24 hour period. Signed-off-by: Brian Foster --- fs/xfs/libxfs/xfs_alloc.c | 9 +++++-- fs/xfs/libxfs/xfs_attr_leaf.c | 2 ++ fs/xfs/libxfs/xfs_btree.c | 14 +++++++++-- fs/xfs/libxfs/xfs_da_btree.c | 3 +++ fs/xfs/libxfs/xfs_dir2_block.c | 1 + fs/xfs/libxfs/xfs_dir2_data.c | 1 + fs/xfs/libxfs/xfs_dir2_leaf.c | 1 + fs/xfs/libxfs/xfs_dir2_node.c | 1 + fs/xfs/libxfs/xfs_ialloc.c | 8 +++++-- fs/xfs/libxfs/xfs_sb.c | 8 +++++++ fs/xfs/libxfs/xfs_symlink_remote.c | 3 +++ fs/xfs/xfs_log.c | 1 - fs/xfs/xfs_log_priv.h | 24 +++++++++++++++++++ fs/xfs/xfs_log_recover.c | 15 +++++++++++- fs/xfs/xfs_mount.c | 49 ++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_mount.h | 3 +++ 16 files changed, 135 insertions(+), 8 deletions(-) diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c index ffad7f2..cb26016 100644 --- a/fs/xfs/libxfs/xfs_alloc.c +++ b/fs/xfs/libxfs/xfs_alloc.c @@ -482,6 +482,8 @@ xfs_agfl_verify( be32_to_cpu(agfl->agfl_bno[i]) >= mp->m_sb.sb_agblocks) return false; } + + xfs_detect_invalid_lsn(mp, be64_to_cpu(XFS_BUF_TO_AGFL(bp)->agfl_lsn)); return true; } @@ -2259,9 +2261,12 @@ xfs_agf_verify( { struct xfs_agf *agf = XFS_BUF_TO_AGF(bp); - if (xfs_sb_version_hascrc(&mp->m_sb) && - !uuid_equal(&agf->agf_uuid, &mp->m_sb.sb_meta_uuid)) + if (xfs_sb_version_hascrc(&mp->m_sb)) { + if (!uuid_equal(&agf->agf_uuid, &mp->m_sb.sb_meta_uuid)) return false; + xfs_detect_invalid_lsn(mp, + be64_to_cpu(XFS_BUF_TO_AGF(bp)->agf_lsn)); + } if (!(agf->agf_magicnum == cpu_to_be32(XFS_AGF_MAGIC) && XFS_AGF_GOOD_VERSION(be32_to_cpu(agf->agf_versionnum)) && diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c index 33df52d..643ba73 100644 --- a/fs/xfs/libxfs/xfs_attr_leaf.c +++ b/fs/xfs/libxfs/xfs_attr_leaf.c @@ -266,6 +266,8 @@ xfs_attr3_leaf_verify( return false; if (be64_to_cpu(hdr3->info.blkno) != bp->b_bn) return false; + + xfs_detect_invalid_lsn(mp, be64_to_cpu(hdr3->info.lsn)); } else { if (ichdr.magic != XFS_ATTR_LEAF_MAGIC) return false; diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c index f7d7ee7..c2c5765 100644 --- a/fs/xfs/libxfs/xfs_btree.c +++ b/fs/xfs/libxfs/xfs_btree.c @@ -243,8 +243,13 @@ bool xfs_btree_lblock_verify_crc( struct xfs_buf *bp) { - if (xfs_sb_version_hascrc(&bp->b_target->bt_mount->m_sb)) + struct xfs_btree_block *block = XFS_BUF_TO_BLOCK(bp); + struct xfs_mount *mp = bp->b_target->bt_mount; + + if (xfs_sb_version_hascrc(&bp->b_target->bt_mount->m_sb)) { + xfs_detect_invalid_lsn(mp, be64_to_cpu(block->bb_u.l.bb_lsn)); return xfs_buf_verify_cksum(bp, XFS_BTREE_LBLOCK_CRC_OFF); + } return true; } @@ -275,8 +280,13 @@ bool xfs_btree_sblock_verify_crc( struct xfs_buf *bp) { - if (xfs_sb_version_hascrc(&bp->b_target->bt_mount->m_sb)) + struct xfs_btree_block *block = XFS_BUF_TO_BLOCK(bp); + struct xfs_mount *mp = bp->b_target->bt_mount; + + if (xfs_sb_version_hascrc(&bp->b_target->bt_mount->m_sb)) { + xfs_detect_invalid_lsn(mp, be64_to_cpu(block->bb_u.s.bb_lsn)); return xfs_buf_verify_cksum(bp, XFS_BTREE_SBLOCK_CRC_OFF); + } return true; } diff --git a/fs/xfs/libxfs/xfs_da_btree.c b/fs/xfs/libxfs/xfs_da_btree.c index be43248..2ea7982 100644 --- a/fs/xfs/libxfs/xfs_da_btree.c +++ b/fs/xfs/libxfs/xfs_da_btree.c @@ -150,6 +150,8 @@ xfs_da3_node_verify( return false; if (be64_to_cpu(hdr3->info.blkno) != bp->b_bn) return false; + + xfs_detect_invalid_lsn(mp, be64_to_cpu(hdr3->info.lsn)); } else { if (ichdr.magic != XFS_DA_NODE_MAGIC) return false; @@ -322,6 +324,7 @@ xfs_da3_node_create( if (xfs_sb_version_hascrc(&mp->m_sb)) { struct xfs_da3_node_hdr *hdr3 = bp->b_addr; + memset(hdr3, 0, sizeof(struct xfs_da3_node_hdr)); ichdr.magic = XFS_DA3_NODE_MAGIC; hdr3->info.blkno = cpu_to_be64(bp->b_bn); hdr3->info.owner = cpu_to_be64(args->dp->i_ino); diff --git a/fs/xfs/libxfs/xfs_dir2_block.c b/fs/xfs/libxfs/xfs_dir2_block.c index 4778d1d..9cd553f 100644 --- a/fs/xfs/libxfs/xfs_dir2_block.c +++ b/fs/xfs/libxfs/xfs_dir2_block.c @@ -71,6 +71,7 @@ xfs_dir3_block_verify( return false; if (be64_to_cpu(hdr3->blkno) != bp->b_bn) return false; + xfs_detect_invalid_lsn(mp, be64_to_cpu(hdr3->lsn)); } else { if (hdr3->magic != cpu_to_be32(XFS_DIR2_BLOCK_MAGIC)) return false; diff --git a/fs/xfs/libxfs/xfs_dir2_data.c b/fs/xfs/libxfs/xfs_dir2_data.c index 824131e..d9c6d6e 100644 --- a/fs/xfs/libxfs/xfs_dir2_data.c +++ b/fs/xfs/libxfs/xfs_dir2_data.c @@ -224,6 +224,7 @@ xfs_dir3_data_verify( return false; if (be64_to_cpu(hdr3->blkno) != bp->b_bn) return false; + xfs_detect_invalid_lsn(mp, be64_to_cpu(hdr3->lsn)); } else { if (hdr3->magic != cpu_to_be32(XFS_DIR2_DATA_MAGIC)) return false; diff --git a/fs/xfs/libxfs/xfs_dir2_leaf.c b/fs/xfs/libxfs/xfs_dir2_leaf.c index f300240..896de9e 100644 --- a/fs/xfs/libxfs/xfs_dir2_leaf.c +++ b/fs/xfs/libxfs/xfs_dir2_leaf.c @@ -164,6 +164,7 @@ xfs_dir3_leaf_verify( return false; if (be64_to_cpu(leaf3->info.blkno) != bp->b_bn) return false; + xfs_detect_invalid_lsn(mp, be64_to_cpu(leaf3->info.lsn)); } else { if (leaf->hdr.info.magic != cpu_to_be16(magic)) return false; diff --git a/fs/xfs/libxfs/xfs_dir2_node.c b/fs/xfs/libxfs/xfs_dir2_node.c index cc28e92..c0bfeef 100644 --- a/fs/xfs/libxfs/xfs_dir2_node.c +++ b/fs/xfs/libxfs/xfs_dir2_node.c @@ -97,6 +97,7 @@ xfs_dir3_free_verify( return false; if (be64_to_cpu(hdr3->blkno) != bp->b_bn) return false; + xfs_detect_invalid_lsn(mp, be64_to_cpu(hdr3->lsn)); } else { if (hdr->magic != cpu_to_be32(XFS_DIR2_FREE_MAGIC)) return false; diff --git a/fs/xfs/libxfs/xfs_ialloc.c b/fs/xfs/libxfs/xfs_ialloc.c index 54deb2d..e91343b 100644 --- a/fs/xfs/libxfs/xfs_ialloc.c +++ b/fs/xfs/libxfs/xfs_ialloc.c @@ -2500,9 +2500,13 @@ xfs_agi_verify( struct xfs_mount *mp = bp->b_target->bt_mount; struct xfs_agi *agi = XFS_BUF_TO_AGI(bp); - if (xfs_sb_version_hascrc(&mp->m_sb) && - !uuid_equal(&agi->agi_uuid, &mp->m_sb.sb_meta_uuid)) + if (xfs_sb_version_hascrc(&mp->m_sb)) { + if (!uuid_equal(&agi->agi_uuid, &mp->m_sb.sb_meta_uuid)) return false; + xfs_detect_invalid_lsn(mp, + be64_to_cpu(XFS_BUF_TO_AGI(bp)->agi_lsn)); + } + /* * Validate the magic number of the agi block. */ diff --git a/fs/xfs/libxfs/xfs_sb.c b/fs/xfs/libxfs/xfs_sb.c index 4742514..badf587 100644 --- a/fs/xfs/libxfs/xfs_sb.c +++ b/fs/xfs/libxfs/xfs_sb.c @@ -163,6 +163,14 @@ xfs_mount_validate_sb( "Filesystem can not be safely mounted by this kernel."); return -EINVAL; } + } else if (xfs_sb_version_hascrc(sbp)) { + /* + * We can't read verify the sb LSN because the read verifier is + * called before the log is allocated and processed. We know the + * log is set up before write verifier (!check_version) calls, + * so just check it here. + */ + xfs_detect_invalid_lsn(mp, sbp->sb_lsn); } if (xfs_sb_version_has_pquotino(sbp)) { diff --git a/fs/xfs/libxfs/xfs_symlink_remote.c b/fs/xfs/libxfs/xfs_symlink_remote.c index 8f8af05..aa6b3c1 100644 --- a/fs/xfs/libxfs/xfs_symlink_remote.c +++ b/fs/xfs/libxfs/xfs_symlink_remote.c @@ -60,6 +60,7 @@ xfs_symlink_hdr_set( if (!xfs_sb_version_hascrc(&mp->m_sb)) return 0; + memset(dsl, 0, sizeof(struct xfs_dsymlink_hdr)); dsl->sl_magic = cpu_to_be32(XFS_SYMLINK_MAGIC); dsl->sl_offset = cpu_to_be32(offset); dsl->sl_bytes = cpu_to_be32(size); @@ -117,6 +118,8 @@ xfs_symlink_verify( if (dsl->sl_owner == 0) return false; + xfs_detect_invalid_lsn(mp, be64_to_cpu(dsl->sl_lsn)); + return true; } diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index aaadee0..a34476b 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -4022,4 +4022,3 @@ xlog_iclogs_empty( } while (iclog != log->l_iclog); return 1; } - diff --git a/fs/xfs/xfs_log_priv.h b/fs/xfs/xfs_log_priv.h index 950f3f9..c0acc71 100644 --- a/fs/xfs/xfs_log_priv.h +++ b/fs/xfs/xfs_log_priv.h @@ -560,4 +560,28 @@ static inline void xlog_wait(wait_queue_head_t *wq, spinlock_t *lock) remove_wait_queue(wq, &wait); } +/* + * The LSN is valid so long as it is behind the current LSN. If it isn't, this + * means that the next log record that includes this metadata could have a + * smaller LSN. In turn, this means that the modification in the log would not + * replay. + */ +static inline bool +xlog_valid_lsn( + struct xlog *log, + xfs_lsn_t lsn) +{ + int cycle = CYCLE_LSN(lsn); + int block = BLOCK_LSN(lsn); + bool valid = true; + + spin_lock(&log->l_icloglock); + if ((cycle > log->l_curr_cycle) || + (cycle == log->l_curr_cycle && block > log->l_curr_block)) + valid = false; + spin_unlock(&log->l_icloglock); + + return valid; +} + #endif /* __XFS_LOG_PRIV_H__ */ diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c index 512a094..c6ea06a 100644 --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -4609,9 +4609,22 @@ xlog_recover( int error; /* find the tail of the log */ - if ((error = xlog_find_tail(log, &head_blk, &tail_blk))) + error = xlog_find_tail(log, &head_blk, &tail_blk); + if (error) return error; + /* + * The superblock was read before the log was available and thus the LSN + * could not be verified. Check the superblock LSN against the current + * LSN now that it's known. + */ + if (xfs_sb_version_hascrc(&log->l_mp->m_sb) && + !xlog_valid_lsn(log, log->l_mp->m_sb.sb_lsn)) { + xfs_warn(log->l_mp, + "Invalid superblock LSN (ahead of log). Please run xfs_repair."); + return -EINVAL; + } + if (tail_blk != head_blk) { /* There used to be a comment here: * diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index bf92e0c..0acfea8 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -41,6 +41,7 @@ #include "xfs_trace.h" #include "xfs_icache.h" #include "xfs_sysfs.h" +#include "xfs_log_priv.h" static DEFINE_MUTEX(xfs_uuid_table_mutex); @@ -1301,3 +1302,51 @@ xfs_dev_is_read_only( } return 0; } + +/* + * Verify that an LSN stamped into a piece of metadata is valid. This is + * intended for use in read verifiers on v5 superblocks. + */ +void +xfs_detect_invalid_lsn( + struct xfs_mount *mp, + xfs_lsn_t lsn) +{ + struct xlog *log = mp->m_log; + int cycle = CYCLE_LSN(lsn); + int block = BLOCK_LSN(lsn); + const char *fmt; + + /* + * 'norecovery' mode skips mount-time log processing and unconditionally + * resets the LSN. + */ + if (mp->m_flags & XFS_MOUNT_NORECOVERY) + return; + + if (xlog_valid_lsn(mp->m_log, lsn)) + return; + + /* + * Warn at least once for each filesystem susceptible to this problem + * and once per day thereafter. + * + * XXX: Specify the minimum xfs_repair version required to resolve? + * Older versions will silently reintroduce the problem. + * + * We should eventually convert this condition into a hard error (via + * verifier failure). Defer that behavior for a few release cycles or so + * until the userspace fixes have had the opportunity to propogate + * throughout the various distributions. + */ + fmt = "WARNING: Metadata has LSN (%d:%d) ahead of current LSN (%d:%d). " +"This may result in filesystem failure. Please unmount and run xfs_repair to resolve."; + if (!mp->m_warned_bad_lsn) { + mp->m_warned_bad_lsn = true; + xfs_warn(mp, fmt, cycle, block, log->l_curr_cycle, + log->l_curr_block); + } else { + xfs_warn_daily(mp, fmt, cycle, block, log->l_curr_cycle, + log->l_curr_block); + } +} diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 7999e91..572ebfc 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -127,6 +127,7 @@ typedef struct xfs_mount { int64_t m_low_space[XFS_LOWSP_MAX]; /* low free space thresholds */ struct xfs_kobj m_kobj; + bool m_warned_bad_lsn;/* bad metadata lsn detected */ struct workqueue_struct *m_buf_workqueue; struct workqueue_struct *m_data_workqueue; @@ -336,4 +337,6 @@ extern int xfs_dev_is_read_only(struct xfs_mount *, char *); extern void xfs_set_low_space_thresholds(struct xfs_mount *); +extern void xfs_detect_invalid_lsn(struct xfs_mount *, xfs_lsn_t); + #endif /* __XFS_MOUNT_H__ */ -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:54:01 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 40BF37F50 for ; Fri, 11 Sep 2015 13:54:01 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 21792304039 for ; Fri, 11 Sep 2015 11:53:58 -0700 (PDT) X-ASG-Debug-ID: 1441997637-04bdf04db676c10001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 3mmuYM7ISWbRMd3R (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:53:57 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id EF007C0A1605 for ; Fri, 11 Sep 2015 18:53:56 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BIruYM021782 for ; Fri, 11 Sep 2015 14:53:56 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 52C48124862; Fri, 11 Sep 2015 14:53:55 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [RFC v2 1/2] xfs: create a daily warning mechanism Date: Fri, 11 Sep 2015 14:53:54 -0400 X-ASG-Orig-Subj: [RFC v2 1/2] xfs: create a daily warning mechanism Message-Id: <1441997635-36644-2-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997635-36644-1-git-send-email-bfoster@redhat.com> References: <1441997635-36644-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441997637 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 The warning mechanism in XFS currently uses the default ratelimit time interval and burst parameters. The default parameters are intended to avoid flooding the logs and whatnot due to messages within fairly short timeframes (e.g., 10 messages within 5s). The forthcoming invalid metadata LSN detection must provide a consistent, but not incessant warning to the user that a repair is required to reformat the log. Update the core ratelimit mechanism to allow customized parameters, continue to pass the ratelimit defaults for existing users, and define a new xfs_warn_daily() mechanism to fire a message on a 24 hour interval. Signed-off-by: Brian Foster --- fs/xfs/xfs_message.h | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/fs/xfs/xfs_message.h b/fs/xfs/xfs_message.h index 8540115..9f1a036 100644 --- a/fs/xfs/xfs_message.h +++ b/fs/xfs/xfs_message.h @@ -30,15 +30,22 @@ void xfs_debug(const struct xfs_mount *mp, const char *fmt, ...) } #endif -#define xfs_printk_ratelimited(func, dev, fmt, ...) \ +#define __xfs_printk_ratelimited(interval, burst, func, dev, fmt, ...) \ do { \ - static DEFINE_RATELIMIT_STATE(_rs, \ - DEFAULT_RATELIMIT_INTERVAL, \ - DEFAULT_RATELIMIT_BURST); \ + static DEFINE_RATELIMIT_STATE(_rs, interval, burst); \ if (__ratelimit(&_rs)) \ func(dev, fmt, ##__VA_ARGS__); \ } while (0) +#define xfs_printk_ratelimited(func, dev, fmt, ...) \ + __xfs_printk_ratelimited(DEFAULT_RATELIMIT_INTERVAL, \ + DEFAULT_RATELIMIT_BURST, \ + func, dev, fmt, ##__VA_ARGS__) + +#define xfs_printk_daily(func, dev, fmt, ...) \ + __xfs_printk_ratelimited(86400 * HZ, 1, func, dev, fmt, \ + ##__VA_ARGS__) + #define xfs_emerg_ratelimited(dev, fmt, ...) \ xfs_printk_ratelimited(xfs_emerg, dev, fmt, ##__VA_ARGS__) #define xfs_alert_ratelimited(dev, fmt, ...) \ @@ -56,6 +63,9 @@ do { \ #define xfs_debug_ratelimited(dev, fmt, ...) \ xfs_printk_ratelimited(xfs_debug, dev, fmt, ##__VA_ARGS__) +#define xfs_warn_daily(dev, fmt, ...) \ + xfs_printk_daily(xfs_warn, dev, fmt, ##__VA_ARGS__) + extern void assfail(char *expr, char *f, int l); extern void asswarn(char *expr, char *f, int l); -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:45 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id B1D0B7F50 for ; Fri, 11 Sep 2015 13:55:45 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 820C530404E for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-ASG-Debug-ID: 1441997744-04bdf04db376da0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 9Hr5ZMBu5uehVOxM (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:44 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 2055DA19CC for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BIthLI022528 for ; Fri, 11 Sep 2015 14:55:43 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 68EE91236D9; Fri, 11 Sep 2015 14:55:42 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 00/12] xfsprogs: format the log correctly on v5 supers Date: Fri, 11 Sep 2015 14:55:30 -0400 X-ASG-Orig-Subj: [PATCH v2 00/12] xfsprogs: format the log correctly on v5 supers Message-Id: <1441997742-37160-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441997744 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 This is pass 2 of the userspace side of the invalid metadata LSN fixes. It is based on the RFCv2 version of the associated kernel fixes: http://oss.sgi.com/pipermail/xfs/2015-September/043627.html Outside of the rebase to the latest kernel patch, this version adds support for the xfs_db uuid command and xfs_metadump. Both of these utilities clear the log under certain circumstances and thus both have been updated to format the log with a bumped cycle number when appropriate. The only remaining gap that I'm aware of is xfs_copy. xfs_copy support is not included because the log formatting code therein is slightly more complicated than what is done in other places. In particular, it uses its own buffer and alignment mechanisms that have to deal with direct I/O alignment rules and aren't easily compatible with the existing buffered log formatting mechanism. I haven't quite figured out how best to deal with that yet. Thoughts, reviews, flames appreciated. Brian v2: - Rebase to latest kernel variant of invalid metadata LSN detection. - Added support for xfs_db's uuid command and xfs_metadump. v1: http://oss.sgi.com/pipermail/xfs/2015-August/043397.html Brian Foster (12): libxfs: validate metadata LSNs against log on v5 superblocks libxfs: track largest metadata LSN in use via verifiers libxfs: don't hardcode cycle 1 into unmount op header libxfs: pass lsn param to log clear and record header logging helpers libxfs: add ability to clear log to arbitrary log cycle libxlog: pull struct xlog out of xlog_is_dirty() xfs_repair: track log state throughout all recovery phases xfs_repair: process the log in no_modify mode xfs_repair: format the log with forward cycle number on v5 supers xfs_repair: don't clear the log by default xfs_db: do not reset current lsn from uuid command on v5 supers db/metadump: bump lsn when log is cleared on v5 supers copy/xfs_copy.c | 4 +- db/init.c | 25 ++++--- db/metadump.c | 21 ++++-- db/sb.c | 18 ++++- include/libxfs.h | 13 ++-- include/libxlog.h | 3 +- include/xfs_mount.h | 6 ++ libxfs/libxfs_priv.h | 2 + libxfs/rdwr.c | 160 +++++++++++++++++++++++++++++++++++++------- libxfs/util.c | 38 +++++++++++ libxfs/xfs_alloc.c | 9 ++- libxfs/xfs_attr_leaf.c | 2 + libxfs/xfs_btree.c | 14 +++- libxfs/xfs_da_btree.c | 3 + libxfs/xfs_dir2_block.c | 1 + libxfs/xfs_dir2_data.c | 1 + libxfs/xfs_dir2_leaf.c | 1 + libxfs/xfs_dir2_node.c | 1 + libxfs/xfs_ialloc.c | 8 ++- libxfs/xfs_sb.c | 8 +++ libxfs/xfs_symlink_remote.c | 3 + libxlog/util.c | 37 +++++----- mkfs/xfs_mkfs.c | 4 +- repair/phase2.c | 83 +++++++++++++++-------- repair/xfs_repair.c | 79 +++++++++++++++++++++- 25 files changed, 436 insertions(+), 108 deletions(-) -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:46 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 41E937F51 for ; Fri, 11 Sep 2015 13:55:46 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 0ADDE8F8040 for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-ASG-Debug-ID: 1441997744-04bdf04db476db0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id mWWFxaG6K9GmifgV (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id D0741C0BB24E for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BItirP014638 for ; Fri, 11 Sep 2015 14:55:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id E04A41248B7; Fri, 11 Sep 2015 14:55:42 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 08/12] xfs_repair: process the log in no_modify mode Date: Fri, 11 Sep 2015 14:55:38 -0400 X-ASG-Orig-Subj: [PATCH v2 08/12] xfs_repair: process the log in no_modify mode Message-Id: <1441997742-37160-9-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com> References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> 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: 1441997745 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 xfs_repair does not zero the log in no_modify mode. In doing so, it also skips the function that scans the log, locates the head/tail blocks and sets the current LSN. Now that the log state is used beyond phase 2, the log scan must occur regardless of whether no_modify mode is enabled or not. Update phase 2 to always execute the log scanning code. Push down the no_modify checks into the log clearing helper such that the log is still not modified in no_modify mode. Signed-off-by: Brian Foster --- repair/phase2.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/repair/phase2.c b/repair/phase2.c index 11504e3..72132ce 100644 --- a/repair/phase2.c +++ b/repair/phase2.c @@ -75,7 +75,7 @@ zero_log(xfs_mount_t *mp) _("zero_log: head block %" PRId64 " tail block %" PRId64 "\n"), head_blk, tail_blk); } - if (head_blk != tail_blk) { + if (!no_modify && head_blk != tail_blk) { if (zap_log) { do_warn(_( "ALERT: The filesystem has valuable metadata changes in a log which is being\n" @@ -93,6 +93,9 @@ zero_log(xfs_mount_t *mp) } } + if (no_modify) + return; + libxfs_log_clear(log->l_dev, XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart), (xfs_extlen_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks), &mp->m_sb.sb_uuid, @@ -136,10 +139,8 @@ phase2( do_log(_("Phase 2 - using internal log\n")); /* Zero log if applicable */ - if (!no_modify) { - do_log(_(" - zero log...\n")); - zero_log(mp); - } + do_log(_(" - zero log...\n")); + zero_log(mp); do_log(_(" - scan filesystem freespace and inode maps...\n")); -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:46 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 2945F7F50 for ; Fri, 11 Sep 2015 13:55:46 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id BA132AC00E for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-ASG-Debug-ID: 1441997744-04bdf04db676db0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id LOGCgx94QjsIrrkS (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:44 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 346B8C0A1605 for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BIthPw022533 for ; Fri, 11 Sep 2015 14:55:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 79BC5124862; Fri, 11 Sep 2015 14:55:42 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 01/12] libxfs: validate metadata LSNs against log on v5 superblocks Date: Fri, 11 Sep 2015 14:55:31 -0400 X-ASG-Orig-Subj: [PATCH v2 01/12] libxfs: validate metadata LSNs against log on v5 superblocks Message-Id: <1441997742-37160-2-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com> References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441997744 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Backport the associated kernel commit. Replace the xfs_detect_invalid_lsn() helper with a stub. Signed-off-by: Brian Foster --- libxfs/libxfs_priv.h | 2 ++ libxfs/util.c | 7 +++++++ libxfs/xfs_alloc.c | 9 +++++++-- libxfs/xfs_attr_leaf.c | 2 ++ libxfs/xfs_btree.c | 14 ++++++++++++-- libxfs/xfs_da_btree.c | 3 +++ libxfs/xfs_dir2_block.c | 1 + libxfs/xfs_dir2_data.c | 1 + libxfs/xfs_dir2_leaf.c | 1 + libxfs/xfs_dir2_node.c | 1 + libxfs/xfs_ialloc.c | 8 ++++++-- libxfs/xfs_sb.c | 8 ++++++++ libxfs/xfs_symlink_remote.c | 3 +++ 13 files changed, 54 insertions(+), 6 deletions(-) diff --git a/libxfs/libxfs_priv.h b/libxfs/libxfs_priv.h index 22f2d53..59cb6c3 100644 --- a/libxfs/libxfs_priv.h +++ b/libxfs/libxfs_priv.h @@ -505,4 +505,6 @@ void xfs_verifier_error(struct xfs_buf *bp); /* xfs_rtalloc.c */ int libxfs_rtfree_extent(struct xfs_trans *, xfs_rtblock_t, xfs_extlen_t); +extern void xfs_detect_invalid_lsn(struct xfs_mount *, xfs_lsn_t); + #endif /* __LIBXFS_INTERNAL_XFS_H__ */ diff --git a/libxfs/util.c b/libxfs/util.c index c9f9175..43338b8 100644 --- a/libxfs/util.c +++ b/libxfs/util.c @@ -729,3 +729,10 @@ xfs_verifier_error( bp->b_error == -EFSBADCRC ? "CRC error" : "corruption", bp->b_bn, BBTOB(bp->b_length)); } + +void +xfs_detect_invalid_lsn( + struct xfs_mount *mp, + xfs_lsn_t lsn) +{ +} diff --git a/libxfs/xfs_alloc.c b/libxfs/xfs_alloc.c index 4f3008a..f1f2791 100644 --- a/libxfs/xfs_alloc.c +++ b/libxfs/xfs_alloc.c @@ -478,6 +478,8 @@ xfs_agfl_verify( be32_to_cpu(agfl->agfl_bno[i]) >= mp->m_sb.sb_agblocks) return false; } + + xfs_detect_invalid_lsn(mp, be64_to_cpu(XFS_BUF_TO_AGFL(bp)->agfl_lsn)); return true; } @@ -2255,9 +2257,12 @@ xfs_agf_verify( { struct xfs_agf *agf = XFS_BUF_TO_AGF(bp); - if (xfs_sb_version_hascrc(&mp->m_sb) && - !uuid_equal(&agf->agf_uuid, &mp->m_sb.sb_meta_uuid)) + if (xfs_sb_version_hascrc(&mp->m_sb)) { + if (!uuid_equal(&agf->agf_uuid, &mp->m_sb.sb_meta_uuid)) return false; + xfs_detect_invalid_lsn(mp, + be64_to_cpu(XFS_BUF_TO_AGF(bp)->agf_lsn)); + } if (!(agf->agf_magicnum == cpu_to_be32(XFS_AGF_MAGIC) && XFS_AGF_GOOD_VERSION(be32_to_cpu(agf->agf_versionnum)) && diff --git a/libxfs/xfs_attr_leaf.c b/libxfs/xfs_attr_leaf.c index cc25068..aca3cf8 100644 --- a/libxfs/xfs_attr_leaf.c +++ b/libxfs/xfs_attr_leaf.c @@ -262,6 +262,8 @@ xfs_attr3_leaf_verify( return false; if (be64_to_cpu(hdr3->info.blkno) != bp->b_bn) return false; + + xfs_detect_invalid_lsn(mp, be64_to_cpu(hdr3->info.lsn)); } else { if (ichdr.magic != XFS_ATTR_LEAF_MAGIC) return false; diff --git a/libxfs/xfs_btree.c b/libxfs/xfs_btree.c index a16ae7d..b2b2db5 100644 --- a/libxfs/xfs_btree.c +++ b/libxfs/xfs_btree.c @@ -240,8 +240,13 @@ bool xfs_btree_lblock_verify_crc( struct xfs_buf *bp) { - if (xfs_sb_version_hascrc(&bp->b_target->bt_mount->m_sb)) + struct xfs_btree_block *block = XFS_BUF_TO_BLOCK(bp); + struct xfs_mount *mp = bp->b_target->bt_mount; + + if (xfs_sb_version_hascrc(&bp->b_target->bt_mount->m_sb)) { + xfs_detect_invalid_lsn(mp, be64_to_cpu(block->bb_u.l.bb_lsn)); return xfs_buf_verify_cksum(bp, XFS_BTREE_LBLOCK_CRC_OFF); + } return true; } @@ -272,8 +277,13 @@ bool xfs_btree_sblock_verify_crc( struct xfs_buf *bp) { - if (xfs_sb_version_hascrc(&bp->b_target->bt_mount->m_sb)) + struct xfs_btree_block *block = XFS_BUF_TO_BLOCK(bp); + struct xfs_mount *mp = bp->b_target->bt_mount; + + if (xfs_sb_version_hascrc(&bp->b_target->bt_mount->m_sb)) { + xfs_detect_invalid_lsn(mp, be64_to_cpu(block->bb_u.s.bb_lsn)); return xfs_buf_verify_cksum(bp, XFS_BTREE_SBLOCK_CRC_OFF); + } return true; } diff --git a/libxfs/xfs_da_btree.c b/libxfs/xfs_da_btree.c index 289dc1e..beb02ed 100644 --- a/libxfs/xfs_da_btree.c +++ b/libxfs/xfs_da_btree.c @@ -146,6 +146,8 @@ xfs_da3_node_verify( return false; if (be64_to_cpu(hdr3->info.blkno) != bp->b_bn) return false; + + xfs_detect_invalid_lsn(mp, be64_to_cpu(hdr3->info.lsn)); } else { if (ichdr.magic != XFS_DA_NODE_MAGIC) return false; @@ -318,6 +320,7 @@ xfs_da3_node_create( if (xfs_sb_version_hascrc(&mp->m_sb)) { struct xfs_da3_node_hdr *hdr3 = bp->b_addr; + memset(hdr3, 0, sizeof(struct xfs_da3_node_hdr)); ichdr.magic = XFS_DA3_NODE_MAGIC; hdr3->info.blkno = cpu_to_be64(bp->b_bn); hdr3->info.owner = cpu_to_be64(args->dp->i_ino); diff --git a/libxfs/xfs_dir2_block.c b/libxfs/xfs_dir2_block.c index 489f301..c886d70 100644 --- a/libxfs/xfs_dir2_block.c +++ b/libxfs/xfs_dir2_block.c @@ -68,6 +68,7 @@ xfs_dir3_block_verify( return false; if (be64_to_cpu(hdr3->blkno) != bp->b_bn) return false; + xfs_detect_invalid_lsn(mp, be64_to_cpu(hdr3->lsn)); } else { if (hdr3->magic != cpu_to_be32(XFS_DIR2_BLOCK_MAGIC)) return false; diff --git a/libxfs/xfs_dir2_data.c b/libxfs/xfs_dir2_data.c index 0c9f529..b68c7ab 100644 --- a/libxfs/xfs_dir2_data.c +++ b/libxfs/xfs_dir2_data.c @@ -222,6 +222,7 @@ xfs_dir3_data_verify( return false; if (be64_to_cpu(hdr3->blkno) != bp->b_bn) return false; + xfs_detect_invalid_lsn(mp, be64_to_cpu(hdr3->lsn)); } else { if (hdr3->magic != cpu_to_be32(XFS_DIR2_DATA_MAGIC)) return false; diff --git a/libxfs/xfs_dir2_leaf.c b/libxfs/xfs_dir2_leaf.c index 80d03b3..e2dac37 100644 --- a/libxfs/xfs_dir2_leaf.c +++ b/libxfs/xfs_dir2_leaf.c @@ -162,6 +162,7 @@ xfs_dir3_leaf_verify( return false; if (be64_to_cpu(leaf3->info.blkno) != bp->b_bn) return false; + xfs_detect_invalid_lsn(mp, be64_to_cpu(leaf3->info.lsn)); } else { if (leaf->hdr.info.magic != cpu_to_be16(magic)) return false; diff --git a/libxfs/xfs_dir2_node.c b/libxfs/xfs_dir2_node.c index 0514cea..5328859 100644 --- a/libxfs/xfs_dir2_node.c +++ b/libxfs/xfs_dir2_node.c @@ -95,6 +95,7 @@ xfs_dir3_free_verify( return false; if (be64_to_cpu(hdr3->blkno) != bp->b_bn) return false; + xfs_detect_invalid_lsn(mp, be64_to_cpu(hdr3->lsn)); } else { if (hdr->magic != cpu_to_be32(XFS_DIR2_FREE_MAGIC)) return false; diff --git a/libxfs/xfs_ialloc.c b/libxfs/xfs_ialloc.c index 93bfaea..a9b0e4a 100644 --- a/libxfs/xfs_ialloc.c +++ b/libxfs/xfs_ialloc.c @@ -2495,9 +2495,13 @@ xfs_agi_verify( struct xfs_mount *mp = bp->b_target->bt_mount; struct xfs_agi *agi = XFS_BUF_TO_AGI(bp); - if (xfs_sb_version_hascrc(&mp->m_sb) && - !uuid_equal(&agi->agi_uuid, &mp->m_sb.sb_meta_uuid)) + if (xfs_sb_version_hascrc(&mp->m_sb)) { + if (!uuid_equal(&agi->agi_uuid, &mp->m_sb.sb_meta_uuid)) return false; + xfs_detect_invalid_lsn(mp, + be64_to_cpu(XFS_BUF_TO_AGI(bp)->agi_lsn)); + } + /* * Validate the magic number of the agi block. */ diff --git a/libxfs/xfs_sb.c b/libxfs/xfs_sb.c index f944a58..5fe892d 100644 --- a/libxfs/xfs_sb.c +++ b/libxfs/xfs_sb.c @@ -161,6 +161,14 @@ xfs_mount_validate_sb( "Filesystem can not be safely mounted by this kernel."); return -EINVAL; } + } else if (xfs_sb_version_hascrc(sbp)) { + /* + * We can't read verify the sb LSN because the read verifier is + * called before the log is allocated and processed. We know the + * log is set up before write verifier (!check_version) calls, + * so just check it here. + */ + xfs_detect_invalid_lsn(mp, sbp->sb_lsn); } if (xfs_sb_version_has_pquotino(sbp)) { diff --git a/libxfs/xfs_symlink_remote.c b/libxfs/xfs_symlink_remote.c index 7d46d9e..364329a 100644 --- a/libxfs/xfs_symlink_remote.c +++ b/libxfs/xfs_symlink_remote.c @@ -57,6 +57,7 @@ xfs_symlink_hdr_set( if (!xfs_sb_version_hascrc(&mp->m_sb)) return 0; + memset(dsl, 0, sizeof(struct xfs_dsymlink_hdr)); dsl->sl_magic = cpu_to_be32(XFS_SYMLINK_MAGIC); dsl->sl_offset = cpu_to_be32(offset); dsl->sl_bytes = cpu_to_be32(size); @@ -114,6 +115,8 @@ xfs_symlink_verify( if (dsl->sl_owner == 0) return false; + xfs_detect_invalid_lsn(mp, be64_to_cpu(dsl->sl_lsn)); + return true; } -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:46 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 7DA5C7F55 for ; Fri, 11 Sep 2015 13:55:46 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 6DD5E30404E for ; Fri, 11 Sep 2015 11:55:46 -0700 (PDT) X-ASG-Debug-ID: 1441997744-04cb6c355b6fca0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id oD37qqY9vhNSoQ4m (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 899FC550CC for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BItib2014601 for ; Fri, 11 Sep 2015 14:55:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id A5B16122E0A; Fri, 11 Sep 2015 14:55:42 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 05/12] libxfs: add ability to clear log to arbitrary log cycle Date: Fri, 11 Sep 2015 14:55:35 -0400 X-ASG-Orig-Subj: [PATCH v2 05/12] libxfs: add ability to clear log to arbitrary log cycle Message-Id: <1441997742-37160-6-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com> References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> 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: 1441997744 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 The libxfs_log_clear() helper currently zeroes the log and writes a single log record such that the kernel code detects the log has been zeroed and mounts successfully. This is not sufficient for v5 filesystems, which must have the log cleared to an LSN that is guaranteed to be ahead of any LSN that has been previously stamped into on-disk metadata. Update libxfs_log_clear() to support the ability to format the log to an arbitrary cycle number. First, the log is physically zeroed. A log record is written to the first block of the log with the desired lsn and refers to the tail_lsn as the last record of the previous cycle. The rest of the log is filled with log records of the previous cycle. This causes the kernel to set the current LSN to start of the desired cycle number at mount time. Signed-off-by: Brian Foster --- libxfs/rdwr.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 61 insertions(+), 6 deletions(-) diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c index c64dba0..d87baec 100644 --- a/libxfs/rdwr.c +++ b/libxfs/rdwr.c @@ -155,26 +155,81 @@ libxfs_log_clear( xfs_buf_t *bp; int len; xfs_lsn_t lsn; + xfs_lsn_t tail_lsn; + xfs_daddr_t blk; + xfs_daddr_t end_blk; if (!btp->dev || !fs_uuid) return -EINVAL; - if (cycle != XLOG_INIT_CYCLE) + if (cycle < XLOG_INIT_CYCLE) return -EINVAL; - lsn = xlog_assign_lsn(cycle, 0); - /* first zero the log */ libxfs_device_zero(btp, start, length); - /* then write a log record header */ + /* + * Initialize the log record length and LSNs. XLOG_INIT_CYCLE is a + * special reset case where we only write a single record where the lsn + * and tail_lsn match. Otherwise, the record lsn starts at block 0 of + * the specified cycle and points tail_lsn at the last record of the + * previous cycle. + */ len = ((version == 2) && sunit) ? BTOBB(sunit) : 2; len = MAX(len, 2); + lsn = xlog_assign_lsn(cycle, 0); + if (cycle == XLOG_INIT_CYCLE) + tail_lsn = lsn; + else + tail_lsn = xlog_assign_lsn(cycle - 1, length - len); + + /* write out the first log record */ bp = libxfs_getbufr(btp, start, len); - libxfs_log_header(XFS_BUF_PTR(bp), fs_uuid, version, sunit, fmt, lsn, - lsn, next, bp); + libxfs_log_header(XFS_BUF_PTR(bp), fs_uuid, version, sunit, fmt, + lsn, tail_lsn, next, bp); bp->b_flags |= LIBXFS_B_DIRTY; libxfs_putbufr(bp); + + /* + * There's nothing else to do if this is a log reset. The kernel detects + * the rest of the log is zeroed and starts at cycle 1. + */ + if (cycle == XLOG_INIT_CYCLE) + return 0; + + /* + * Otherwise, fill everything beyond the initial record with records of + * the previous cycle so the kernel head/tail detection works correctly. + * + * We don't particularly care about the record size or content here. + * It's only important that the headers are in place such that the + * kernel finds 1.) a clean log and 2.) the correct current cycle value. + * Therefore, bump up the record size to the max to use larger I/Os and + * improve performance. + */ + cycle--; + blk = start + len; + end_blk = start + length; + + len = min(end_blk - blk, BTOBB(BDSTRAT_SIZE)); + while (blk < end_blk) { + lsn = xlog_assign_lsn(cycle, blk - start); + tail_lsn = xlog_assign_lsn(cycle, blk - start - len); + + bp = libxfs_getbufr(btp, blk, len); + /* + * Note: pass the full buffer length as the sunit to initialize + * the entire buffer. + */ + libxfs_log_header(XFS_BUF_PTR(bp), fs_uuid, version, BBTOB(len), + fmt, lsn, tail_lsn, next, bp); + bp->b_flags |= LIBXFS_B_DIRTY; + libxfs_putbufr(bp); + + len = min(end_blk - blk, BTOBB(BDSTRAT_SIZE)); + blk += len; + } + return 0; } -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:46 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 73E957F51 for ; Fri, 11 Sep 2015 13:55:46 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 63DCC8F8050 for ; Fri, 11 Sep 2015 11:55:46 -0700 (PDT) X-ASG-Debug-ID: 1441997744-04cb6c355c6fcb0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id rTQykykHygP60U7A (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id B5E4091E8D for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BItiem027222 for ; Fri, 11 Sep 2015 14:55:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 029FB124909; Fri, 11 Sep 2015 14:55:43 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 11/12] xfs_db: do not reset current lsn from uuid command on v5 supers Date: Fri, 11 Sep 2015 14:55:41 -0400 X-ASG-Orig-Subj: [PATCH v2 11/12] xfs_db: do not reset current lsn from uuid command on v5 supers Message-Id: <1441997742-37160-12-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com> References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> 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: 1441997745 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 The xfs_db uuid command modifes the uuid of the filesystem. As part of this process, it is required to clear the log and format it with records that use the new uuid. It currently resets the log to cycle 1, which is not safe for v5 superblocks. Update the uuid log clearing implementation to bump the current cycle when the log is formatted on v5 superblock filesystems. This ensures that the current LSN remains ahead of metadata LSNs on the subsequent mount. Since the log is checked and cleared across a couple different functions, also add a new global xlog structure, associate it with the preexisting global mount structure and reference it to get and use the current log cycle. Signed-off-by: Brian Foster --- db/init.c | 25 ++++++++++++++----------- db/sb.c | 19 +++++++++++++++---- 2 files changed, 29 insertions(+), 15 deletions(-) diff --git a/db/init.c b/db/init.c index 9537a38..c0472c8 100644 --- a/db/init.c +++ b/db/init.c @@ -17,6 +17,7 @@ */ #include "libxfs.h" +#include "libxlog.h" #include #include "command.h" #include "init.h" @@ -28,17 +29,18 @@ #include "malloc.h" #include "type.h" -static char **cmdline; -static int ncmdline; -char *fsdevice; -int blkbb; -int exitcode; -int expert_mode; -int force; -xfs_mount_t xmount; -xfs_mount_t *mp; -libxfs_init_t x; -xfs_agnumber_t cur_agno = NULLAGNUMBER; +static char **cmdline; +static int ncmdline; +char *fsdevice; +int blkbb; +int exitcode; +int expert_mode; +int force; +struct xfs_mount xmount; +struct xfs_mount *mp; +struct xlog xlog; +libxfs_init_t x; +xfs_agnumber_t cur_agno = NULLAGNUMBER; static void usage(void) @@ -154,6 +156,7 @@ init( progname, fsdevice); exit(1); } + mp->m_log = &xlog; blkbb = 1 << mp->m_blkbb_log; /* diff --git a/db/sb.c b/db/sb.c index 9c585ca..30c622d 100644 --- a/db/sb.c +++ b/db/sb.c @@ -229,7 +229,6 @@ int xlog_recover_do_trans(struct xlog *log, xlog_recover_t *t, int p) int sb_logcheck(void) { - struct xlog log; int dirty; if (mp->m_sb.sb_logstart) { @@ -248,7 +247,7 @@ sb_logcheck(void) libxfs_buftarg_init(mp, x.ddev, x.logdev, x.rtdev); - dirty = xlog_is_dirty(mp, &log, &x, 0); + dirty = xlog_is_dirty(mp, mp->m_log, &x, 0); if (dirty == -1) { dbprintf(_("ERROR: cannot find log head/tail, run xfs_repair\n")); return 0; @@ -269,20 +268,32 @@ sb_logcheck(void) static int sb_logzero(uuid_t *uuidp) { + int cycle = XLOG_INIT_CYCLE; + int error; + if (!sb_logcheck()) return 0; + /* + * The log must always move forward on v5 superblocks. Bump it to the + * next cycle. + */ + if (xfs_sb_version_hascrc(&mp->m_sb)) + cycle = mp->m_log->l_curr_cycle + 1; + dbprintf(_("Clearing log and setting UUID\n")); - if (libxfs_log_clear(mp->m_logdev_targp, + error = libxfs_log_clear(mp->m_logdev_targp, XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart), (xfs_extlen_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks), uuidp, xfs_sb_version_haslogv2(&mp->m_sb) ? 2 : 1, - mp->m_sb.sb_logsunit, XLOG_FMT, XLOG_INIT_CYCLE)) { + mp->m_sb.sb_logsunit, XLOG_FMT, cycle); + if (error) { dbprintf(_("ERROR: cannot clear the log\n")); return 0; } + return 1; } -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:47 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 9EF757F58 for ; Fri, 11 Sep 2015 13:55:46 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 8DC6730404E for ; Fri, 11 Sep 2015 11:55:46 -0700 (PDT) X-ASG-Debug-ID: 1441997745-04cb6c355b6fcb0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id I2BjGqUB6J3hwDq8 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id EA2DA8E690 for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BItiQt014640 for ; Fri, 11 Sep 2015 14:55:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id ECE7C1248FD; Fri, 11 Sep 2015 14:55:42 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 09/12] xfs_repair: format the log with forward cycle number on v5 supers Date: Fri, 11 Sep 2015 14:55:39 -0400 X-ASG-Orig-Subj: [PATCH v2 09/12] xfs_repair: format the log with forward cycle number on v5 supers Message-Id: <1441997742-37160-10-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com> References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> 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: 1441997745 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 v5 filesystems use the current LSN and the last modified LSN stored within fs metadata to provide correct log recovery ordering. xfs_repair historically clears the log in phase 2. This resets to the current LSN of the filesystem to the initial cycle, as if the fs was just created. This is problematic because the filesystem LSN is now behind many pre-existing metadata structures on-disk until either the current filesystem LSN catches up or those particular data structures are modified and written out. If a filesystem crash occurs in the meantime, log recovery can incorrectly skip log items and cause filesystem corruption. Update xfs_repair to check the maximum metadata LSN value against the current log state once the filesystem has been processed. If the maximum LSN exceeds the current LSN with respect to the log, reformat the log with a cycle number that exceeds that of the maximum LSN. Signed-off-by: Brian Foster --- repair/xfs_repair.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 68 insertions(+), 2 deletions(-) diff --git a/repair/xfs_repair.c b/repair/xfs_repair.c index 0e80124..8285d9d 100644 --- a/repair/xfs_repair.c +++ b/repair/xfs_repair.c @@ -531,6 +531,63 @@ _("sb realtime summary inode %" PRIu64 " %sinconsistent with calculated value %u } +/* + * v5 superblock metadata track the LSN of last modification and thus require + * that the current LSN is always moving forward. The current LSN is reset if + * the log has been cleared, which puts the log behind parts of the filesystem + * on-disk and can disrupt log recovery. + * + * We have tracked the maximum LSN of every piece of metadata that has been read + * in via the read verifiers. Compare the max LSN with the log and if the log is + * behind, bump the cycle number and reformat the log. + */ +static void +format_log_max_lsn( + struct xfs_mount *mp) +{ + struct xlog *log = mp->m_log; + int max_cycle; + int max_block; + int new_cycle; + xfs_daddr_t logstart; + xfs_daddr_t logblocks; + int logversion; + + if (!xfs_sb_version_hascrc(&mp->m_sb)) + return; + + /* + * If the log is ahead of the highest metadata LSN we've seen, we're + * safe and there's nothing to do. + */ + max_cycle = CYCLE_LSN(libxfs_max_lsn); + max_block = BLOCK_LSN(libxfs_max_lsn); + if (max_cycle < log->l_curr_cycle || + (max_cycle == log->l_curr_cycle && max_block < log->l_curr_block)) + return; + + /* + * Going to the next cycle should be sufficient but we bump by a few + * counts to help cover any metadata LSNs we could have missed. + */ + new_cycle = max_cycle + 3; + logstart = XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart); + logblocks = XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks); + logversion = xfs_sb_version_haslogv2(&mp->m_sb) ? 2 : 1; + + do_warn(_("Maximum metadata LSN (%d:%d) is ahead of log (%d:%d).\n"), + max_cycle, max_block, log->l_curr_cycle, log->l_curr_block); + + if (no_modify) { + do_warn(_("Would format log to cycle %d.\n"), new_cycle); + return; + } + + do_warn(_("Format log to cycle %d.\n"), new_cycle); + libxfs_log_clear(log->l_dev, logstart, logblocks, &mp->m_sb.sb_uuid, + logversion, mp->m_sb.sb_logsunit, XLOG_FMT, new_cycle); +} + int main(int argc, char **argv) { @@ -896,6 +953,12 @@ _("Warning: project quota information would be cleared.\n" stop_progress_rpt(); if (no_modify) { + /* + * Warn if the current LSN is problematic and the log requires a + * reformat. + */ + format_log_max_lsn(mp); + do_log( _("No modify flag set, skipping filesystem flush and exiting.\n")); if (verbose) @@ -931,11 +994,14 @@ _("Note - stripe unit (%d) and width (%d) were copied from a backup superblock.\ libxfs_writebuf(sbp, 0); /* - * Done, flush all cached buffers and inodes. + * Done. Flush all cached buffers and inodes first to ensure all + * verifiers are run (where we discover the max metadata LSN), reformat + * the log if necessary and unmount. */ libxfs_bcache_flush(); - + format_log_max_lsn(mp); libxfs_umount(mp); + if (x.rtdev) libxfs_device_close(x.rtdev); if (x.logdev && x.logdev != x.ddev) -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:47 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 7C4CE7F54 for ; Fri, 11 Sep 2015 13:55:46 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 27944AC007 for ; Fri, 11 Sep 2015 11:55:46 -0700 (PDT) X-ASG-Debug-ID: 1441997745-04bdf04db676dc0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id qJguXnA8dHwRhBJw (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id EC0D5A7569 for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BItimF014643 for ; Fri, 11 Sep 2015 14:55:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 0F0E31236D9; Fri, 11 Sep 2015 14:55:42 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 10/12] xfs_repair: don't clear the log by default Date: Fri, 11 Sep 2015 14:55:40 -0400 X-ASG-Orig-Subj: [PATCH v2 10/12] xfs_repair: don't clear the log by default Message-Id: <1441997742-37160-11-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com> References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> 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: 1441997745 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 xfs_repair currently clears the log regardless of whether it is corrupted, clean or contains data. This is traditionally harmless but now causes log recovery problems on v5 filesystems. v5 filesystems expect a clean log to always have an LSN out ahead of the maximum last modification LSN stamped on any bit of metadata throughout the fs. If this is not the case, repair must reformat the log with a larger cycle number after fs processing is complete. Given that unconditional log clearing actually introduces a filesystem inconsistency on v5 superblocks (that repair must subsequently recover from) and provides no tangible benefit for v4 filesystems that otherwise have a clean and covered log, it is more appropriate behavior to not clear the log by default. Update xfs_repair to always and only clear the log when the -L parameter is specified. Retain the existing logic to require -L or otherwise exit if the log appears to contain data. Adopt similar behavior if the log appears to be corrupted. Signed-off-by: Brian Foster --- repair/phase2.c | 60 ++++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 40 insertions(+), 20 deletions(-) diff --git a/repair/phase2.c b/repair/phase2.c index 72132ce..fe7ed2b 100644 --- a/repair/phase2.c +++ b/repair/phase2.c @@ -36,11 +36,13 @@ int xlog_recover_do_trans(struct xlog *log, xlog_recover_t *t, int p) } static void -zero_log(xfs_mount_t *mp) +zero_log( + struct xfs_mount *mp) { - int error; - xfs_daddr_t head_blk, tail_blk; - struct xlog *log = mp->m_log; + int error; + xfs_daddr_t head_blk; + xfs_daddr_t tail_blk; + struct xlog *log = mp->m_log; memset(log, 0, sizeof(struct xlog)); x.logBBsize = XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks); @@ -65,10 +67,22 @@ zero_log(xfs_mount_t *mp) } log->l_sectbb_mask = (1 << log->l_sectbb_log) - 1; - if ((error = xlog_find_tail(log, &head_blk, &tail_blk))) { - do_warn(_("zero_log: cannot find log head/tail " - "(xlog_find_tail=%d), zeroing it anyway\n"), + /* + * Find the log head and tail and alert the user to the situation if the + * log appears corrupted or contains data. In either case, we do not + * proceed past this point unless the user explicitly requests to zap + * the log. + */ + error = xlog_find_tail(log, &head_blk, &tail_blk); + if (error) { + do_warn( + _("zero_log: cannot find log head/tail (xlog_find_tail=%d)\n"), error); + if (!no_modify && !zap_log) + do_error(_( +"ERROR: The log head and/or tail cannot be discovered. Attempt to mount the\n" +"filesystem to replay the log or use the -L option to destroy the log and\n" +"attempt a repair.\n")); } else { if (verbose) { do_warn( @@ -93,19 +107,25 @@ zero_log(xfs_mount_t *mp) } } - if (no_modify) - return; - - libxfs_log_clear(log->l_dev, XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart), - (xfs_extlen_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks), - &mp->m_sb.sb_uuid, - xfs_sb_version_haslogv2(&mp->m_sb) ? 2 : 1, - mp->m_sb.sb_logsunit, XLOG_FMT, XLOG_INIT_CYCLE); - - /* update the log data structure with new state */ - error = xlog_find_tail(log, &head_blk, &tail_blk); - if (error || head_blk != tail_blk) - do_error(_("failed to clear log")); + /* + * Only clear the log when explicitly requested. Doing so is unnecessary + * unless something is wrong. Further, this resets the current LSN of + * the filesystem and creates more work for repair of v5 superblock + * filesystems. + */ + if (!no_modify && zap_log) { + libxfs_log_clear(log->l_dev, + XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart), + (xfs_extlen_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks), + &mp->m_sb.sb_uuid, + xfs_sb_version_haslogv2(&mp->m_sb) ? 2 : 1, + mp->m_sb.sb_logsunit, XLOG_FMT, XLOG_INIT_CYCLE); + + /* update the log data structure with new state */ + error = xlog_find_tail(log, &head_blk, &tail_blk); + if (error || head_blk != tail_blk) + do_error(_("failed to clear log")); + } } /* -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:47 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id E721F7F50 for ; Fri, 11 Sep 2015 13:55:46 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id BA24830404E for ; Fri, 11 Sep 2015 11:55:46 -0700 (PDT) X-ASG-Debug-ID: 1441997744-04bdf04db376db0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id w7jcQi1fy0EsRLyQ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id D234C2620 for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BItiCQ020251 for ; Fri, 11 Sep 2015 14:55:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 1D86E124917; Fri, 11 Sep 2015 14:55:43 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 12/12] db/metadump: bump lsn when log is cleared on v5 supers Date: Fri, 11 Sep 2015 14:55:42 -0400 X-ASG-Orig-Subj: [PATCH v2 12/12] db/metadump: bump lsn when log is cleared on v5 supers Message-Id: <1441997742-37160-13-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com> References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441997745 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 xfs_metadump handles the log in different ways depending on the mode of operation. If the log is dirty or obfuscation and stale data zeroing are disabled, the log is copied as is. In all other scenarios, the log is explicitly zeroed. This is incorrect for version 5 superblocks where the current LSN is always expected to be ahead of all fs metadata. Update metadump to use libxfs_log_clear() to format the log with an elevated LSN rather than zero the log and reset the current the LSN. Metadump does not use buffers for the dump target, instead using a cursor implementation to access the log via a single memory buffer. Therefore, update libxfs_log_clear() to receive an optional (but exclusive to the buftarg parameter) memory buffer pointer for the log. If the pointer is provided, the log format is written out to this buffer. Otherwise, fall back to the original behavior and access the log through buftarg buffers. Signed-off-by: Brian Foster --- db/metadump.c | 16 +++++++++++-- db/sb.c | 2 +- include/libxfs.h | 4 ++-- libxfs/rdwr.c | 68 +++++++++++++++++++++++++++++++++++++++-------------- mkfs/xfs_mkfs.c | 2 +- repair/phase2.c | 2 +- repair/xfs_repair.c | 5 ++-- 7 files changed, 72 insertions(+), 27 deletions(-) diff --git a/db/metadump.c b/db/metadump.c index 129670e..56b733e 100644 --- a/db/metadump.c +++ b/db/metadump.c @@ -2514,6 +2514,10 @@ copy_log(void) { struct xlog log; int dirty; + xfs_daddr_t logstart; + int logblocks; + int logversion; + int cycle = XLOG_INIT_CYCLE; if (show_progress) print_progress("Copying log"); @@ -2538,8 +2542,16 @@ copy_log(void) /* clear out a clean log */ if (show_progress) print_progress("Zeroing clean log"); - memset(iocur_top->data, 0, - mp->m_sb.sb_logblocks * mp->m_sb.sb_blocksize); + + logstart = XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart); + logblocks = XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks); + logversion = xfs_sb_version_haslogv2(&mp->m_sb) ? 2 : 1; + if (xfs_sb_version_hascrc(&mp->m_sb)) + cycle = log.l_curr_cycle + 1; + + libxfs_log_clear(NULL, iocur_top->data, logstart, logblocks, + &mp->m_sb.sb_uuid, logversion, + mp->m_sb.sb_logsunit, XLOG_FMT, cycle); break; case 1: /* keep the dirty log */ diff --git a/db/sb.c b/db/sb.c index 30c622d..17d446c 100644 --- a/db/sb.c +++ b/db/sb.c @@ -283,7 +283,7 @@ sb_logzero(uuid_t *uuidp) dbprintf(_("Clearing log and setting UUID\n")); - error = libxfs_log_clear(mp->m_logdev_targp, + error = libxfs_log_clear(mp->m_logdev_targp, NULL, XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart), (xfs_extlen_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks), uuidp, diff --git a/include/libxfs.h b/include/libxfs.h index 6c87934..f733c36 100644 --- a/include/libxfs.h +++ b/include/libxfs.h @@ -153,8 +153,8 @@ typedef char *(libxfs_get_block_t)(char *, int, void *); * Helpers to clear the log to a particular log cycle. */ #define XLOG_INIT_CYCLE 1 -extern int libxfs_log_clear(struct xfs_buftarg *, xfs_daddr_t, uint, - uuid_t *, int, int, int, int); +extern int libxfs_log_clear(struct xfs_buftarg *, char *, xfs_daddr_t, + uint, uuid_t *, int, int, int, int); extern int libxfs_log_header(char *, uuid_t *, int, int, int, xfs_lsn_t, xfs_lsn_t, libxfs_get_block_t *, void *); diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c index d87baec..a4cc3f4 100644 --- a/libxfs/rdwr.c +++ b/libxfs/rdwr.c @@ -132,41 +132,57 @@ static void unmount_record(void *p) memcpy((char *)p + sizeof(xlog_op_header_t), &magic, sizeof(magic)); } -static char *next(char *ptr, int offset, void *private) +static char *next( + char *ptr, + int offset, + void *private) { - xfs_buf_t *buf = (xfs_buf_t *)private; + struct xfs_buf *buf = (struct xfs_buf *)private; - if (XFS_BUF_COUNT(buf) < (int)(ptr - XFS_BUF_PTR(buf)) + offset) + if (buf && + (XFS_BUF_COUNT(buf) < (int)(ptr - XFS_BUF_PTR(buf)) + offset)) abort(); + return ptr + offset; } +/* + * Format the log. The caller provides either a buftarg which is used to access + * the log via buffers or a direct pointer to a buffer that encapsulates the + * entire log. + */ int libxfs_log_clear( struct xfs_buftarg *btp, + char *dptr, xfs_daddr_t start, - uint length, + uint length, /* basic blocks */ uuid_t *fs_uuid, int version, - int sunit, + int sunit, /* bytes */ int fmt, int cycle) { - xfs_buf_t *bp; + struct xfs_buf *bp = NULL; int len; xfs_lsn_t lsn; xfs_lsn_t tail_lsn; xfs_daddr_t blk; xfs_daddr_t end_blk; + char *ptr; - if (!btp->dev || !fs_uuid) + if (((btp && dptr) || (!btp && !dptr)) || + (btp && !btp->dev) || !fs_uuid) return -EINVAL; if (cycle < XLOG_INIT_CYCLE) return -EINVAL; /* first zero the log */ - libxfs_device_zero(btp, start, length); + if (btp) + libxfs_device_zero(btp, start, length); + else + memset(dptr, 0, BBTOB(length)); /* * Initialize the log record length and LSNs. XLOG_INIT_CYCLE is a @@ -184,11 +200,17 @@ libxfs_log_clear( tail_lsn = xlog_assign_lsn(cycle - 1, length - len); /* write out the first log record */ - bp = libxfs_getbufr(btp, start, len); - libxfs_log_header(XFS_BUF_PTR(bp), fs_uuid, version, sunit, fmt, - lsn, tail_lsn, next, bp); - bp->b_flags |= LIBXFS_B_DIRTY; - libxfs_putbufr(bp); + ptr = dptr; + if (btp) { + bp = libxfs_getbufr(btp, start, len); + ptr = XFS_BUF_PTR(bp); + } + libxfs_log_header(ptr, fs_uuid, version, sunit, fmt, lsn, tail_lsn, + next, bp); + if (bp) { + bp->b_flags |= LIBXFS_B_DIRTY; + libxfs_putbufr(bp); + } /* * There's nothing else to do if this is a log reset. The kernel detects @@ -209,6 +231,8 @@ libxfs_log_clear( */ cycle--; blk = start + len; + if (dptr) + dptr += BBTOB(len); end_blk = start + length; len = min(end_blk - blk, BTOBB(BDSTRAT_SIZE)); @@ -216,18 +240,26 @@ libxfs_log_clear( lsn = xlog_assign_lsn(cycle, blk - start); tail_lsn = xlog_assign_lsn(cycle, blk - start - len); - bp = libxfs_getbufr(btp, blk, len); + ptr = dptr; + if (btp) { + bp = libxfs_getbufr(btp, blk, len); + ptr = XFS_BUF_PTR(bp); + } /* * Note: pass the full buffer length as the sunit to initialize * the entire buffer. */ - libxfs_log_header(XFS_BUF_PTR(bp), fs_uuid, version, BBTOB(len), - fmt, lsn, tail_lsn, next, bp); - bp->b_flags |= LIBXFS_B_DIRTY; - libxfs_putbufr(bp); + libxfs_log_header(ptr, fs_uuid, version, BBTOB(len), fmt, lsn, + tail_lsn, next, bp); + if (bp) { + bp->b_flags |= LIBXFS_B_DIRTY; + libxfs_putbufr(bp); + } len = min(end_blk - blk, BTOBB(BDSTRAT_SIZE)); blk += len; + if (dptr) + dptr += BBTOB(len); } return 0; diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c index 238d400..5f939b5 100644 --- a/mkfs/xfs_mkfs.c +++ b/mkfs/xfs_mkfs.c @@ -2667,7 +2667,7 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"), /* * Zero the log.... */ - libxfs_log_clear(mp->m_logdev_targp, + libxfs_log_clear(mp->m_logdev_targp, NULL, XFS_FSB_TO_DADDR(mp, logstart), (xfs_extlen_t)XFS_FSB_TO_BB(mp, logblocks), &sbp->sb_uuid, logversion, lsunit, XLOG_FMT, XLOG_INIT_CYCLE); diff --git a/repair/phase2.c b/repair/phase2.c index fe7ed2b..e26e2fc 100644 --- a/repair/phase2.c +++ b/repair/phase2.c @@ -114,7 +114,7 @@ zero_log( * filesystems. */ if (!no_modify && zap_log) { - libxfs_log_clear(log->l_dev, + libxfs_log_clear(log->l_dev, NULL, XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart), (xfs_extlen_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks), &mp->m_sb.sb_uuid, diff --git a/repair/xfs_repair.c b/repair/xfs_repair.c index 8285d9d..bed2ff5 100644 --- a/repair/xfs_repair.c +++ b/repair/xfs_repair.c @@ -584,8 +584,9 @@ format_log_max_lsn( } do_warn(_("Format log to cycle %d.\n"), new_cycle); - libxfs_log_clear(log->l_dev, logstart, logblocks, &mp->m_sb.sb_uuid, - logversion, mp->m_sb.sb_logsunit, XLOG_FMT, new_cycle); + libxfs_log_clear(log->l_dev, NULL, logstart, logblocks, + &mp->m_sb.sb_uuid, logversion, mp->m_sb.sb_logsunit, + XLOG_FMT, new_cycle); } int -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id F29E77F59 for ; Fri, 11 Sep 2015 13:55:46 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id D408A304039 for ; Fri, 11 Sep 2015 11:55:46 -0700 (PDT) X-ASG-Debug-ID: 1441997744-04cbb005ec77510001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Bl3BRwPCE7Haqwup (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id D38A2C0BB24F for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BItiJk014634 for ; Fri, 11 Sep 2015 14:55:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id B7EB31248A9; Fri, 11 Sep 2015 14:55:42 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 04/12] libxfs: pass lsn param to log clear and record header logging helpers Date: Fri, 11 Sep 2015 14:55:34 -0400 X-ASG-Orig-Subj: [PATCH v2 04/12] libxfs: pass lsn param to log clear and record header logging helpers Message-Id: <1441997742-37160-5-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com> References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> 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: 1441997745 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 In preparation to support the ability to format the log with an arbitrary cycle number, the log clear and record logging helpers must be updated to receive the desired cycle and LSN values as parameters. Update libxfs_log_clear() to receive the desired cycle number to format the log with. Define a preprocessor directive to represent the currently hardcoded case of cycle 1. Update libxfs_log_header() to receive the lsn and tail_lsn of the record to write. Use a NULL value LSN to represent the currently hardcoded behavior. All callers are updated to use the current default values. As such, this patch does not change behavior in any way. Signed-off-by: Brian Foster --- copy/xfs_copy.c | 4 ++-- db/sb.c | 2 +- include/libxfs.h | 12 ++++++++---- libxfs/rdwr.c | 26 ++++++++++++++++++++------ mkfs/xfs_mkfs.c | 2 +- repair/phase2.c | 2 +- 6 files changed, 33 insertions(+), 15 deletions(-) diff --git a/copy/xfs_copy.c b/copy/xfs_copy.c index 2f4f5cb..949be5f 100644 --- a/copy/xfs_copy.c +++ b/copy/xfs_copy.c @@ -1212,8 +1212,8 @@ write_log_header(int fd, wbuf *buf, xfs_mount_t *mp) offset = libxfs_log_header(p, &buf->owner->uuid, xfs_sb_version_haslogv2(&mp->m_sb) ? 2 : 1, - mp->m_sb.sb_logsunit, XLOG_FMT, - next_log_chunk, buf); + mp->m_sb.sb_logsunit, XLOG_FMT, NULLCOMMITLSN, + NULLCOMMITLSN, next_log_chunk, buf); do_write(buf->owner); return roundup(logstart + offset, buf->length); diff --git a/db/sb.c b/db/sb.c index 598e787..560e653 100644 --- a/db/sb.c +++ b/db/sb.c @@ -278,7 +278,7 @@ sb_logzero(uuid_t *uuidp) (xfs_extlen_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks), uuidp, xfs_sb_version_haslogv2(&mp->m_sb) ? 2 : 1, - mp->m_sb.sb_logsunit, XLOG_FMT)) { + mp->m_sb.sb_logsunit, XLOG_FMT, XLOG_INIT_CYCLE)) { dbprintf(_("ERROR: cannot clear the log\n")); return 0; } diff --git a/include/libxfs.h b/include/libxfs.h index cc06fc6..6c87934 100644 --- a/include/libxfs.h +++ b/include/libxfs.h @@ -149,10 +149,14 @@ extern int platform_nproc(void); /* check or write log footer: specify device, log size in blocks & uuid */ typedef char *(libxfs_get_block_t)(char *, int, void *); -extern int libxfs_log_clear (struct xfs_buftarg *, xfs_daddr_t, uint, - uuid_t *, int, int, int); -extern int libxfs_log_header (char *, uuid_t *, int, int, int, - libxfs_get_block_t *, void *); +/* + * Helpers to clear the log to a particular log cycle. + */ +#define XLOG_INIT_CYCLE 1 +extern int libxfs_log_clear(struct xfs_buftarg *, xfs_daddr_t, uint, + uuid_t *, int, int, int, int); +extern int libxfs_log_header(char *, uuid_t *, int, int, int, xfs_lsn_t, + xfs_lsn_t, libxfs_get_block_t *, void *); /* Shared utility routines */ diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c index ef18749..c64dba0 100644 --- a/libxfs/rdwr.c +++ b/libxfs/rdwr.c @@ -149,14 +149,21 @@ libxfs_log_clear( uuid_t *fs_uuid, int version, int sunit, - int fmt) + int fmt, + int cycle) { xfs_buf_t *bp; int len; + xfs_lsn_t lsn; if (!btp->dev || !fs_uuid) return -EINVAL; + if (cycle != XLOG_INIT_CYCLE) + return -EINVAL; + + lsn = xlog_assign_lsn(cycle, 0); + /* first zero the log */ libxfs_device_zero(btp, start, length); @@ -164,8 +171,8 @@ libxfs_log_clear( len = ((version == 2) && sunit) ? BTOBB(sunit) : 2; len = MAX(len, 2); bp = libxfs_getbufr(btp, start, len); - libxfs_log_header(XFS_BUF_PTR(bp), - fs_uuid, version, sunit, fmt, next, bp); + libxfs_log_header(XFS_BUF_PTR(bp), fs_uuid, version, sunit, fmt, lsn, + lsn, next, bp); bp->b_flags |= LIBXFS_B_DIRTY; libxfs_putbufr(bp); return 0; @@ -178,6 +185,8 @@ libxfs_log_header( int version, int sunit, int fmt, + xfs_lsn_t lsn, + xfs_lsn_t tail_lsn, libxfs_get_block_t *nextfunc, void *private) { @@ -186,11 +195,16 @@ libxfs_log_header( __be32 cycle_lsn; int i, len; + if (lsn == NULLCOMMITLSN) + lsn = xlog_assign_lsn(XLOG_INIT_CYCLE, 0); + if (tail_lsn == NULLCOMMITLSN) + tail_lsn = lsn; + len = ((version == 2) && sunit) ? BTOBB(sunit) : 1; memset(p, 0, BBSIZE); head->h_magicno = cpu_to_be32(XLOG_HEADER_MAGIC_NUM); - head->h_cycle = cpu_to_be32(1); + head->h_cycle = cpu_to_be32(CYCLE_LSN(lsn)); head->h_version = cpu_to_be32(version); if (len != 1) head->h_len = cpu_to_be32(sunit - BBSIZE); @@ -202,8 +216,8 @@ libxfs_log_header( head->h_fmt = cpu_to_be32(fmt); head->h_size = cpu_to_be32(XLOG_HEADER_CYCLE_SIZE); - head->h_lsn = cpu_to_be64(xlog_assign_lsn(1, 0)); - head->h_tail_lsn = cpu_to_be64(xlog_assign_lsn(1, 0)); + head->h_lsn = cpu_to_be64(lsn); + head->h_tail_lsn = cpu_to_be64(tail_lsn); memcpy(&head->h_fs_uuid, fs_uuid, sizeof(uuid_t)); diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c index d993fc0..238d400 100644 --- a/mkfs/xfs_mkfs.c +++ b/mkfs/xfs_mkfs.c @@ -2670,7 +2670,7 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"), libxfs_log_clear(mp->m_logdev_targp, XFS_FSB_TO_DADDR(mp, logstart), (xfs_extlen_t)XFS_FSB_TO_BB(mp, logblocks), - &sbp->sb_uuid, logversion, lsunit, XLOG_FMT); + &sbp->sb_uuid, logversion, lsunit, XLOG_FMT, XLOG_INIT_CYCLE); mp = libxfs_mount(mp, sbp, xi.ddev, xi.logdev, xi.rtdev, 0); if (mp == NULL) { diff --git a/repair/phase2.c b/repair/phase2.c index 7e264c4..0673a0c 100644 --- a/repair/phase2.c +++ b/repair/phase2.c @@ -98,7 +98,7 @@ zero_log(xfs_mount_t *mp) (xfs_extlen_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks), &mp->m_sb.sb_uuid, xfs_sb_version_haslogv2(&mp->m_sb) ? 2 : 1, - mp->m_sb.sb_logsunit, XLOG_FMT); + mp->m_sb.sb_logsunit, XLOG_FMT, XLOG_INIT_CYCLE); } /* -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 1D4A07F5E for ; Fri, 11 Sep 2015 13:55:47 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id F18888F8040 for ; Fri, 11 Sep 2015 11:55:46 -0700 (PDT) X-ASG-Debug-ID: 1441997744-04cbb005e977500001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id CLaRqGnL9eEMEhBk (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id BF489C0A1615 for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BItiso020246 for ; Fri, 11 Sep 2015 14:55:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id D13ED1248D6; Fri, 11 Sep 2015 14:55:42 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 06/12] libxlog: pull struct xlog out of xlog_is_dirty() Date: Fri, 11 Sep 2015 14:55:36 -0400 X-ASG-Orig-Subj: [PATCH v2 06/12] libxlog: pull struct xlog out of xlog_is_dirty() Message-Id: <1441997742-37160-7-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com> References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441997745 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 The xlog_is_dirty() helper is called in various places to acquire the current log head, tail and to determine whether the log is dirty. Some callers will require additional information to deal with formatting the log, such as the current LSN. xlog_is_dirty() already acquires this information through existing sub-helpers, but it is not available to callers as the xlog structure is allocated on the local stack. Update xlog_is_dirty() to receive the xlog structure as a parameter and pass it along such that additional information about the log is available to callers. Update the existing callers to allocate the xlog structure on the stack. Signed-off-by: Brian Foster --- db/metadump.c | 5 +++-- db/sb.c | 3 ++- include/libxlog.h | 3 ++- libxlog/util.c | 37 +++++++++++++++++++------------------ 4 files changed, 26 insertions(+), 22 deletions(-) diff --git a/db/metadump.c b/db/metadump.c index af96e12..129670e 100644 --- a/db/metadump.c +++ b/db/metadump.c @@ -2512,7 +2512,8 @@ copy_sb_inodes(void) static int copy_log(void) { - int dirty; + struct xlog log; + int dirty; if (show_progress) print_progress("Copying log"); @@ -2530,7 +2531,7 @@ copy_log(void) if (!obfuscate && !zero_stale_data) goto done; - dirty = xlog_is_dirty(mp, &x, 0); + dirty = xlog_is_dirty(mp, &log, &x, 0); switch (dirty) { case 0: diff --git a/db/sb.c b/db/sb.c index 560e653..9c585ca 100644 --- a/db/sb.c +++ b/db/sb.c @@ -229,6 +229,7 @@ int xlog_recover_do_trans(struct xlog *log, xlog_recover_t *t, int p) int sb_logcheck(void) { + struct xlog log; int dirty; if (mp->m_sb.sb_logstart) { @@ -247,7 +248,7 @@ sb_logcheck(void) libxfs_buftarg_init(mp, x.ddev, x.logdev, x.rtdev); - dirty = xlog_is_dirty(mp, &x, 0); + dirty = xlog_is_dirty(mp, &log, &x, 0); if (dirty == -1) { dbprintf(_("ERROR: cannot find log head/tail, run xfs_repair\n")); return 0; diff --git a/include/libxlog.h b/include/libxlog.h index 05b16e8..6c6e83a 100644 --- a/include/libxlog.h +++ b/include/libxlog.h @@ -84,7 +84,8 @@ extern int print_record_header; extern libxfs_init_t x; -extern int xlog_is_dirty(xfs_mount_t *mp, libxfs_init_t *x, int verbose); +extern int xlog_is_dirty(struct xfs_mount *, struct xlog *, libxfs_init_t *, + int); extern struct xfs_buf *xlog_get_bp(struct xlog *, int); extern void xlog_put_bp(struct xfs_buf *); extern int xlog_bread(struct xlog *log, xfs_daddr_t blk_no, int nbblks, diff --git a/libxlog/util.c b/libxlog/util.c index c6b8f2a..72b8b18 100644 --- a/libxlog/util.c +++ b/libxlog/util.c @@ -29,15 +29,15 @@ libxfs_init_t x; */ int xlog_is_dirty( - xfs_mount_t *mp, - libxfs_init_t *x, - int verbose) + struct xfs_mount *mp, + struct xlog *log, + libxfs_init_t *x, + int verbose) { - int error; - struct xlog log; - xfs_daddr_t head_blk, tail_blk; + int error; + xfs_daddr_t head_blk, tail_blk; - memset(&log, 0, sizeof(log)); + memset(log, 0, sizeof(*log)); /* We (re-)init members of libxfs_init_t here? really? */ x->logBBsize = XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks); @@ -46,23 +46,24 @@ xlog_is_dirty( if (xfs_sb_version_hassector(&mp->m_sb)) x->lbsize <<= (mp->m_sb.sb_logsectlog - BBSHIFT); - log.l_dev = mp->m_logdev_targp; - log.l_logBBsize = x->logBBsize; - log.l_logBBstart = x->logBBstart; - log.l_sectBBsize = BTOBB(x->lbsize); - log.l_mp = mp; + log->l_dev = mp->m_logdev_targp; + log->l_logBBsize = x->logBBsize; + log->l_logBBstart = x->logBBstart; + log->l_sectBBsize = BTOBB(x->lbsize); + log->l_mp = mp; if (xfs_sb_version_hassector(&mp->m_sb)) { - log.l_sectbb_log = mp->m_sb.sb_logsectlog - BBSHIFT; - ASSERT(log.l_sectbb_log <= mp->m_sectbb_log); + log->l_sectbb_log = mp->m_sb.sb_logsectlog - BBSHIFT; + ASSERT(log->l_sectbb_log <= mp->m_sectbb_log); /* for larger sector sizes, must have v2 or external log */ - ASSERT(log.l_sectbb_log == 0 || - log.l_logBBstart == 0 || + ASSERT(log->l_sectbb_log == 0 || + log->l_logBBstart == 0 || xfs_sb_version_haslogv2(&mp->m_sb)); ASSERT(mp->m_sb.sb_logsectlog >= BBSHIFT); } - log.l_sectbb_mask = (1 << log.l_sectbb_log) - 1; + log->l_sectbb_mask = (1 << log->l_sectbb_log) - 1; - if ((error = xlog_find_tail(&log, &head_blk, &tail_blk))) { + error = xlog_find_tail(log, &head_blk, &tail_blk); + if (error) { xlog_warn(_("%s: cannot find log head/tail " "(xlog_find_tail=%d)\n"), __func__, error); -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 0041D7F5A for ; Fri, 11 Sep 2015 13:55:47 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 83CC4AC00E for ; Fri, 11 Sep 2015 11:55:46 -0700 (PDT) X-ASG-Debug-ID: 1441997744-04cb6c355a6fca0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id uGR5FxIZsCClkhAQ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id A61FDA8A for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BIti7r027204 for ; Fri, 11 Sep 2015 14:55:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id C6C03124891; Fri, 11 Sep 2015 14:55:42 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 07/12] xfs_repair: track log state throughout all recovery phases Date: Fri, 11 Sep 2015 14:55:37 -0400 X-ASG-Orig-Subj: [PATCH v2 07/12] xfs_repair: track log state throughout all recovery phases Message-Id: <1441997742-37160-8-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com> References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> 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: 1441997745 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 xfs_repair examines and clears the log in phase 2. Phase 2 acquires the log state in local data structures that are lost upon phase exit. v5 filesystems require that the log is formatted with a higher cycle number after the fs is repaired. This requires assessment of the log state to determine whether a reformat is necessary. Rather than duplicate the log processing code, update phase 2 to populate a globally available log data structure. Add a log pointer to xfs_mount, as exists in kernel space, that repair uses to store a reference to the log that is available to various phases. Note that this patch simply plumbs through the global log data structure and does not change behavior in any way. Signed-off-by: Brian Foster --- include/xfs_mount.h | 6 ++++++ repair/phase2.c | 34 +++++++++++++++++++--------------- repair/xfs_repair.c | 8 +++++++- 3 files changed, 32 insertions(+), 16 deletions(-) diff --git a/include/xfs_mount.h b/include/xfs_mount.h index ed897a2..5ec6866 100644 --- a/include/xfs_mount.h +++ b/include/xfs_mount.h @@ -98,6 +98,12 @@ typedef struct xfs_mount { int qi_dqperchunk; } *m_quotainfo; + /* + * xlog is defined in libxlog and thus is not intialized by libxfs. This + * allows an application to initialize and store a reference to the log + * if warranted. + */ + struct xlog *m_log; } xfs_mount_t; /* diff --git a/repair/phase2.c b/repair/phase2.c index 0673a0c..11504e3 100644 --- a/repair/phase2.c +++ b/repair/phase2.c @@ -39,33 +39,33 @@ static void zero_log(xfs_mount_t *mp) { int error; - struct xlog log; xfs_daddr_t head_blk, tail_blk; + struct xlog *log = mp->m_log; - memset(&log, 0, sizeof(log)); + memset(log, 0, sizeof(struct xlog)); x.logBBsize = XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks); x.logBBstart = XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart); x.lbsize = BBSIZE; if (xfs_sb_version_hassector(&mp->m_sb)) x.lbsize <<= (mp->m_sb.sb_logsectlog - BBSHIFT); - log.l_dev = mp->m_logdev_targp; - log.l_logBBsize = x.logBBsize; - log.l_logBBstart = x.logBBstart; - log.l_sectBBsize = BTOBB(x.lbsize); - log.l_mp = mp; + log->l_dev = mp->m_logdev_targp; + log->l_logBBsize = x.logBBsize; + log->l_logBBstart = x.logBBstart; + log->l_sectBBsize = BTOBB(x.lbsize); + log->l_mp = mp; if (xfs_sb_version_hassector(&mp->m_sb)) { - log.l_sectbb_log = mp->m_sb.sb_logsectlog - BBSHIFT; - ASSERT(log.l_sectbb_log <= mp->m_sectbb_log); + log->l_sectbb_log = mp->m_sb.sb_logsectlog - BBSHIFT; + ASSERT(log->l_sectbb_log <= mp->m_sectbb_log); /* for larger sector sizes, must have v2 or external log */ - ASSERT(log.l_sectbb_log == 0 || - log.l_logBBstart == 0 || + ASSERT(log->l_sectbb_log == 0 || + log->l_logBBstart == 0 || xfs_sb_version_haslogv2(&mp->m_sb)); ASSERT(mp->m_sb.sb_logsectlog >= BBSHIFT); } - log.l_sectbb_mask = (1 << log.l_sectbb_log) - 1; + log->l_sectbb_mask = (1 << log->l_sectbb_log) - 1; - if ((error = xlog_find_tail(&log, &head_blk, &tail_blk))) { + if ((error = xlog_find_tail(log, &head_blk, &tail_blk))) { do_warn(_("zero_log: cannot find log head/tail " "(xlog_find_tail=%d), zeroing it anyway\n"), error); @@ -93,12 +93,16 @@ zero_log(xfs_mount_t *mp) } } - libxfs_log_clear(log.l_dev, - XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart), + libxfs_log_clear(log->l_dev, XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart), (xfs_extlen_t)XFS_FSB_TO_BB(mp, mp->m_sb.sb_logblocks), &mp->m_sb.sb_uuid, xfs_sb_version_haslogv2(&mp->m_sb) ? 2 : 1, mp->m_sb.sb_logsunit, XLOG_FMT, XLOG_INIT_CYCLE); + + /* update the log data structure with new state */ + error = xlog_find_tail(log, &head_blk, &tail_blk); + if (error || head_blk != tail_blk) + do_error(_("failed to clear log")); } /* diff --git a/repair/xfs_repair.c b/repair/xfs_repair.c index 85a012b..0e80124 100644 --- a/repair/xfs_repair.c +++ b/repair/xfs_repair.c @@ -539,6 +539,7 @@ main(int argc, char **argv) xfs_dsb_t *dsb; xfs_buf_t *sbp; xfs_mount_t xfs_m; + struct xlog log = {0}; char *msgbuf; struct xfs_sb psb; int rval; @@ -620,7 +621,11 @@ main(int argc, char **argv) } } - /* prepare the mount structure */ + /* + * Prepare the mount structure. Point the log reference to our local + * copy so it's available to the various phases. The log bits are + * initialized in phase 2. + */ memset(&xfs_m, 0, sizeof(xfs_mount_t)); mp = libxfs_mount(&xfs_m, &psb, x.ddev, x.logdev, x.rtdev, 0); @@ -630,6 +635,7 @@ main(int argc, char **argv) progname); exit(1); } + mp->m_log = &log; /* * set XFS-independent status vars from the mount/sb structure -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:49 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id C0AE17F50 for ; Fri, 11 Sep 2015 13:55:48 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id B030B8F8040 for ; Fri, 11 Sep 2015 11:55:45 -0700 (PDT) X-ASG-Debug-ID: 1441997744-04cb6c355a6fc90001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id S2KvmQIym9Wv2NMY (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:44 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 47593C0A1608 for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BIthGR023097 for ; Fri, 11 Sep 2015 14:55:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 98FB6124881; Fri, 11 Sep 2015 14:55:42 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 02/12] libxfs: track largest metadata LSN in use via verifiers Date: Fri, 11 Sep 2015 14:55:32 -0400 X-ASG-Orig-Subj: [PATCH v2 02/12] libxfs: track largest metadata LSN in use via verifiers Message-Id: <1441997742-37160-3-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com> References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441997744 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 The LSN validation helper is called in the I/O verifier codepath for metadata that embed a last-modification LSN. While the codepath exists, this is not used in userspace as in the kernel because the former doesn't have an active log. xfs_repair does need to check the validity of the LSN metadata with respect to the on-disk log, however. Use the LSN validation mechanism to track the largest LSN that has been seen. Export the value so repair can use it once it has processed the entire filesystem. Note that the helper continues to always return true to preserve existing behavior. Signed-off-by: Brian Foster --- include/libxfs.h | 1 + libxfs/util.c | 31 +++++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+) diff --git a/include/libxfs.h b/include/libxfs.h index b1604e2..cc06fc6 100644 --- a/include/libxfs.h +++ b/include/libxfs.h @@ -134,6 +134,7 @@ typedef struct { #define LIBXFS_DIRECT 0x0020 /* can use direct I/O, not buffered */ extern char *progname; +extern xfs_lsn_t libxfs_max_lsn; extern int libxfs_init (libxfs_init_t *); extern void libxfs_destroy (void); extern int libxfs_device_to_fd (dev_t); diff --git a/libxfs/util.c b/libxfs/util.c index 43338b8..236575a 100644 --- a/libxfs/util.c +++ b/libxfs/util.c @@ -730,9 +730,40 @@ xfs_verifier_error( bp->b_bn, BBTOB(bp->b_length)); } +/* + * This is called from I/O verifiers on v5 superblock filesystems. In the + * kernel, it validates the metadata LSN parameter against the current LSN of + * the active log. We don't have an active log in userspace so this kind of + * validation is not required. + * + * xfs_repair piggybacks off this mechanism to help track the largest metadata + * LSN in use on a filesystem. Keep a record of the largest LSN seen such that + * repair can validate it against the state of the log. + */ +xfs_lsn_t libxfs_max_lsn = 0; +pthread_mutex_t libxfs_max_lsn_lock = PTHREAD_MUTEX_INITIALIZER; + void xfs_detect_invalid_lsn( struct xfs_mount *mp, xfs_lsn_t lsn) { + int cycle = CYCLE_LSN(lsn); + int block = BLOCK_LSN(lsn); + int max_cycle; + int max_block; + + if (lsn == NULLCOMMITLSN) + return; + + pthread_mutex_lock(&libxfs_max_lsn_lock); + + max_cycle = CYCLE_LSN(libxfs_max_lsn); + max_block = BLOCK_LSN(libxfs_max_lsn); + + if ((cycle > max_cycle) || + (cycle == max_cycle && block > max_block)) + libxfs_max_lsn = lsn; + + pthread_mutex_unlock(&libxfs_max_lsn_lock); } -- 2.1.0 From bfoster@redhat.com Fri Sep 11 13:55:49 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 5FD4C7F54 for ; Fri, 11 Sep 2015 13:55:49 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 508E9304039 for ; Fri, 11 Sep 2015 11:55:49 -0700 (PDT) X-ASG-Debug-ID: 1441997744-04cbb005eb77500001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id qtmwuMOvKfGiPI1s (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 11:55:44 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 3F367C0B2B6D for ; Fri, 11 Sep 2015 18:55:44 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BIth23020210 for ; Fri, 11 Sep 2015 14:55:44 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 884D2124857; Fri, 11 Sep 2015 14:55:42 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2 03/12] libxfs: don't hardcode cycle 1 into unmount op header Date: Fri, 11 Sep 2015 14:55:33 -0400 X-ASG-Orig-Subj: [PATCH v2 03/12] libxfs: don't hardcode cycle 1 into unmount op header Message-Id: <1441997742-37160-4-git-send-email-bfoster@redhat.com> In-Reply-To: <1441997742-37160-1-git-send-email-bfoster@redhat.com> References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441997744 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 The libxfs helper to write a log record after zeroing the log fills much of the record header and unmount record with dummy data. It also hardcodes the cycle number into the transaction oh_tid field as the kernel expects to find the cycle stamped at the top of each block and the original oh_tid value packed into h_cycle_data of the record header. The log clearing code requires the ability to format the log to an arbitrary cycle number to fix v5 superblock log recovery ordering problems. As a result, the unmount record helper must not hardcode a cycle of 1. Fix up libxfs_log_header() to pack the unmount record appropriately, as is already done for extra blocks that might exist beyond the record. Use h_cycle_data for the original 32-bit word of the log record data block and stamp the cycle number in its place. This allows unmount_record() to work for arbitrary cycle numbers and libxfs_log_header() to pack a cycle value that matches the lsn used in the record header. Note that this patch does not change behavior as the lsn is still hardcoded to (1:0). Signed-off-by: Brian Foster --- libxfs/rdwr.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c index bc77699..ef18749 100644 --- a/libxfs/rdwr.c +++ b/libxfs/rdwr.c @@ -122,7 +122,7 @@ static void unmount_record(void *p) } magic = { XLOG_UNMOUNT_TYPE, 0, 0 }; memset(p, 0, BBSIZE); - op->oh_tid = cpu_to_be32(1); + op->oh_tid = cpu_to_be32(0xb0c0d0d0); op->oh_len = cpu_to_be32(sizeof(magic)); op->oh_clientid = XFS_LOG; op->oh_flags = XLOG_UNMOUNT_TRANS; @@ -188,10 +188,6 @@ libxfs_log_header( len = ((version == 2) && sunit) ? BTOBB(sunit) : 1; - /* note that oh_tid actually contains the cycle number - * and the tid is stored in h_cycle_data[0] - that's the - * way things end up on disk. - */ memset(p, 0, BBSIZE); head->h_magicno = cpu_to_be32(XLOG_HEADER_MAGIC_NUM); head->h_cycle = cpu_to_be32(1); @@ -203,7 +199,6 @@ libxfs_log_header( head->h_crc = cpu_to_le32(0); head->h_prev_block = cpu_to_be32(-1); head->h_num_logops = cpu_to_be32(1); - head->h_cycle_data[0] = cpu_to_be32(0xb0c0d0d0); head->h_fmt = cpu_to_be32(fmt); head->h_size = cpu_to_be32(XLOG_HEADER_CYCLE_SIZE); @@ -212,11 +207,25 @@ libxfs_log_header( memcpy(&head->h_fs_uuid, fs_uuid, sizeof(uuid_t)); - len = MAX(len, 2); p = nextfunc(p, BBSIZE, private); unmount_record(p); + /* + * The kernel expects to see either a log record header magic or the LSN + * cycle at the top of every log block (for example, see + * xlog_[un]pack_data() and xlog_get_cycle()). Pack the unmount record + * block appropriately here. + */ cycle_lsn = CYCLE_LSN_DISK(head->h_lsn); + head->h_cycle_data[0] = *(__be32 *)p; + *(__be32 *)p = cycle_lsn; + + /* + * Now zero any remaining blocks in the record and stamp with the cycle. + * Note that we don't need to swap into h_cycle_data because it has + * already been initialized to zero. + */ + len = MAX(len, 2); for (i = 2; i < len; i++) { p = nextfunc(p, BBSIZE, private); memset(p, 0, BBSIZE); -- 2.1.0 From bfoster@redhat.com Fri Sep 11 14:22:35 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id BCDB57F37 for ; Fri, 11 Sep 2015 14:22:35 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 9C8AA30404E for ; Fri, 11 Sep 2015 12:22:32 -0700 (PDT) X-ASG-Debug-ID: 1441999349-04cb6c355d70c00001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id MnSpInzGuCCdD99B (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 11 Sep 2015 12:22:30 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 4AE1F8E69F; Fri, 11 Sep 2015 19:22:29 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-37.bos.redhat.com [10.18.41.37]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8BJMSVm002139; Fri, 11 Sep 2015 15:22:28 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 4122F1236D9; Fri, 11 Sep 2015 15:22:27 -0400 (EDT) Date: Fri, 11 Sep 2015 15:22:27 -0400 From: Brian Foster To: Rich Johnston Cc: xfs@oss.sgi.com Subject: Re: [PATCH V4] xfsrestore: fix fs uuid order check for incremental restores Message-ID: <20150911192226.GA19690@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH V4] xfsrestore: fix fs uuid order check for incremental restores References: <20150826213133.GB3902@dastard> <55D5FB95.1280108@sgi.com> <20150902132112.GB23587@bfoster.bfoster> <20150903234346.2473A600006AF@gulag1.americas.sgi.com> <20150908124726.GA5305@bfoster.bfoster> <20150911171450.C067C6073EA67@gulag1.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150911171450.C067C6073EA67@gulag1.americas.sgi.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1441999350 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Fri, Sep 11, 2015 at 12:14:50PM -0500, Rich Johnston wrote: > Restoring an incremental level 1 dump will fail with the following error > if the fs uuid of the most recent level 0 dump in the inventory does not > match level 1 dump we are restoring. > > xfsrestore: ERROR: selected dump not based on previously applied dump > > This can happen when you have multiple filesystems and you are restoring > a level 1 or greater dump of filesystem FS1 but the most recent level 0 > dump in the inventory was filesystem FS2 > > The fix is to ensure the fs uuid of the inventory entry and the dump to > be restored match. > > Signed-off-by: Rich Johnston > --- Looks fine to me: Reviewed-by: Brian Foster > > Changelog > V2 wrong file sent > > V3 > Address review comments from Brian: > > fix invmgr_query_all_sessions() returning true if these error cases > persist throughout the loop > > make if check more readable and less overloaded in search_inv() and > return an error if GET_REC_NOLOCK() fails > > use NULL instead of (uuid_t *)0 in Inv_validate_cmdline() > > remove any spaces around braces of code that was changed > > V4 > fix compile error introduced when I removed any spaces around braces of > code that was changed and cleaning up whitespace. > > we should be returning BOOL_FALSE on any errors. I missed one. > > dump/content.c | 16 +++--- > inventory/inv_api.c | 130 +++++++++++++++++++++++++++++--------------------- > inventory/inv_mgr.c | 53 +++++++++++++------- > inventory/inv_priv.h | 7 +- > inventory/inventory.h | 21 +++++--- > restore/content.c | 23 +++++--- > 6 files changed, 151 insertions(+), 99 deletions(-) > > Index: b/dump/content.c > =================================================================== > --- a/dump/content.c > +++ b/dump/content.c > @@ -872,7 +872,7 @@ content_init( intgen_t argc, > sameinterruptedpr = BOOL_FALSE; > interruptedpr = BOOL_FALSE; > > - ok = inv_get_session_byuuid( &baseuuid, &sessp ); > + ok = inv_get_session_byuuid(&fsid, &baseuuid, &sessp); > if ( ! ok ) { > mlog( MLOG_NORMAL | MLOG_ERROR, _( > "could not find specified base dump (%s) " > @@ -983,9 +983,10 @@ content_init( intgen_t argc, > "online inventory not available\n") ); > return BOOL_FALSE; > } > - ok = inv_lastsession_level_lessthan( inv_idbt, > - ( u_char_t )sc_level, > - &sessp ); > + ok = inv_lastsession_level_lessthan(&fsid, > + inv_idbt, > + (u_char_t)sc_level, > + &sessp); > if ( ! ok ) { > sessp = 0; > } > @@ -1022,9 +1023,10 @@ content_init( intgen_t argc, > if ( inv_idbt != INV_TOKEN_NULL ) { > /* REFERENCED */ > bool_t ok1; > - ok = inv_lastsession_level_equalto( inv_idbt, > - ( u_char_t )sc_level, > - &sessp ); > + ok = inv_lastsession_level_equalto(&fsid, > + inv_idbt, > + (u_char_t)sc_level, > + &sessp); > ok1 = inv_close( inv_idbt ); > ASSERT( ok1 ); > if ( ! ok ) { > Index: b/inventory/inv_api.c > =================================================================== > --- a/inventory/inv_api.c > +++ b/inventory/inv_api.c > @@ -596,69 +596,78 @@ inv_free_session( > > > /*----------------------------------------------------------------------*/ > -/* inventory_lasttime_level_lessthan */ > -/* */ > -/* Given a token that refers to a file system, and a level, this returns*/ > -/* the last time when a session of a lesser level was done. */ > -/* */ > -/* returns -1 on error. */ > +/* inv_lasttime_level_lessthan */ > +/* */ > +/* Given a file system uuid, token that refers to a file system, and a */ > +/* level, tm is populated with last time when a session of a lesser */ > +/* level was done. */ > +/* */ > +/* Returns TRUE on success. */ > /*----------------------------------------------------------------------*/ > > bool_t > inv_lasttime_level_lessthan( > - inv_idbtoken_t tok, > - u_char level, > - time32_t **tm ) > + uuid_t *fsidp, > + inv_idbtoken_t tok, > + u_char level, > + time32_t **tm) > { > int rval; > if ( tok != INV_TOKEN_NULL ) { > - rval = search_invt( tok->d_invindex_fd, &level, (void **) tm, > - (search_callback_t) tm_level_lessthan ); > + rval = search_invt(fsidp, tok->d_invindex_fd, &level, > + (void **)tm, > + (search_callback_t)tm_level_lessthan); > > return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; > } > > - return invmgr_query_all_sessions((void *) &level, /* in */ > - (void **) tm, /* out */ > - (search_callback_t) tm_level_lessthan); > + return invmgr_query_all_sessions(fsidp, /* fs uuid ptr */ > + (void *)&level, /* in */ > + (void **)tm, /* out */ > + (search_callback_t)tm_level_lessthan); > } > > - > - > - > - > /*----------------------------------------------------------------------*/ > -/* */ > -/* */ > -/* */ > +/* inv_lastsession_level_lessthan */ > +/* */ > +/* Given a file system uuid, token that refers to a file system, and a */ > +/* level, ses is populated with a session of lesser than the level */ > +/* passed in. */ > +/* */ > +/* Returns FALSE on an error, TRUE if not. If (*ses) is NULL, then the */ > +/* search failed. */ > /*----------------------------------------------------------------------*/ > > bool_t > inv_lastsession_level_lessthan( > - inv_idbtoken_t tok, > + uuid_t *fsidp, > + inv_idbtoken_t tok, > u_char level, > - inv_session_t **ses ) > + inv_session_t **ses) > { > int rval; > if ( tok != INV_TOKEN_NULL ) { > - rval = search_invt( tok->d_invindex_fd, &level, (void **) ses, > - (search_callback_t) lastsess_level_lessthan ); > + rval = search_invt(fsidp, tok->d_invindex_fd, &level, > + (void **)ses, > + (search_callback_t)lastsess_level_lessthan); > > return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; > } > > - return invmgr_query_all_sessions((void *) &level, /* in */ > - (void **) ses, /* out */ > - (search_callback_t) lastsess_level_lessthan); > + return invmgr_query_all_sessions(fsidp, /* fs uuid */ > + (void *)&level, /* in */ > + (void **)ses, /* out */ > + (search_callback_t)lastsess_level_lessthan); > > } > > - > - > - > /*----------------------------------------------------------------------*/ > -/* */ > -/* */ > +/* inv_lastsession_level_equalto */ > +/* */ > +/* Given a file system uuid, token that refers to a file system, and a */ > +/* level, this populates ses with last time when a session of a lesser */ > +/* level was done. */ > +/* */ > /* Return FALSE on an error, TRUE if not. If (*ses) is NULL, then the */ > /* search failed. */ > /*----------------------------------------------------------------------*/ > @@ -666,21 +675,24 @@ inv_lastsession_level_lessthan( > > bool_t > inv_lastsession_level_equalto( > - inv_idbtoken_t tok, > + uuid_t *fsidp, > + inv_idbtoken_t tok, > u_char level, > inv_session_t **ses ) > { > int rval; > if ( tok != INV_TOKEN_NULL ) { > - rval = search_invt( tok->d_invindex_fd, &level, (void **) ses, > - (search_callback_t) lastsess_level_equalto ); > + rval = search_invt(fsidp, tok->d_invindex_fd, &level, > + (void **)ses, > + (search_callback_t)lastsess_level_equalto); > > return ( rval < 0) ? BOOL_FALSE: BOOL_TRUE; > } > > - return invmgr_query_all_sessions((void *) &level, /* in */ > - (void **) ses, /* out */ > - (search_callback_t) lastsess_level_equalto); > + return invmgr_query_all_sessions(fsidp, /* fs uuid */ > + (void *)&level, /* in */ > + (void **)ses, /* out */ > + (search_callback_t)lastsess_level_equalto); > > } > > @@ -688,35 +700,45 @@ inv_lastsession_level_equalto( > /*----------------------------------------------------------------------*/ > /* inv_getsession_byuuid */ > /* */ > +/* Given a file system uuid and a session uuid , ses is populated with */ > +/* the session that contains the matching system uuid. */ > +/* */ > +/* Returns FALSE on an error, TRUE if the session was found. */ > /*----------------------------------------------------------------------*/ > > bool_t > inv_get_session_byuuid( > - uuid_t *sesid, > - inv_session_t **ses) > + uuid_t *fsidp, > + uuid_t *sesid, > + inv_session_t **ses) > { > > - return (invmgr_query_all_sessions((void *)sesid, /* in */ > - (void **) ses, /* out */ > - (search_callback_t) stobj_getsession_byuuid)); > + return invmgr_query_all_sessions(fsidp, /* fs uuid */ > + (void *)sesid, /* in */ > + (void **)ses, /* out */ > + (search_callback_t)stobj_getsession_byuuid); > } > > - > - > /*----------------------------------------------------------------------*/ > -/* inv_getsession_byuuid */ > +/* inv_getsession_bylabel */ > /* */ > +/* Given a file system uuid and a session uuid, ses is populated with */ > +/* the session that contains the matching system label. */ > +/* */ > +/* Returns FALSE on an error, TRUE if the session was found. */ > /*----------------------------------------------------------------------*/ > > bool_t > inv_get_session_bylabel( > - char *session_label, > - inv_session_t **ses) > + uuid_t *fsidp, > + char *session_label, > + inv_session_t **ses) > { > > - return (invmgr_query_all_sessions((void *)session_label, /* in */ > - (void **) ses, /* out */ > - (search_callback_t) stobj_getsession_bylabel)); > + return invmgr_query_all_sessions(fsidp, /* fs uuid */ > + (void *)session_label, /* in */ > + (void **)ses, /* out */ > + (search_callback_t)stobj_getsession_bylabel); > } > > > @@ -786,8 +808,8 @@ inv_delete_mediaobj( uuid_t *moid ) > return BOOL_FALSE; > } > > - if ( search_invt( invfd, NULL, (void **)&moid, > - (search_callback_t) stobj_delete_mobj ) > + if (search_invt(&arr[i].ft_uuid, invfd, NULL, (void **)&moid, > + (search_callback_t)stobj_delete_mobj) > < 0 ) > return BOOL_FALSE; > /* we have to delete the session, etc */ > Index: b/inventory/inv_mgr.c > =================================================================== > --- a/inventory/inv_mgr.c > +++ b/inventory/inv_mgr.c > @@ -134,8 +134,9 @@ get_sesstoken( inv_idbtoken_t tok ) > /*---------------------------------------------------------------------------*/ > bool_t > invmgr_query_all_sessions ( > - void *inarg, > - void **outarg, > + uuid_t *fsidp, > + void *inarg, > + void **outarg, > search_callback_t func) > { > invt_counter_t *cnt; > @@ -145,6 +146,7 @@ invmgr_query_all_sessions ( > int result; > inv_oflag_t forwhat = INV_SEARCH_ONLY; > void *objectfound; > + bool_t ret = BOOL_FALSE; > > /* if on return, this is still null, the search failed */ > *outarg = NULL; > @@ -157,7 +159,7 @@ invmgr_query_all_sessions ( > } > if ( fd < 0 || numfs <= 0 ) { > mlog( MLOG_NORMAL | MLOG_INV, _("INV: Error in fstab\n") ); > - return BOOL_FALSE; > + return ret; > } > > close( fd ); > @@ -169,7 +171,7 @@ invmgr_query_all_sessions ( > mlog( MLOG_NORMAL | MLOG_INV, _( > "INV: Cant get inv-name for uuid\n") > ); > - return BOOL_FALSE; > + continue; > } > strcat( fname, INV_INVINDEX_PREFIX ); > invfd = open( fname, INV_OFLAG(forwhat) ); > @@ -178,9 +180,9 @@ invmgr_query_all_sessions ( > "INV: Open failed on %s\n"), > fname > ); > - return BOOL_FALSE; > + continue; > } > - result = search_invt( invfd, inarg, &objectfound, func ); > + result = search_invt(fsidp, invfd, inarg, &objectfound, func); > close(invfd); > > /* if error return BOOL_FALSE */ > @@ -192,12 +194,13 @@ invmgr_query_all_sessions ( > return BOOL_TRUE; > } else if (result == 1) { > *outarg = objectfound; > + ret = BOOL_TRUE; > } > } > > /* return val indicates if there was an error or not. *buf > says whether the search was successful */ > - return BOOL_TRUE; > + return ret; > } > > > @@ -213,10 +216,11 @@ invmgr_query_all_sessions ( > > intgen_t > search_invt( > - int invfd, > - void *arg, > - void **buf, > - search_callback_t do_chkcriteria ) > + uuid_t *fsidp, > + int invfd, > + void *arg, > + void **buf, > + search_callback_t do_chkcriteria) > { > > int fd, i; > @@ -247,7 +251,7 @@ search_invt( > /* we need to get all the invindex headers and seshdrs in reverse > order */ > for (i = nindices - 1; i >= 0; i--) { > - int nsess; > + int nsess, j; > invt_sescounter_t *scnt = NULL; > invt_seshdr_t *harr = NULL; > bool_t found; > @@ -272,19 +276,34 @@ search_invt( > } > free ( scnt ); > > - while ( nsess ) { > + for (j = nsess - 1; j >= 0; j--) { > + invt_session_t ses; > + > /* fd is kept locked until we return from the > callback routine */ > > /* Check to see if this session has been pruned > * by xfsinvutil before checking it. > */ > - if ( harr[nsess - 1].sh_pruned ) { > - --nsess; > + if (harr[j].sh_pruned) { > continue; > } > - found = (* do_chkcriteria ) ( fd, &harr[ --nsess ], > - arg, buf ); > + > + /* if we need to check the fs uuid's and they don't > + * match or we fail to get the session record, > + * then keep looking > + */ > + if (fsidp) { > + int ret = GET_REC_NOLOCK(fd, &ses, > + sizeof(invt_session_t), > + harr[j].sh_sess_off); > + if (ret < 0) > + return ret; > + if (uuid_compare(ses.s_fsid, *fsidp)) > + continue; > + } > + > + found = (* do_chkcriteria)(fd, &harr[j], arg, buf); > if (! found ) continue; > > /* we found what we need; just return */ > Index: b/inventory/inv_priv.h > =================================================================== > --- a/inventory/inv_priv.h > +++ b/inventory/inv_priv.h > @@ -548,11 +548,12 @@ get_headerinfo( int fd, void **hdrs, voi > size_t hdrsz, size_t cntsz, bool_t doblock ); > > bool_t > -invmgr_query_all_sessions (void *inarg, void **outarg, search_callback_t func); > +invmgr_query_all_sessions(uuid_t *fsidp, void *inarg, void **outarg, > + search_callback_t func); > > intgen_t > -search_invt( int invfd, void *arg, void **buf, > - search_callback_t do_chkcriteria ); > +search_invt(uuid_t *fsidp, int invfd, void *arg, void **buf, > + search_callback_t do_chkcriteria); > intgen_t > invmgr_inv_print( int invfd, invt_pr_ctx_t *prctx); > > Index: b/inventory/inventory.h > =================================================================== > --- a/inventory/inventory.h > +++ b/inventory/inventory.h > @@ -247,32 +247,37 @@ inv_put_mediafile( > */ > extern bool_t > inv_lasttime_level_lessthan( > + uuid_t *fsidp, > inv_idbtoken_t tok, > - u_char level, > - time32_t **time );/* out */ > + u_char level, > + time32_t **time); /* out */ > > extern bool_t > inv_lastsession_level_lessthan( > + uuid_t *fsidp, > inv_idbtoken_t tok, > u_char level, > - inv_session_t **ses );/* out */ > + inv_session_t **ses); /* out */ > > extern bool_t > inv_lastsession_level_equalto( > + uuid_t *fsidp, > inv_idbtoken_t tok, > u_char level, > - inv_session_t **ses );/* out */ > + inv_session_t **ses); /* out */ > > /* Given a uuid of a session, return the session structure.*/ > extern bool_t > inv_get_session_byuuid( > - uuid_t *sesid, > - inv_session_t **ses); > + uuid_t *fsidp, > + uuid_t *sesid, > + inv_session_t **ses); > > extern bool_t > inv_get_session_bylabel( > - char *session_label, > - inv_session_t **ses); > + uuid_t *fsidp, > + char *session_label, > + inv_session_t **ses); > > > /* on return, *ses is NULL */ > Index: b/restore/content.c > =================================================================== > --- a/restore/content.c > +++ b/restore/content.c > @@ -2179,8 +2179,9 @@ content_stream_restore( ix_t thrdix ) > if ( ! drivep->d_isnamedpipepr > && > ! drivep->d_isunnamedpipepr ) { > - ok = inv_get_session_byuuid( &grhdrp->gh_dumpid, > - &sessp ); > + ok = inv_get_session_byuuid(NULL, > + &grhdrp->gh_dumpid, > + &sessp); > if ( ok && sessp ) { > mlog( MLOG_VERBOSE, _( > "using online session inventory\n") ); > @@ -3736,9 +3737,9 @@ Inv_validate_cmdline( void ) > ok = BOOL_FALSE; > sessp = 0; > if ( tranp->t_reqdumpidvalpr ) { > - ok = inv_get_session_byuuid( &tranp->t_reqdumpid, &sessp ); > + ok = inv_get_session_byuuid(NULL, &tranp->t_reqdumpid, &sessp); > } else if ( tranp->t_reqdumplabvalpr ) { > - ok = inv_get_session_bylabel( tranp->t_reqdumplab, &sessp ); > + ok = inv_get_session_bylabel(NULL, tranp->t_reqdumplab, &sessp); > } > rok = BOOL_FALSE; > if ( ok && sessp ) { > @@ -6812,13 +6813,15 @@ askinvforbaseof( uuid_t baseid, inv_sess > /* get the base session > */ > if ( resumedpr ) { > - ok = inv_lastsession_level_equalto( invtok, > - ( u_char_t )level, > - &basesessp ); > + ok = inv_lastsession_level_equalto(&sessp->s_fsid, > + invtok, > + (u_char_t)level, > + &basesessp); > } else { > - ok = inv_lastsession_level_lessthan( invtok, > - ( u_char_t )level, > - &basesessp ); > + ok = inv_lastsession_level_lessthan(&sessp->s_fsid, > + invtok, > + (u_char_t)level, > + &basesessp); > } > if ( ! ok ) { > mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_MEDIA, _( > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bounce-1676-550028-1064-248@dflswe.com Fri Sep 11 23:19:19 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.7 required=5.0 tests=DEAR_FRIEND,T_DKIM_INVALID autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 61DE07F37 for ; Fri, 11 Sep 2015 23:19:19 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 5232D8F8040 for ; Fri, 11 Sep 2015 21:19:15 -0700 (PDT) X-ASG-Debug-ID: 1442031552-04cbb005ec89620001-NocioJ Received: from host2.dflswe.com (v133-130-97-217.a026.g.tyo1.static.cnode.io [133.130.97.217]) by cuda.sgi.com with ESMTP id kK3jY0QbaHq8HmIp for ; Fri, 11 Sep 2015 21:19:13 -0700 (PDT) X-Barracuda-Envelope-From: bounce-1676-550028-1064-248@dflswe.com X-Barracuda-Apparent-Source-IP: 133.130.97.217 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=tradewm; d=pf-mold.com; h=Date:To:From:Reply-to:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Transfer-Encoding:Content-Type; i=sales@pf-mold.com; bh=6hm4hXYAbzhY/CXvs6BwQmFEHmY=; b=UfSFbN5r3IOR/qgGL6ZkDTTGhsDbXAElYmnFskH6sUHNfGiwaac79p1Lr2Ay9KuEHmlbSlxM1bjT CtAvvIdpKhp+rY0keB5J+JxKF+2E3RjSIiWk2wiXuTSiKRXiCE1SSlBl1Ze/EtljPJlmxzrCgCqM pYFu22FS5qJUvPY1La8= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=tradewm; d=pf-mold.com; b=f6hum5rfKTnlf2jvqQx8b8Ax2CWaC+ZnqU9CoPxg17qL20Ze7HObBRx/YJEyeV5C9iPH7cLwU8Iw 2rf+glmnUCW5pN2XRKW+aJZrEVyx1iJOCceo0xAmtRNs4DSP0luNmCcPyFDTwO1cF344ia5ET6sH xPxg+6wwCxGxdUq7VeE=; Received: by host2.dflswe.com id huejs20e97c0 for ; Sat, 12 Sep 2015 13:19:08 +0900 (envelope-from ) Date: Sat, 12 Sep 2015 13:19:08 +0900 To: "xfs@oss.sgi.com" From: pfmold Reply-to: pfmold Subject: Injection mold and molding Message-ID: <8d4826409027b2f61914a3237d2084f1@133.130.97.217> X-ASG-Orig-Subj: Injection mold and molding X-Priority: 3 X-Mailer: Email Sending System X-Complaints-To: admin@qq.com List-Unsubscribe: X-MessageID: OHx8fHwyNjk2fHx8fHhmc0Bvc3Muc2dpLmNvbXx8fHw1fHx8fDF8fHx8MA%3D%3D X-Report-Abuse: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Barracuda-Connect: v133-130-97-217.a026.g.tyo1.static.cnode.io[133.130.97.217] X-Barracuda-Start-Time: 1442031553 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.00 X-Barracuda-Spam-Status: No, SCORE=1.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DEAR_FRIEND, DKIM_SIGNED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22464 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 1.00 DEAR_FRIEND BODY: Dear Friend? That's not very dear! Dear Friend, PF is a professional Injection Mold , Die-casting manufacturer=20 with more than decade experience located in Shenzhen China,=20 and we also offer CNCs machining and Rapid Prototyping=20 services. We are a professional mold maker in China. we can give your=20 good solutions as followings: 1. Injection mould 2. Plastic molding 3. Over-molding 4. Assembly,painting,silk-screen Good quality with better price is our advantage. please send us the drawings, we will quote to you soon. Peter PF Industry Co., Limited.=20 1st floor,No.589-1, Jinbi Road, Pingshan, Longgang district, Shenzhen, Chin= a.518118 TEL: +86-755-28326656 Fax: +86-755-28326655 Mobile: +86-18038086989 Email:manager@pf-mold.com Website: www.pf-mold.com Skype:pfmold Whatsapp/Tango/Viber:+86 18038086989 From david@fromorbit.com Sun Sep 13 18:51:09 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 6517C7F37 for ; Sun, 13 Sep 2015 18:51:09 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 10F8AAC002 for ; Sun, 13 Sep 2015 16:51:05 -0700 (PDT) X-ASG-Debug-ID: 1442188262-04bdf04db3cb590001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id RHXxYRie4Ho7PoRw for ; Sun, 13 Sep 2015 16:51:03 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BxCgAHC/ZVPOV8LHldgyOBPYJcg32iRQEBAQEBAQaKZpEaBAICgSJNAQEBAQEBBwEBAQFBP4QkAQEEOhwjEAgDDgoJJQ8FJQMHGhOILclkAQEIAiAZhhOFRIUNB4QsAQSVV4x7mwGEdiwzin0BAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 14 Sep 2015 09:21:00 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZbH2x-0003cT-Qw; Mon, 14 Sep 2015 09:50:59 +1000 Date: Mon, 14 Sep 2015 09:50:59 +1000 From: Dave Chinner To: Brian Foster Cc: Austin Schuh , rt-users , xfs , Philipp Schrader , Brian Silverman Subject: Re: [RT XFS] BUG from lockdep in xfs Message-ID: <20150913235059.GU26895@dastard> X-ASG-Orig-Subj: Re: [RT XFS] BUG from lockdep in xfs References: <20150909114451.GA30015@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150909114451.GA30015@bfoster.bfoster> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1442188263 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22514 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Wed, Sep 09, 2015 at 07:44:51AM -0400, Brian Foster wrote: > On Tue, Sep 08, 2015 at 11:54:07PM -0700, Austin Schuh wrote: > > I'm running xfstests and got the following BUG with lockdep enabled. > > I'm running the 4.1.6-rt5 kernel from TI's tree on a TI ARM chip. > > > > Any ideas on what could be causing it, or if it is a real problem? > > > > I see some patches in Dave's latest 4.3 pull request that discuss > > lockdep. Are there any ones there that are worth backporting to my > > 4.1.6 kernel? > > > > I suspect Dave's recent rework of the lockdep namespace bits is what you > want: > > 0952c818 xfs: clean up inode lockdep annotations Yes, that works around the issue that causes this: > > [ 4357.394974] BUG: looking up invalid subclass: 8 i.e. that we have about 15 different subclass annotations for different inode locking situations we need to shoe horn into 8 subclasses... Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Sep 13 18:58:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 025317F37 for ; Sun, 13 Sep 2015 18:58:42 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 696D3AC002 for ; Sun, 13 Sep 2015 16:58:42 -0700 (PDT) X-ASG-Debug-ID: 1442188717-04cb6c355cbffa0001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id rhCKeGMffRHrOBAw for ; Sun, 13 Sep 2015 16:58:37 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DcCgBtDPZVPOV8LHldgyOBPYJcg32iRQEBAQEBAQaKZpEaAgIBAQKBIk0BAQEBAQEHAQEBAUE/hCQBAQQ6HCMQCAMOCgklDwUlAwcaE4gtyWQBAQgCAR8ZhhOFRIUNB4QsBZVXjHubAYR2LDOKfQEBAQ Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 14 Sep 2015 09:28:36 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZbHAJ-0003dv-Se; Mon, 14 Sep 2015 09:58:35 +1000 Date: Mon, 14 Sep 2015 09:58:35 +1000 From: Dave Chinner To: Brian Foster Cc: xfs@oss.sgi.com, David Jeffery Subject: Re: [PATCH] xfs: add missing ilock around dio write last extent alignment Message-ID: <20150913235835.GV26895@dastard> X-ASG-Orig-Subj: Re: [PATCH] xfs: add missing ilock around dio write last extent alignment References: <1441809812-60175-1-git-send-email-bfoster@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441809812-60175-1-git-send-email-bfoster@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1442188717 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22514 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Wed, Sep 09, 2015 at 10:43:32AM -0400, Brian Foster wrote: > The iomap codepath (via get_blocks()) acquires and release the inode > lock in the case of a direct write that requires block allocation. This > is because xfs_iomap_write_direct() allocates a transaction, which means > the ilock must be dropped and reacquired after the transaction is > allocated and reserved. > > xfs_iomap_write_direct() invokes xfs_iomap_eof_align_last_fsb() before > the transaction is created and thus before the ilock is reacquired. This > can lead to calls to xfs_iread_extents() and reads of the in-core extent > list without any synchronization (via xfs_bmap_eof() and > xfs_bmap_last_extent()). xfs_iread_extents() assert fails if the ilock > is not held, but this is not currently seen in practice as the current > callers had already invoked xfs_bmapi_read(). > > What has been seen in practice are reports of crashes down in the > xfs_bmap_eof() codepath on direct writes due to seemingly bogus pointer > references from xfs_iext_get_ext(). While an explicit reproducer is not > currently available to confirm the cause of the problem, crash analysis > and code inspection from David Jeffrey had identified the insufficient > locking. > > xfs_iomap_eof_align_last_fsb() is called from other contexts with the > inode lock already held. __xfs_get_blocks() acquires and drops the ilock > with variable flags. Therefore, take the simple approach to cycle ilock > around the last extent alignment call from xfs_iomap_write_direct(). > > Reported-by: David Jeffery > Signed-off-by: Brian Foster > --- > fs/xfs/xfs_iomap.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c > index 1f86033..4d7534e 100644 > --- a/fs/xfs/xfs_iomap.c > +++ b/fs/xfs/xfs_iomap.c > @@ -142,7 +142,9 @@ xfs_iomap_write_direct( > offset_fsb = XFS_B_TO_FSBT(mp, offset); > last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); > if ((offset + count) > XFS_ISIZE(ip)) { > + xfs_ilock(ip, XFS_ILOCK_EXCL); > error = xfs_iomap_eof_align_last_fsb(mp, ip, extsz, &last_fsb); > + xfs_iunlock(ip, XFS_ILOCK_EXCL); XFS_ILOCK_SHARED? Also, looking at __xfs_get_blocks(), we drop the ilock immediately before calling xfs_iomap_write_direct(), which we already hold in shared mode for the xfs_bmapi_read() for direct IO. Can we push that lock dropping into xfs_iomap_write_direct() after we've done the xfs_iomap_eof_align_last_fsb() call and before we do transaction reservations so we don't need an extra lock round-trip here? e.g. xfs_iomap_write_delay() is called under the lock context held by __xfs_get_blocks().... Cheers, Dave. -- Dave Chinner david@fromorbit.com From bis@xlmicro.com Mon Sep 14 07:29:19 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 00E5B7F37 for ; Mon, 14 Sep 2015 07:29:19 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id E6E1E8F8040 for ; Mon, 14 Sep 2015 05:29:15 -0700 (PDT) X-ASG-Debug-ID: 1442233731-04cb6c355bd2b00001-NocioJ Received: from xlmicro.com ([58.101.208.170]) by cuda.sgi.com with ESMTP id WKVEeGmstHEb2tzE for ; Mon, 14 Sep 2015 05:29:02 -0700 (PDT) X-Barracuda-Envelope-From: bis@xlmicro.com X-Barracuda-Apparent-Source-IP: 58.101.208.170 Received: from kmtllngjh (unknown [92.131.164.221]) by xlmicro.com with SMTP id R9NQhuuHzyf7ZX5Y.1 for ; Mon, 14 Sep 2015 20:29:00 +0800 Message-ID: <20150914202900378508@xlmicro.com> From: =?utf-8?B?6Zm25b6X?= To: Subject: =?utf-8?B?5b6X54ix5LiN5rul5oOF77yM5aSx54ix5LiN6Ieq5bqf?= Date: Mon, 14 Sep 2015 20:28:55 +0800 X-ASG-Orig-Subj: =?utf-8?B?5b6X54ix5LiN5rul5oOF77yM5aSx54ix5LiN6Ieq5bqf?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0177_016CD529.1E152140" X-mailer: Uuz 5 X-Barracuda-Connect: UNKNOWN[58.101.208.170] X-Barracuda-Start-Time: 1442233732 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MV0113c, BSF_SC5_MJ1963, HTML_MESSAGE, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22527 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MV0113c BSF_SC0_MV0113c 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 This is a multi-part message in MIME format. ------=_NextPart_000_0177_016CD529.1E152140 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0253_016CD529.1E152140" ------=_NextPart_001_0253_016CD529.1E152140 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQrpmYTku7bor7fmgqjlj4LogIMgLS0g6LS15bee5YiG5YWs5Y+4 ------=_NextPart_001_0253_016CD529.1E152140 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAw LjI5MDAuNjQ1MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8UD4mbmJzcDs8L1A+ DQo8UD7pmYTku7bor7fmgqjlj4LogIMgLS0g6LS15bee5YiG5YWs5Y+4PC9QPjwvQk9EWT48L0hU TUw+DQo= ------=_NextPart_001_0253_016CD529.1E152140-- ------=_NextPart_000_0177_016CD529.1E152140 Content-Type: application/octet-stream; name="=?utf-8?B?M+WkqTLlpJws5YGa5aW9MeS7tuS6iy5kb2N4?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?utf-8?B?M+WkqTLlpJws5YGa5aW9MeS7tuS6iy5kb2N4?=" UEsDBBQABgAIAAAAIQDd/JU3ZgEAACAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VMtuwjAQvFfqP0S+Vomhh6qqCBz6OLZIpR9g7A1Y9Uv28vr7bgJEVQtBKuUSKVnvzOzsxIPR2pps CTFp70rWL3osAye90m5Wso/JS37PsoTCKWG8g5JtILHR8PpqMNkESBl1u1SyOWJ44DzJOViRCh/A UaXy0Qqk1zjjQchPMQN+2+vdcekdgsMcaww2HDxBJRYGs+c1fd4qiWASyx63B2uukokQjJYCSSlf OvWDJd8xFNTZnElzHdINyWD8IENdOU6w63sja6JWkI1FxFdhSQZf+ai48nJhaYaiG+aATl9VWkLb X6OF6CWkRJ5bU7QVK7Tb6z+qI+HGQPp/FVvcLnrSOY4+JE57OZsf6s0rUDlZESCihnZ1x0cHRLLs EsPvkLvGb1KAlHfgzbN/tgcNzEnKin6JiZgaOJvvV/Ja6JMiVjB9v5j738C7hLT5kz7+wYz9dVF3 H0gdb+634RcAAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMg ogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9ab g5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYz sKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdh b9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687 HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQDWZLNR+gAAADEDAAAcAAgBd29yZC9f cmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKySzWrDMBCE74W+g9h7LTv9oYTIuZRArq37AIq9/qGyJLSbtn77CkNShwb34otgRmjmk7Sb7Xdv xCcG6pxVkCUpCLSlqzrbKHgvdnfPIIi1rbRxFhUMSLDNb282r2g0x0PUdp5ETLGkoGX2aympbLHX lDiPNu7ULvSaowyN9Lr80A3KVZo+yTDNgPwiU+wrBWFf3YMoBh+b/892dd2V+OLKY4+Wr1TILzy8 IXO8HMVYHRpkBRMzibQgr4OslgShPxQnZw4hWxSBBxM/8/wMNOq5+scl6zmOCP62j1KOazbH8LAk Q+0sF/pgJhxn6wQhLwY9/wEAAP//AwBQSwMEFAAGAAgAAAAhALDCfFCGRwAAe3YFABEAAAB3b3Jk L2RvY3VtZW50LnhtbOydW1MbVxbv30/V+Q4qnmaqJjb4Fts1MMdOJjOpM1Px8fhU6jwqIIMmWKIk 2cnkSYAFuiJh7khcAwbbIHE1uiD4LnHv3a0nf4XzX71bssA4CYzjlsnKZIK61Wq1WvrtdV/rz3/5 /kG345HL53d7Pa1NLReamxwuT7u3w+3pbG36v/e++OR6k8MfcHo6nN1ej6u16T8uf9Nf2v7n//jz dzc7vO0PH7g8AQdO4fHffIRnuwKBnpsXL/rbu1wPnP4L3h6XB0/e9/oeOAPY9HVefOD0ffuw55N2 74MeZ8D9jbvbHfjPxUvNzdearNN4W5se+jw3rVN88sDd7vP6vfcD9JKb3vv33e0u60/1Fb5f877q lZ9bl2y+40WfqxvX4PX4u9w9/urZHpz1bPiIXdWTPPq5D/HoQXf1uO96fs27dfic3+H7eNCtLvs7 r6+jx+dtd/n92Pu5erJ2xpbmn3tv6wbSKWqv+DWXcPQ9q1fywOn21E5Dv45j33/ty7uAL++ieu+L dKo3HwT3og2/pW+8Hf+hv4Fvuq0/d3zWg547Psd3N7td9wNf+LwP7rm+D+B3eh2/0+9u+tydXW/v 7fL6frjlacef1ib83DrpGs0z9/y/1qbLzc1NF60zf43d3+FkzZ9eM08X+E8PPkPH987aEf/wer/F QY+c3a1NzVdumS+9aJ6rdnl/87k76Hyd+PuZt7v+lHgfdXD1mAB9EqDWcRena7595erl21fNz0G7 7uByj++8V7/PvGqf9ca+v7vow1cv7tKV2rVVj2g3j2+3jm//pQ/bfhvfC9YB81XenuqJPe5udTfo C3hr5zfeQMD74K3d5vdybC/difr38Hd1VI9o73Y5fXQf2r3d9KU5Hwa8tHnf3Y37bm6ZX5nH+7XP 2WM+fHSr293pqZ5AXYa6zi53h+ufWGSsm299fvo8p7nxdz933Xc+7MZP7fhXcqduF90r/Dzpj7Pj 3w/9gbv0nXzp6TCv0e9x9tzz0nevNnuc7eAVF+K8H3DRF6su2Pq+fF94PQE/Petvd7tbm0Q2ppVH 6Da4nP7ALb/bWb+v65bHf+Sgdn9r0z1nl/eB9eM1byVerH66zfQPvR2+BfP98Ne6cB8OMu/Mkd8f faT3fmF4py63B/e0+onUDfiFS8Xvpk0c9ovCtghPyY1R8SRuYqU+jHmhv/ojVN+4/lae8s7R5fzp zBfwX3+5Z7+H6tbhHmrFYmWheOaP8Hu+h+rWmfcwJsMpu+/hhSMXQEwriYOln5ZbJUFrgNctXCcC Y+1kmfP7kznvgemzSJT38Lb4mZPhcNMP6Qrlrcfn8rt8j1xNbQ5mo6a7sT5GagLrY6RN1qk7Z9cl xOELrZDSpx9DIGr5hJzMaaVxcTAhwhvYKZamj8AHVfJEgXOSkvl+loSPU0MzgnF1J43sgnHQT3dy Y9juO8k6RhOvo+/Drn0PZLOOwT4fSBLTp8E+n3pRbnqYfsGRchZ6bPRXiKd9cjYjw8Nya0FmInbL wY/T5xMeFhubWj4ostPG016+h2fwPeIXyDfQSabDWZ23tV9gf9nuXyBrs6zNvpcozXvUZkkus9/W VOosSwt3hGOFvyZWyL9CjlhXXWv2Raw/4l9hC1KPrLh44P0mTnR4A587/cgIguP5h9YmpFHhgQpS mMkmVq7D9Wb6nwqE16dYnOHlvyYZ49SnPcVSbCYZmJ9NJW5cNv9RH+2dqRvtSCBz+dRBH13qxr/b 8aWagqv+Y7z3vAnTuP9G/fcz/9um/hfmP+oe+n+oXtLla9U9n1FaiXmZah++04ZLAvkNPh5lamj5 9cqLSbHZp5eSempAhFYrM4t6dgGPZTRo9JdFdlaGJ43sul7qP2KcfGit7ErzVfq+iLf3uxDVvNcf +fLyrqywo6lg9SB+dOvJB185bty4bCVEfmRrwtsX/s5EgFfBlJx4WZnYEZkNva/wKjh8NDXgNNHJ 38YdWr33tGBdam65Kgo7zTdkJtxy/ZNLzXJiWe5tisz2q2Cvw9HSTPuvfdJyHfu1fFTu7tF+c/fl 5k9aWuhpPCXiE1pxjRc0ygl5l7plt770rgXtfOpKv8XaVgUHfxsmm/VnFJnTLVoi2Sei8yJXMDYX GnzR0vZ7tfy0iORksITlSKQeV/pXKxOrSunCHi1fgtKlntKLK9DKSCUz1TBkkIjhSTwlxzdkMiVj o8h7oJeUhrT8CE6LA2QkYZTXxGyM8kvMV+EYXtx4cSOj+u3k9epO+zwi/7WeoCyBBrPSqsvtz6ha wVfB4//KqZhIDIJcyxBT1JeWRTIqQi9Ftr+yiIyxwfrVgNFmtM8z2qh3e7c3520t4XyqN+tPtcK8 sVPQR1cbXL25cq25WYT6L14WS88utkAfeb0fFqkXRu5AX40Z2S2tECHVJhGuLKXwQF8dwsfCAyP+ Eganvh55vX80fYW+0A8Z8WPfkpn//R4rDtnN9Fb22e9mSWsjj1LkUERnRWJMKyeweh1RWBrKofSO 4hiRHZQzG7DboHYduXhemlCZWx+Us9tLdDyqVh/seaen6KNOjnV7qDL8vtvnD/zD7XF91uX0obj5 OgK19btRt09l+6Ye9S7f0kHWKOcq6VClNEyvrRZNH9tdVxFjnu03TKM99s6/fEF01WcrmdZHd4+A fZpV6ZR3hPzWn5z5zaq28ge8N0Zu5vX+2WuUTn973rEKO7769OrVC9e+vHT90uVrXznUP19d+vLC 1S+vfXXpq8vWrq++/Ir2XLtx+cuvjtxmXqx5sT7StgHLhekO+3CeL16s3zTeOPtiXenLHgGbF+tq 95FAm57dbIzFuuf7C51O732np/N/3fd+j95H3dTWCIv2mb86G0SfyKye+XLfm9w78xXYcMP04uGZ L/e93TDH/znzNdhwyz4srm1XW1o+vXH98uVPj9wj1o1YN2LdyOuDUmKmflp+hPcUWPyAxpqMxI6A zbrRG91IZhCLaARDtuX6jYv0/0vXWq60HPm6eB1usHWY086ONE48qXil6pertWA8qsjhJ/0RZmYw lZxUwUkVREGDwXvKbBDythu78xXkF+w+luNTxxUAFrgscI83Lf7I2xk3HrPVKyIYWy44aqlAIh/W I+Ejoha5Pj6v9/5ffWSKqRbj/h5Xd/e/Ak5fwIpfVv32RwzWk9rjVb05Nc3ktOrLiT7q+k/TEwj8 qsv/q6ej4S7+HWG21/tp9QUhpd4I9hsrA5XF4VfBqFhaqaR7kUoux0JaMSaiq/poSY8MvgrG8Gwl nZDrP+pDMZmZMaJ9lSCSvGJmMlf6yA3i9ZbXW15v31/7+l9coS5dcKhkcaX/INFBrKe0wlN9M/Ep EjWXpmVmjTI04yEZW1NHgnSszCIxIYNBffiAsjXL++hX+hdxsFfZ6hUhAN+LhCg8qMw9FWgyv4xV AJmcJT2dRsN5sfTCGJ7QyhkkrcutfhygD/EqYHZc5uo6LkCxTCr8eW9DLH5pFXiHqHc4KO/6yZQe SUNUowpNhAf0uWWRSqgaNW1/3shuQCGQ6QORLhsTzwj8zGZlbEzMFfESOhI9ja3DkLnNmDPmPz+k h42rs8+q+SXM2y5fcLxNsRLqCAyJgTj4Rf2o2FtWmwzsLzQZsjufmcMPHH4g+5kLoBqpyoCp/G+p PKUXnwhQk+PILfi2CfHhnH+nvHAz/GBWPgp0ZVgNcviBBe4vjbFkDfk31JBVMxUaHGN2YYE7+6dg hnbOTP8URJ1LHI30tfIY9VDpL+uZOXJqw+UdTml52LnUuAWb6ngRTVcGk6/359jBzbkC5zlXoBrw ahwpXL0iEq9WeyQT0srYIdCWmSCgBtGV6QNADWCPcY2BXJXgnOIaL2GEWSizUDbHa384RboeYeWh qmSCmLqCXrNGtkh+5vGC3B7DA/RFqzyPv0E4vSOWy4DXmE2IVBgHVBYHZN8c2qGhZxKzzCwzyzay bCwfglzL57y9WhlMiPBLUXwKTrV85thT1K0wuFJDWySSxgbNLjcWFhhkBplBthFk5IXItQUrFczs BE8mcHneWPlRDGwbh1NaMQ0Fu7I46Xi938s2MNvAbANfbbJFgT45vQPNRZlKpvI8U3nKaEzjOLBO eeFvwkhGf1xO5TiMxMoxK8c2KsctMGfVeCRyUG2X9BK5k4XZpVfZvrQZWjUOB9H1FgYuDsBcXGOl Txzu4iXGwQFiSiK0aeQGsCkPgyI5LHdKiClxThazzWzbyPYl4jOSU05msfQYHmktj/EaUczioIRp LR8Tm7N4YDXkN4d3aIUYhiYR9ImkSMXhmKb6h9A21gZyb5lnwRmReYn9dLpisTIVqh2AkBXVV02l 4CnD5CVaDOLLemmfFXhW4M+zAl+NAjWOZl69IqjcJ5vVaGEHujEJkWU1cvFYVrOstlFWXyblGQP/ QssUN175EaFgkduHGLZCyushk9K4yvhQIWIlv3EMDTQlfTsuqyFlkY2TWm4KaT2dlfODrI0z4Uy4 jYRfIUUbdvX+tCiOYvoNhuNRlkiVcLAqQntUwLy0Yzwervw4JKd38JJ/ff3VPfy58/lnt2jrn7fu 3sNcGaaZaWaabaT5KtFcKhrZA+Rq6aVnciz8BuX0YmVyDgfoKzk524sHOAYH0EtCq5DUlZCV8KXM Y/K/9a/i5cJ8oYS9zd4z1sivmD/vE8uEqjs/XMP/d81aOXNHovfUkfbM749b+PaIlTc2c7fTH7jr 8nS4fK6OO85O122fy/mtOScm0HZNgVyZWSR3d3RTqehQv43sM6WTo9161UG2rhiHZk4LBRhXOrm5 MiBljLqMqD3967I/9CrYx54y9pSxp8ymBJS2T0lsm7NqjZdRObOM/yI3TCsOkPPbbDgglp7rQxtw m9Eek3M0JKIVYXm8MjhMnu8slVYBZjGwS8tBXR0WLRClca20RoZ69DnEfG1FYPJZo2eN3j6N/mQf OaeeMZXnnMpTZnA1ToDrlBdOqWdirmBk1+XoSz0d5dQzRvuco101ZxuH2eoVEYyqQNLoHUVqCdRp Y28XSIqBhMpXUc9Cx9by1MEAB1Caiek5J8U7V1BNDOTWgsxEtFIJvQ6QkGJOle9TFR8W7JM50tJN 8LX8iMi+VO9lWd0wyNEAcIETzLndH7f7u22X1Y2cNIJ6IIFCLTwWiUER3lArgIwPqkA43GfIKTOP 5OacTCvTahutciQBUUvO632aQwbxWp+5Qh4tU6QqqJGqovftwz8mg0guHyFHWfmJXtymLNHBJA5W 3jaIY4S/cU7aMzqHpvxIIpfbizi/WgfQ0VfOpug8C2HtIGZkV1V3BXaXs7uc3eV2CW7o0oCxxqax 8sSIbMlIVu6PEunK3M7nZThJ5JrzNmQyaRxuoOe23rtLhSJo3D+/Zy4aZJuL8qLYRy8ycq0b5ZKc OZCPI0h6o2VhKCcW+6lL0sEE1AMsLNAT2G3OVjxb8ew2/7vL3dkVQFDfnHp7pfkqTSmCtyFgJS4E 2qmgPdCumq8G2r/God+1NrU0f3rNHGWhJjR1fO9U040C7be9PgT//earvD3VE3vc3eqAbtf92rt1 eAOfO/1dJIX8P7Q2XTcf9LCKfq5V9FN6nxvHBXfKCydPnZHdwhwdrRTTSwko5K+CKTkzVJl5JhZR PTbMGjhr4OdZAz8lMB816XJsyujb4t4MLMSb3hpud2RKJXQds3s9Z6D+Vhmo76jaREYKJZIWV5Rx DblMhnZ2VoYnxWysPs7FNSJsGrNp3ICmscyHRGKIhlOuUzdREZ/QimtqU48UjN5JRbHSuplippgp bkSKUa2d2baiV09WjdwiOqagulPtUakmDC/Dy/A2ILxiaVyMDcjoGGo3FLasObP72rRoW9nyrbsF jdUGmIK/6bLK/ETiKDUn25+uLBxUJrIsalnUsqhtQFFbeTol8zkRisDmtbTl9aeVqUWRXRTFFTic 5VCY4WV4Gd4GhFc/GILAvfXlvVtGdsnI9WIDZRhGL6oypmsOaKaX6WV6G5BeubYid7b+9b/vyExR zj5WcSMlg1lp5hAvG7qNa+iaE5qpWFH5lDksxBmWNykLlV1UfnfH3SOpKI3lokJ+BkoaRGFHK6E3 fkz5qqh2cbOvGhkaEipcpPp+mUNhMXnObCZ0sFeZHqikB9AJkAom9jbxSkx4xmOliWMc9D+/uvf3 v979F+ZBY6+xEJejh1RalR6mzdRyZTSITc7J5JzM85yTWe0j0DjJltUrMjsbmDAq+7jGpojkzBLI JOoZUf1ENnQ5weVLbDqz6dyApjOJ8WqPESW3IV7hspbhPZlJiOgCbY706pF47VmrIcn4oIiPA3Aq Z85E3szfsTqQWMK/Ogs+jfYmWgnzc+hgKqMeouaBquRZn1vGVC0W5SzKWZTbVeAMvdwIwts9CkLF 0qCW3xC5OFUrmw2LVCeE6viNtFRj4o+uG4hNY7Q0vcTsYICGv2rwNKnr2S252UfJ22Nh1Qu4EuxD CyM8ZsWAFQNWDBpQMWBxzOL4PIvj31W141DYyB3QqJ35fdQ1M9qM9nlGu+qiakin2Tv7b6t+X0p5 xshKubogY3PoL6SX+mnTbC6EDoGYnOdwKLsZajVUbDypz63rkUH5BB1/D+hYs/+QsdFvRHnKBrcn OdftST5O1lkCswQ+zxL496Rcq/AXFTRHtli5Zm8We7Ma0JullZa14hN024U3GhOr5FQO3TcVucZK b2XsEP5vy6udnEB7Tq1YxBQsOLPl4znZNyeSUZHs0/JDlL5iBriUMa36AcvdkBgs0plnFqCZo+2B nNogt3fuQMz3yY1RuZFWPT6xk0U/i/7zLPobWiFvQyNeY68fGKpOQtXe3vFKcNo4HBSpx/pKAk+h 9sMyx5NRFfdW9jfC3XK8QEtHKARLHSY2lhSsDPUrhqUP8JhL7g/KrcXepN43XPYqkNcOJ6jv/uim VkQO6wDFq5emtfxzZJui7ss4TFH7/91efTUGuU95rhjRgxah609pQmZqDZtysI+UhEzOyK2zZGfJ zpLdpgSWd7rVkeCm5ZeNjVWQrvLRoduDWTLYd7AzbkyVjae9cn5QDA4go41ILw8AbTE8IGcOGWqG mqFuQKhFoVwpTQJqZWVjCA8MeaaVaWVaG41WppKpPM9U/p6iXXIkBG85ZK5pFHMqGaeXcHqJbQMq XwWj6BRoFV2XqOBShFYrM4uWyzoaVAOl0TIfDmrkkb0Kxv7+1T0WxyyOz7M4buwIFJit9K9WJlZR GQlgEYpStIrCFvbrpX00+6zntzr+McbYMraMrT22bbfTH7jr8mBQoqvjjrPTddvncn6LwYvUBAFA i8SI8TJaWRyg/OxomsUstdjmwZDQC6udjI408qnu5JlSv9lMKaJSbs1RWkekiPAsUrdEaFvfLqHP GLI2mFAm9PYVM0+xCiMTamZofOH1BPy4J05/u9vd2iR+U0LF0z6tPCZKRSN7QE07S8/QIIBis1nK o0RvsMokWoKx5stOJpakdjqZlFeppt+ySco9dd8k9rEAbbIlt5FUXNWKi6bFoOvmOxzANdcvO5DY gcQGqT0OJNNNJMc3tFLpXZwqqcq0smxl2Wp3v3qSrVYQxnQikfvI7GKt3EcyGhR7aF3HlilbpmyZ 2mmZvvEa1bmM4EFSPiUmlKMwXI5vXzm+aaJS2dwIyulQdiMjCRHeUIIV5MpIjAllQplQ+wh9Z9kc O4vYWXSenUW/p5x9Nc7ByD3WSnvcoYoFLgtc+wRuW8sFhxx9aQztiYMwuk2Y5eYjGmrTq5uVTBD1 6GK5jH/NQUojojiKYQnoUaF8UBhDjCavb/75KTiKf43lQ5GNGIdhfWVYDVZDI9iZIXE4IbY3WJqz ND/P0ryhU/5Zx25t6vAGeLApDzb1nZgsYkv6xMlUXrrgEAk4rKhDjHJbqVLXmnSGSDXQPS5PaYrq KYwyQsmODA9rpTXzVWYyhumOVl0kxeELjDaV4RQVzu7uyZllkuAsklkks0i2KRvjZPjfqNSnfKQ0 cLVwyNAKqg5qE1AdDrE/L9d/ZNwZd8a9oXBHZzimkqlkKm2isu0yXGFVtdkIF6Aeoxpejh6KldFK f1k5u9T8YDWOVLVmlJM5FUHW94taIYmaPr2EKqFe+L3QmRXHvK2iy0wQTZ3hQ8NhSl2HBs7sM/vM vk3s/yYKOOogjMOMEX6Ozs0Osr2jaWP3sSym0FiDaWfamfaGop31bw5FcyjaxlD0lQsONfdEPo7A SU1p0+tPtcL8n8jbffhCbGyKZA6Tk6A4I21TTg6JpWd0kFkJ8SeU6svZDPbKyYM3IelP4AuTW9si MaEPzxo7MyKxoKLRSh5DEovcoJwagbOMRTKLZBbJLJI7uwIICz5ydrc2XWm+2oS2WgjnB3x3fGZ/ rXb13+rW1zj0u9amluZPrzXTjyfwnx4XwsvfO+l12Gy/7fWhTZff3PD2VE/scXerA7pd92vvxkFp ukt0j3x+d8fduqK76i5uikN3yPfhmuJchUvsrQiz2B+DG0wmsiKUJw/ZBCYL9orENPZjk0YbogFA uizHBzG/BLFrOZ8Xh/0Q4sdC01aLSTM0zQ4wVr5Z+bZP+T7ZAcYmMVPJVDYalafMBqkdbiVmQ1aH 83pxUQzDjI6+yQyp9K8bO7uVgyk2hNkQZkOYDWE2hI8Z8P6ujqoB397tcvoIknZvt9fX2uR8GPDS 5n13N/wG5pbpAPB4v/Y5e8yHj251uzs9tRO4PAGXTzkButwdrn86fdTBm1wN7cq5wIYw7pXpCThi 9psWsLpDH9AQvgZDOL2DAik4nNELFqN5MaD3SKO74qiRW1YWbs0pLVcXaDh3Moop3XIb1nFfvTBW ZrK+UqKh3YVDLZ+Re5sis41J3iK0JpJ5hzG6IDaSIjbIIplFMotkFsksklkkO9vdnk6IRud9KBBw kisdwopPvD+RqJQR87RQSnosidtAIvnTCw6tNKR6tqNZJbXeMl3J6IaHOWOQuJg89icVQYZbWqTy qHOmuHEmorq64wgIZyWZSURbTfT6WNayrGVZ21CytqY1n+6Bcnjd++wfSCtB8qU+uivWU3+Q/fNi b/aPWAcqUylL0dbTaTnDbQm4fSa3z7SrfSZHoLgtATu+zCQjXwNp2dfriqJUwgZqoYyViDiYEHMF tIeXEy8rE/CMPdfn1uETQ8ETDpD92/CVidTakeyR7JYcCuMAHAzpK1I5kRzGS+AWY52bdW7Wuc+P zi3iE1pxTe9fh859rPKJEsrUzAmGnqFn6BsKek744oQvTviyL+Gr7cZJCdcUcM4Wjd5RGhicna1M haBE66UR9PlSE9co4Bza08ojsj8kBnZJB5+ZFfk8+bpHElo5I4MrnGHNaDPa9qF9sn/rdA5tdbRy a6M9idyc0/IRsb2AEkh9NSb2gzCokdCpnNr1ejcr3HCpMP/Mf6Pxzwo3U8lU2kdlW0sz0kjyQbm2 UOvcpcaLQ6eWYzukeg8+F3ublPep0kuCM8Zerl7FVo5s+TipFSLk3U5O6OkoFHC5S3o6NS9YLrP2 zZwz5/Zx/v60b4dD6d/UXvdgVcwNWdMt5NqiVkjJ3T2xlXe8qapCfpmxyo09ObOEM0tsyizpdvoD d10edOFwddxxdrpu+1xOKrVBJvHJqwLr5Cyrz7ms/j2Nm7MmZiyt6MUtHjfHaDPaVDHSeCOqTrkm QXy36WtrsN31F/Nm36GgVgijGzes7ZqxzikmnGLCKSYNlWICYEGr1TIfcess2nKuAlutRPz+xeFg ZplZZtYmZtt+GnhSY1NPZ8kLPpkzss9E+AUCykgl0YoxeLXVMRC1yjuu5RMseSnE/ENr03X68bKa fc7V7MbTn6tXRIqxVowfEbJzRZlZ0yMF5IGxeGXxyuLVJvF6ssPZQUJXydrgCsakmx0KgCrSvbTS OMSueoyKKjm/xwizbGXZal8kuQ0pl2/cTfN7NV8TFGAMdlMdwGpp2UpPZpnLMpdlrk0y94hJa7X7 eRJHux+ZyVFDv5WEEqywapUPCkKWzF6zd5+MkGF7jGtkWYvNMRzzen+O0Wa0GW2b0D5ZnYY2LZLU YUBGDsyGX5ZQVsNdlWiuIawEtIIdKwB4R/OwSu+hCCXq/GBbUM+VEm4VbDD2jD1j31DYi3S65vOi B6XHemkQDyqLAyK3D63dCIZIWU/nteITEdqmYsoncbHfJ1JxDjpxgiYnaNqUoBl4o6ED0RqxeAzp LYpjwmytLXqnxchzrZg2A1AofEycuJ8FMwtmFsw2CWYCWYRfiuJTTH5T6rOWH1IO7Noe1bFXtS9g A5qd2ezMttGZXUv3IGn7JK50ZTyWuWT9dGUxEBLZAkxq5SEj4ZuKM7wML8NrM7ymlWuatVauliKU 2WQ2mU372DzZM82VhUzlOafylFU8jTNa5pQXXi0/KsZV+ZFl1ZotQtCOy+y51wtDmP1R7I9if5Sd /qinfVp5TMV1xeGLSnCOkjvMeVFaPiY2Z7GpgNVLzzAZijVnltHnXEZXKwUaR/hWr4ikKvmQTWZR daQIFZlVLU9TUvWVnJztRZqGEYyrkiNj8QX2y5dhcz9nY3EYl8O4doZx3yZXyVaadRxaxRA2rbRs 7O7UI6z2I5irlSZZ+LLwZeFrn9vqZOF7DGEa7hSdxTzzeorl0KpI5I2dH7VS6S9s9LLRy0avnUZv KozOtSIbF+OPYd9aOc8qM6NUNLIHVK1/GDKe9uLZymACD+TMglZ6yX1qWQCzALZXAB9zTqEeAXqz TO+AWTTP0fLPafRDZg6JkjKONOd1IGwcDmIABMPL8DK89sILWuGZwn9V8ZECVn8RkzMDxkqvKFMj eVWECFvXoQ9twLklRwsiOVl5hmZ2UbGxqWdiVLY0Bp9Whg1iRpqRthdpLV9USVVGbkcGKagrBrZF dhpsi/Ag27ps67Kta5Oty2lWrU0d3sDnTn8X/Qa5/VzH3dam5ubbV0yJgTvi87s77t7xnbDzc9d9 58PuwNvP3KnbRVMCeu746I+z498PMUjA3dkV+NLTYc4P8HucPfe8f/O5rc0eZ7vb04l3dd4PuOg9 qdEyrkGdwPeF1xPw07P+dre7tUlkY5jYSV+bCxMKbvndzvp9Xbc8/iMHtftbm+45u7wPnOqs35jn /uYzv/m33dvt9eFUj5zdrU03bly+3Gy+eTWu2jiR3jOmWeUjKs1KFRUZK0+MyBbZvdklfW6ZRTCL YBbBNolgChmpaiFVPAQqrXSqnRWxT53ZxeGUvkj9KM2sDUq5EsEnZlediJx4WZnYgcEro8t6MU8H j8+IJ+NibIGhZqgZahuhhjNKL65gcjAGiaP4XisOwMuMVllWTla1KB+8oyIfg8cZWAaWgbUR2Nqg UsWjSIbl1gK1wTKFLPXPWC47HOiFYwzu1Gc8UzXvchmyl5pczQ/KiXnkdiB2LMMpZpqZZqbtYpqG D6/8KMIDcjblqMw9w0xhsZ5yYIgZRhbHRCotNspib0srxBBvYlQZVUbVJlRP9kNbvSLr/1AetMkt DVMpxJDYwdwyt8xt43MbredWThWZW+aWuW0obrm9BidLnfNkqVOGTz/2uC96Oqu4r4otUR50MiUS g5REGQ2KPZ5mxgW/XPBrW8Gvck0Z2VUjW4RXqn58igK2VrKg7U/qK0Fgq/ZzhSBzy9zaxq2awW0h OtMvVqkMUM4syyJHfBhMBtM+MM25vTVlF1SK0AtU/Ok788bOKgb4ioNedjyx44kdT/Y4nrqRqX3X 5elw+Vwdd5ydrts+l/NbMwE70NZCGY65ae1w4fV+mOrrS0XU/WETHTHUuCHCebCI0WN6X+H1foRB ZpAZZHtADrRdAq5afkTLT6sC+z+gxRy1wcC0z/GCSA3TbLCBbX19nKYCTuaOyOS5or4Q/CPzy/wy v3bxe5mKBULb4rCfHuSzImp1i4T01UpDKsERT+mjc3KnhEor1Nof4xjmrtyOsCTmqNE5jxo1Xhlg 9Yqo4esVAjiLthnLmM0pd4cgiYOoHDL/SyM95figXH+KbKlK70g9wSI7C6bJcxWJyewuy2N2XbHr yjbX1VWiODygFV+gbkBEMaBzSCxtGjvLyhqu158x+w+tbbTDGSOHZs5sBzO3zK1t3F4jbkm8zqu+ c8dwRa854zCj1GcStfOYArjG0LLKzCqzjV2pPgW0+tYB8qHgptL711F+q7iVh0H4l98MNkkO03iE DLIzWMyymGUxa5uYvU5idmYaHVtRv2eGh8wCW6sO1yy8pfAQPMtz2wwri1cWrzaK13pjFeouUi9U piPIFetzqMEFoch35AAQB4A4AGRXAAj1eFT5vjJgDP6IsUNwAhsvITrjIjyFPdhPBXtP+4xQATEi bo3OIpVFqo0i9RitenQN/c7fplWky6iMZ1qZVqa1cWgVmTkjikDOcdkqcoNaafAC68GsB7MebJce DE23sjhcNVCnVajmiAU7n4cGLEcSGEpfmchWFicZWAaWgbULWC0fgTNYEUq5xvtJ5pF5ZB7t43FE YDTmbEwhCTblBkKopSN7Rg+ojKd6DEI1KMZDGQ9lORVH9dFVMTQHxxODzCAzyDaBfHITRm4Kxb6k c+5L+p01hdIgcF+Yg0We9mnlMTFXEKGSSnli+cvyl+WvTfKXJgFhmq1q9aR0aT2zj47Hik20saDZ 1ZiMiznWxaKMJMihnFkVhW1RzP/88fraqpGOMd1MN9NtJ911opaKATLByotJZfkS1KUSDOFa7jGt A9TnIm6O/UrgAOp8MbRRO0DfL+IAhpqhZqjthNrUoiGO0QcDwzQhmsX4Y4BM0rnuKdqPcSOhl6bg nmNsGVvG1iZsT/Z0qa6O9eYwhn+pnqyY7yWWHlOHKpErWDN0gyEIZmM16GCUGWVG2SaUTaM5mZOT I1pxSEZWjIW4HArLmX6mkqlkKm2kEqHdSv8qTatWjRyLT6iXY/GJsTuu2jkyoUwoE2ojoVBvqetb cUgNrgWwlKMRXYBryjg44PG1HPg954Hfahe1xhnzU70i9HU72UhFjKiGbW1gNVBFnxk2RLlDBXeo sK1DBcg0hvbEwQT1b9vYlI/Zx8s8Mo+28UgNyuGtVTaoctWyxckWJ1ucNlqcIrQnlgblVAwzKB1y BqM9XjKTzCQzaSeTSaQTDhgrP2r5qEjmZWZOHISYSqaSqbSRSq24gskb8PAgaMIwMowMo40wksc1 GxGhVXbqcEyEYyI2NlYiJ2t/GX27KX0+mYIZycKRhSMLRxuFY2WhKMLPRF07bkaSkWQk7UJSM2eg 16exQ1ZWFg6MqWEGk8FkMO0Ck3TXwymEPLRiTIaHUf0pY4dou404ZbXCO6HtT8vJIX2qjANIxX2c FOkDxpaxZWxtxFaOTdWqruXEy8rETmUwjvpOonjimYxGiej+kOidRqEYgikMLAPLwNoIrFZc0ksW s1VO5wGpSOYAKePJeDKeDYLnnxwOCq+Yo47JUP1xqDL1jAllQplQewjtdvoDd12eDpfP1XHH2em6 7XM5v73Y9meUpFCxtVKEjcNB1I0BVhHCJDdShMVBuDJ9IIdWqBfwk7iMD8r4MnPMHDPH9nAcaFON 8o95gtExX26PMZgMJoNpF5gQo2JrQkQS+nZJL82BUCO77qDBxjRoJthLLfSjQSQ64IGRXUJXMXpg 5j3wbGPOQOIMJHszkMCuVk7oS0Uj3q9UXZHbB7w0zGJvGVOi9HSeWpwgfmNSrPhmcplcJtdecivT SYrfTCdFZsPhEOl5OZOS42XEd0j2pqjDrtgfM2mO10TxsYRD5pg5Zo5t5Fik01CHj5m1PD/K8d1N BpPBtA/MkxsWqW650IXRZAz/1fLUyV6OFkRy0pxUTu3t3zS/L42T1mz20nY4uKERN1DhBiq2NVCh dtf6Qpa6duZj6OOJMK3xclsszQHRqjMqLtd/rMwsysOgiG5q+SLGPr4K9v1B5pJi6ZlxmJbry39k XzP7mtnXbJev2WyDlMI8VkJY5Pv1clY5qWAIY/QqoMYDmQ/JqQ3r8dM+GVsDxcwtc8vc2sXtZUhf GVnDLBkkWojQmiiuI9HCWHmsUi/0lV6RXWJK2eRlk9c+k7ftSs0TJefz8BiL9GJlco6xZCwZSxux vAosjewzS+lN9lFkdmBbXx+H8NRXUXHHyi27lti1ZJtr6Rr4rExuiYOsnMnIfIpwzaXF0oqxmxQb SeaT5SfLTxvlp1wIawcxER6Qs6nX+9Nqjqmeoi6h9UkTcASrMKyKvr7e55b3LFZZrNolVk8OwL4K BtmTy57c8+zJ/e7mN2aB2jef+c2/7d5urw/5MI+c3a1NN25cvtzc3IQnqsOVGmfc0ykvnErw9LU1 EVrXX8xDZ1a9KFSGBTPOjJ9nxhsP3uoVEZVqdjglQJSCWiFsPO1VVCpCmU1mk9m0K5JKeUxaaUjb R5u1aTmzbOR2fgqOinyfyBT1F7NaMUJ27GFIf8zDaNh8ZfPVLvO1jVKVCNT8c2QGV0EdcdB2eQTT MMRwmbKDM5HKVEoGV1iqslRlqWqXVFVthustULCpBonDY8xsMpvMpm1s5iPHvENgE91gIEm5To7r 5G5fMUOLuBE+v7vj7h1fa1Nz87Gdn7vuOx92B95+5k7dLmoK1nPHR3+cHf9+iL5h7s6uwJeeDtML 6/c4e+55/+ZzW5s9zna3pxPv6rwfcNF7kk8W16BO4PvC6wn46Vl/u9vd2iSyMWh9tIa40JDslt/t rN/XdcvjP3JQu7+16Z6zy/vA2Zie3npnEVy48BdVY6bTSmgqfxHjiS+ckx84+cHG5AfCsxiv4Smj I1o5WRlM6H0FtdPxUzBzvRkS9lLzT8EZdFMT4SnjMKWPrrLay2ovq712qb2mXI3UwFVlbtr+pAiF dYxTLe2LVFjlNDGnzClzahOnJ6cpqa4ux/xJLddgsiJtXx9b5mYQHJvh2IxtsRnI1hYZS8O1qxCt LD7WsxPGAqu8jCVjaSeWlxSWxt62GCxa8hNzNKb2KpObrOeynst6rk16LqXqXrZkZg59R5eVQWpk F0T4CUtO9vKyl9deL+8VBadYmobrVu72ojKcc+k5/nIsEsrhUTNK+97Cs/iBdbk9iCxX47r1AVur wuWqIlMrRSE2MbfRTAykxzLHo2vY4GSD006D85ql00YOYHAag8/F3iZmmWvl7VpfQQxIZsuTLU+2 PG20PD+1lNu5ggiVMJacMufN0eVKxdUK87I/x5QypUypjZRetyhNxQEnRpNrefT0RJ1aRCu9hN4r +0OMKCPKiNqI6A0L0YFtzK4wyiU5OYL8P+NwToQ3kP7HfDKfzKeNfLY0W/bo1oLITsvMHKpDxQaG USRE8oUySZlRZpQZtZPRau7Q2A66CCoo9aGcWOxnNBlNRtNONK38IZF6rK8k5PggLE+RfK5nYqhR k2sLDCgDyoDaCaiVQ2RENytPNrXChnLjMpfMJXNpD5fdqEi/6/J0uHyujjvOTtdtn8v5rVnMbvbn bLESiyrpAVScVdIv9cUhBS08vGhyD8cu08v0Mr320KsYraYY7Q/L3hwNIEbvzuKAsbsh0zvGYQbh UmOP46Oca8S5RnbmGrVYyUZa+RA5uvU9dQEo/EgitMeilEUpi1KbROnJtdw8coKLW855ccspJzd8 7CMnNAwON0dOWCJ4a64SRLISBhNv69slkUgaGxzKYWWZlWXblOWfBp7Us0npvtGg2FsxTdt1sdln 5f0Wi2J4Evn6ILcymtUKczgAm+hvRkMrTKVaK2eM/rKIplm1ZtWaVWubVOs2EC23FtDu3ojkkMBf WSjqYyHi2hS+DgeSnOqfr7Grl0bkbIbZZXaZXbvYteZBmcOgSMAqZHlAKtvF59wurva5bhyDt3pF VFpuilRluiaApZ4NisQYBKeR3TJyM6/34wpUeiqd14pP8JSaeszSlKUpS1O7pClhm4nIsbDCE1Ra wyzmijKzphr+glk1e5GFLAtZFrL2dVY6OSRE7qkXUyKzKnIFOV4gwfoihgGMWj5qNdV3OBxWklQS nV5eYsBb9QktXxLR1bod3AuYXc3sarbL1Xwy4NY8ONPQJbojBQDLoDKoDKpdoJK5K5JxkRoWyUTl abjmiAKfYq6oLwTZrGWzls1aG81aqlJH75fxQREfNxu/mJsbw3Ii+WZzvACEwazlnFpdEPtJ9UKe tMq2Ltu69tm6JGH1gyGRLgPJN4RWXVHSRJUdUgwpQ2ovpNQ6GJ5ihvTmI2d3a1OHN/C5099Fqp// h9am6+YDzOd10VRe7Gz3dnsxofd6M/1Pjen9xhsIeB/gOfMEHne3Nb2XJv5W9576tIjNBdpve32o pPRTl2l/V0f1XO3dLqev7lqcDwNe2rzv7sYHMLfMikuP92ufs8d8+OhWt7vTUzuBy4Mxw+oqu9wd rn86fVSjab6lGjncg0PNCch1I42ru7jr9wfu+g1JquXXWZLePztNyElnSO/y5PIzT07H4vfzrflN SIcQs8E81crigMjts9LL8jTQzvLUZ4rLE7UH8xl1h3wfbopGFdWY2JxlSBlShrTn/7N3tk1tXUke /yoqXiW1Oy47cZKZVEFtnGSyU7VT5fKmamZebSkg25olgpKUh91XwlggCcSDETZGPBsMNiAJg0Ho sWo/yviec69e+Sts9zn3CglEYmwyV5g/5TLSlQTS5f66+/T5d7fNYHtBWpc0sbxpYU5mUyR1qg1M ke5Q1+RgjwbLUl74qpUqlqX/5GUpCQ1pI+ZYZR01SjR3imI8IcorlFMCoSAUhLq4i9qIJ2+M7kSo B7hRGLOy29ZGhPitzS/o2/VImBrHsKQ4vVcvfKWqV2oxA5bBMlh2keWTqJJcmAUPpVmi1UzvybE1 Ippui+pmLbKob9dmK0ZxjRAWA8NAGAgDYbcQlssxozIiYkNyYcJDcFqZDStToGr18rQYHNfHQSgI BaEuEdpavi/Safakjnxfbq/Vnq9Cvg9JBOT7rsn3jUKKmLQlworM2pMxucR7rnrFa0Wi2qFyJ7ZC ikrraNdHZkkc/NwoFGqDZVri6pfzujeyTq+lGncxtEuDsoziQzpoLY9S42MdYYsHoxRAozk51IpQ K7qnVmztnqk41qPLYYlwsf2UVsPcrXz9iZ6/ruLsVSs7JGKbRH4T7TRyIJYzF9fEwQv6nx7lNhfx JHV44zW0HgytjAu6ONIuC+AH/O0IPxsAdu6Us1blQIr4F3Rb7k6z91dV9Tp8B8fg+MZ1dRFj27jD FfXV6U7c5liH7WJhRHtrqpYXFYr0x+wSP9W5FVkyZMmQJWurLBnTy1/siVPZWjQJgu2CoDOX/qBY IeTvQbGC+M2KFX7VB1vLG1alAoJBMGoC6Qy0nzz6VwmmjLWVKoFgEAyC25LgrkY1CDWr0ctemT6U U0nKYInYjFgd5hvbj+X8IKWtaeeK9qmwEOYMFgrzb6Ewn7owXL1qZ/NcSWV1ieg2EXqkDFHpZ+Sm kJtCbsql3JTqOpVZ5skEkSj5Sl2Pz250YpQK8+mGkeey3yNmkU/Gzi52hFx1o9canaiWcsCJwonC ibrlRD9qBFILKQAkgASQbgH5cSOQtdk5cyUJIAEkgHQHyF5vKHzLF6DWnL6em947vhtBn5cbaPIc PZ3W1aV9nNbNHuo1KGVwxQGX4TYVHtwft9YHjPISlShY2TUZGTMOYyKxgL7IEBtDbOye2Pg4xRph Zrm8xBUEiTUxmSCQaXgIy4sVxR56DABja6YHWzNNrbhc2pp5es8oT7+KjIpVnlNLWV9K/1r73J2V JoYwqjvDhPGrSBK+Fr4WvtZFXyuaUa0Nbui+rFZ1WKzu6DJccIrCHRTuuKx2aOaUYmIxnrdyg3Kv okttNbl6lctR8mBUDL0EuSAX5LYJubX5FV6vzsWpxF0k0kaZAmMaq7dlZecJWM0vgAWwALZNgHVW r2rdmh80yxlrP1pbYVq1nwWtoBW0ukpr61qcVxGMkEaLuPe6RRzVKatNz+++DKnvajQimWM1BvEP f/j446tqQCKV3wR5vkj7lOGc8Y3ztq65tSWim+bmEikxapszZvEZDSUR6ZXazCL74mLBylQgyYAk A5IMdyQZ4S4jz+MMjGKEJBRyJqvZBJJAEki6hSQL+62Mar6oPOXrUuzav1zrpB3X16U40ASaQNMt NFnir10kVcmZlVWjPMVx7GiB2qSCTJAJMt0ik7X+mky7A3n6hVmogkkwCSbdYvJIzq+G99Qdp611 UO5TzkXk3Ja1t1H3o7QK1ctRSAwhMYTE0EWJoVEYJa96Mm+rmwvDt8K3wre65VtV94eZMXM5Q47T TGfk0jC1EaZUkb5tFMfE1PPa8KicXyM/apSog8usfoin8qhxPvZdpU80i4uUCUaKCbIIyCJclUV0 cYrJTOeNwgOjumwUi6o9OHGt73GUvFgwlyONUbIuBaDdVHNzBAgDYSDsLsIqFxXdFdVBTkrlMyLx rD5Dj0lWvtkopKlHDEmLzfmIjI/QAC1CWq2G46SRIM5BMkgGye6SfJ0A1k0PrXiWRts5zlh7XHvo HU3QUsDqJwJbYAts3cX2E/a7sSHOM9Mku+Q49Y/Ri2MxtyGiB7Rrq1PQRn7bJnkqSc8BukAX6LqL 7qeM7kSMmk9QCCyrEZHY0ejKF8tcgbe/K1ZZOyznaXG839g5BuIobBdhu8jF7aLP6ujyjcyoeHif 01WxfVF4SstefYOSziKeVPWzDDkAZpeLwRzo/tQG3Z9+T9xaC0m5V2ZulfZY5lIyl/Z8YKY27BoB NSBaLB6KaFGvifm5ukWjei4F0R9iaxhbw9gadmtruHFEFhOd2bAyBW6qurpeSw9w7DwdNQojZvGx jE0axS0NtpjImqv0tEXAC3gBr1vwGvk4MXtScyVjE2JyBmyCTbDpFpusudL54lokLkee6RCZHSrg xDgsjMOyc+futC7+x9AD8pr19hLW8K7ITdbmItZTkj7GzXWdcxqViQh1cTN3ijTkuU4uBcfwrPCs 8KxueVaCl/ZlaX+H8JRzWSM/VZuuEp5GoQAwASbAdB1MMbRrbj+k2gExPmmO5TivtP6EDtYeZWor M7ZXBbAIgxEGux0Ga09qVQZFqUAOtPY4KqK75m4R/hTyJsib3JU3HTWQ0TkjYlLDadfwJMdpNABC XoS8CHndCnlV9Y4qitUR7hGoQy/M5wOAE3ACTrfgbNQ2sKTBaSWsIbXnc+STLBNWs2Ftt6qm2YFc kAty3SK3Fpnl0XTDq2I4J5Kb1voQVejIhYljCHPBjgO1bhdeD5HBL/gFv27xK9Lpk8Ik3cGfCJUv B8yNETGeqM3sy8xLoApUgapbqCqdknKix/gElsASWLqF5VHut44lvCW2ZLAl4+6WDK1EayuTejFK KSW9TjVTL3mFGl9/FUkYBSpZnXwVGaF6VU4JN3tWWtTqyNcozZjrkaPFa/xQRujl9+B04XThdN1x ur3eUPiWL9DjC/p6bnrv+G4Efd7/VlP3wpg/2dnR0xf+yhu6y1cnatB7LkkN+hnHOF70+ZPG4bye P6mbyZiZZXLjHo9RHuOubWPDtfklfex1aVQXEOiD+ulw3nDecN7uOG9nOKUN7ux9K5ulUVtAEkgC SZeQbB01U/mOGX9GQ3zshm3mi4q5tmDf8cjtJ/ZNa2/RvkW7SVSSp+9QG2S5O13f5vUAcAAOwF0C vOsYy7opuZEvUh0tI5peMveWxMQjNIpBt0V0W3Sx2yJz2uBmqbMxleXp/STi1B74oxa71OWYj5Tn qIlb49gQ+Fn4WfhZt/ysHq6nI2DlWNNibFHEHoNKUAkq3aJSNaLYEoe7gBHKDCgz3FVmcIhLZevF RcAIGAGj6zDKR/tyrgAYASNgdB/GfFQ+zgFGwAgY3YVRt+y2Mzkq40r5HNYKZ6BV8CKZg2SOW8kc roOrPduSD7NyL81bIIUUiQ50T2Cxc09usRQQlGIjExuZLm5kqrK4tTWRS4nKgSg9IlC/vvUNyERg i8DW3cCWO6HVCk/lUqmWPpCxGJH5178BTIAJMN0F8zq33365aY1uGKUs4ekR46NamQc6QSfodJfO T4hOar0tRh9qGj0es0JNzcqiOkgHxPZTkdmnNWlteNIs7ELugwwRMkQuZYhaV7N8SvzK2J5Z3Pu/ Awp/RXRExJ6JaO6Dr7w/+nuay1N++rw/2Nd3++tgkPxO+H/6fZ0doX5fb+9/hr3BcIeqNOdHgiF/ z602mPD85+7uXnp33kBPk9057VN8Hehpv8/woYebveZ2dB4PAQ8CHgQ8rgY8ra3oZ2RFzXRGLg1b mYrIzDqxUJPh4eYCXepIt/4W5OGB4brJ7Oy46ny0llbUPvhtsOGJ+ifctH/Sv/v8d+6G6Xk/ens7 O65f/YQNGv3acNB+Bv1iutft3PsLPfWnzo5rVz/79Cr7ZW3Te372akMY7r7RF6R2IiH1qr5+5wcH /L36Cb2+2/XfhvYafJb4HCn/1/A3cg41uUTn4Fe+294fesMnn36z4ZD6yfqP5u35+w/U5oX/zn8K 9CifGwp4+7/t+ybot+/2e7v9gTv0C7y3wz6+WGy3pn9A8I99gXCIHw11+/2dHSIzYpSn+K/vo/4x X4T83sZjd78IhJqe1B3q7PjWe7fve3WN0LWlLq326ZvhvCO6mLt0F9d61YEuvQWSWIPw1X4ySnUO Asm3Ngl0Cu/6A2TNHFtiOyDH/3TxLrVRXTaKRY/9ZWVWxXj2dx5reUPGt35nvRy3skOvSzF7mMHi oYgWRfZQHKxxUZ8eP53bkfcXqSj3dSkOnIEzcHYppdDF29kyXpUjUWvvyRHUHxj5glGMGIcxNZC6 YORHxM5C4xM/BLfgFty6xa0a+xXdpSQ9ASzyGZF4pnu56tFC7H6Vv6UBJWZqUe4VGyf2wfFSmAMd GXRkLurI1Kb4w+cyt8czhJLDVnVAxdNErm5OJRYL5nLEqs6QB6ZR80Z1vjY7h3gZ2AJbF7FVu+XK s4ronrX/xF4D15e7Mp6ksX4ykdDuV5SnyCFzG5t8hMTc+jVwv3C/2ARydko4NW5nl84vs/2raSze NRcTMdrmoYyUiO2LwlPH/Yood9Tgx6Nb1AxS3xClCHwvfC98r4u+l/dotVuVuZTMpY98b93BWmXq ufxQxO8BVsAKWF2E9fcEq93WUckqaJVrlKtisuyhWFnORcwiF2jYM+uppfJyDMieCdm3kGsEG8Ul Z349y1Aa9SShuz0UZimhCsn0vEFOBnf39faRYMH7Q7iP797295KMRd1TQodA31+C3n5188cvev13 AvUf4AuQ0kHLHO76e3x/9gZ58I36lVr1AF0GnauTW96uRM+tJVSvIpFLtCdUl1B91xcO933vXMj1 w02s2Ud/S4L023hPCHLEB41Cpmbdkm1qnNN+VX01ahXoXPez5eDvtiGxlXSMzAXU7J3ZXv/0+WVT 94GBq0oqSNf8W4v6zgE9wgse4kKOq7PNKFlVHbn9UX1pp3Jq7Hahqft7t+NCuhtC0HPPR6qQ9zv9 /5ch9V2Fys4vP/JfPNvQOfrRdX3qQ//7Jet9Vaitj70L4e8sG6a3clIj+Itz+t7247EGWCbWPGIi 6RHpBY+Mr1+iEPMtPP6bBKNn/rF0sb3pwg8GRBP72xiQ985knMsHYiNhZQ9EbsgorpFQkQwG2QtS I4uhqMgcivHJGvUfGN7t//nKHW/fbW/gzr/d7vv5e6+/90p33/ewJ+0sY7x89sQf4KzabX8wFP4P f8D35V1vkAp2rl2jyL7xeGfHR59e/w3rgk5dX1/c+OTcjI0YvycSS1a2UluZeV2afRVJNBkRWnzR X8rNVN2pfzwnbGSTSXOWaIAwNRY0i+Pc6CG6UZtf0bOFZSJCIhaRWZCxGSuzbRYHL8oHPNvVyafh VWSk6cPRKXo/8kX1TOQFzwJdPhfQhsHjT5//QDZNLUBDVJra6+Mw17EmjIxdmtquhu/N7MIvfko2 FjRSoPZoj2z+f7X6EnM5897hsUdhXBBfqm34lmg4By92xeqp8cabYffe2RHnA7HJoGDRKM2K5LRR TtKy1FzPHTMQrSzJ17w6PfV5MCkwKTApJCy5WPnx81t/Pr1HSS1zbUMmtsQq1w/JuS1Kj1N2vNHO GHkyOKMksnoVuUf5MblL43THTjUqTWYIFgYWBhbmslqYXmojdMsXoL5Rvp6b3ju+G0Gfl9V4HM5Y AykacmgUCicMiZl6aWXnTxwmu2KUlsw5avXRetUEWwNbA1tzWW2NWiBRNp37DE9yNr0xDrEGRkVi +dhBGR+hsY7HDrZaMMGwwLDAsMCwwLBwn+dL0xMU+0XvLPB7P/WJ55d/Ufv/iFguWbNhGBYYlpbC 53MzLEZxRm5VqMuxKI3TAucfD5fNsRwNXqHKOrotU1nK+erbVnlL5CewwsEKByucS7vCaV1kRblZ OX20yUx3qU+G3oW29g7N1AZZFhHdsTJHiRURHWyeE8OKnveiaBIiuO91QQKK6rGoObWKTOlUVodp hxgRBSIKRBSXNqLounZFpvZFLGftvRTjeV1JRdMe5EBWTJB2ZFTGJo3iFpVamVtb1NJS62HFg1H9 fDvKcLaIrWraWh41lzM0IeJ1KQ3bAtsC23J5bctHV8TcBvXRpMIpEU+S9RCTtBaxTQp3uM5P0WLF LD52jAnXbepaK7F4yHVIs/e1MRHDZXqhkU9QxRK9UD/KxiqWk6PDojQNUwNTA1NzaU1N68SIx0P1 4WI8YWWfmkVu+0sGhG3RXE7MRziGOciahapIVxCrnKkRYT3H0tTyDF0m7BbfrJu0y+Paa/Qjqnac ksbmnjqcDfn4itxeJeNgbowYh4s03o5NRyYuxx7onqbUWoICEo5etlas6picXyP5q3iwYWVXyMKY qV0W3I89kCx7xcLHi2gE0ciljUa6rl+h4Vs0AbNuUnixUywa5Wnz4WTtUebIjIzQBM0pLaQXE5N2 skVZFarhwaLmzc3ImaMPatjRts2RL3SDvX9qMwOn8Jb3L9u8I4HzVinaaL1cQTtl8hit1xb2UTqF b9qX7swNyd8r5s6hp6tDFH9/f5UB9cvtTfoo4irsUXvqnCygnjC0mPLepib+nR1utCVzzKlznV6Q Jlymmo1B42tIl0OLSGs/au0nKDXVFOud5bOcA+q8/v3Xt34D76wRpeuoVXfZU0SWzt+d37QVoT2B pFGM0j81EahgFIasSoUm8LXBKb3SdEphR8NO9gV29Gx29BwQfxsreQ6/9tRY9zKpDxFjXFfJsIuX F3d8zdvQ46Jb5E311CJ3gxnP8mzakXhtutrkjBBg0B7NGwQYRnlIbwXIkSmRKbt9DhFRID8QvsVp yz8F7BAi4O3/tu+boB8RRROciLYRbYfejo13dty/VHdwQSMK2psSsU2KK6gG2jhcYikNFR3NZK2B 59Rirg3W2hcyfUFn1Rp+Lg52jp1VUd00Dtshg3Ehz6p8tKIaITZdsaTp0AdbnnB5f9ZaWmmDyxgB HgI8BHitt0eRMgIb58IGArzmoaG8k8Ipo50iSZZEddAceEmuUBQLVqbStKhC1ujNskZqKypSWz6U uTxFHebmE3GwxqeU/t9oHj7jwilFjAE7ei529Bz2hzhN8/8CAAAA///EVU1rGzEQ/Stmz6VZxx9x TddgY/oBLRjHkLOslXfVyqtFku2kx54KbS/poZceSyGX0lMpgf4bb39HZyTtsnYCaVJoDbZ3pNnR mzczTxM1eLjpqwZ8NY+nExUFYThqd1qjTmB3vMMjmRkNXoxoM9ScREHx9e3254cA1qiOghlJ5ZIE B/gOlUJixDURGA0/uHEAZ7hopnG6FH2dE8qiIFdMM7VmwaCBLsY52t/c/hrq/ixSU0GtAb0WvV+c 7WdkShDqCeNJakqg7bDjUVYecDAAoh40PQHXTRQ0w6NuiHmbsxzwx6c+bUNHUsVMafuWzMvAGReO F8EW1WnV4lwaI5dXfFUdmndGdupn6DQu36OCEWVrgdxHAVkZieaCC6iBtWxpMnmiSG4f10PBk6wM 4GA4nCmP2XOiXrqalfljPrZH/pD46ZgtyEqYq+6T2hJylTuCSfxipc0UE3+axRajzkg+k48V9yZ0 DM8SAEIWhmFhHWBfUVU2KdGU83qHXte16TDTO063bGOohgdeteSN0/PXwCD1lGfAaZmRI+DmiRsU ny9+ffy+/fG++PK6+PSteHOxM23/XgMG9+4M4H/SaKlzNG4vL4vzd3fOoixhvVFv2YMol/d3AGBX 7qsm6sZc2Emrz3C71ekNR6gSdqxr47q7Y8d13GqOO6G9EnzXo3y7YRQ8Ax08PLSiiMZ0JWCBmGeY InZoOSsO3aavGTWTamxQDnaPPIb9fZFIjl8BVNTf5oOwi7BTeO72Wj03A3kCmgWrRuZRcOTAWBWt LKdxlYlyXBkpIyDdYIY9DL2Q0gqMN5OVqesNjBvehf4CQx+rVrGkKFWIwd4MSIXGaPgw4YYC4BZc HY4Qx4HlZi7jM/sAEVZLlpnBbwAAAP//AwBQSwMEFAAGAAgAAAAhAMccbRScBgAAURsAABUAAAB3 b3JkL3RoZW1lL3RoZW1lMS54bWzsWU1vG0UYviPxH0Z7b2MndhpHdarYsRto00axW9TjeD3enXp2 ZzUzTuobao9ISIiCeqAS4sIBAZVaCSTKr0kpKkXqX+Cdmd31TrwmSRtBBfUh8c4+7/fHvDO+eOlO xNA+EZLyuOlVz1c8RGKfD2kcNL0b/e65NQ9JheMhZjwmTW9KpHdp4/33LuJ1FZKIIKCP5TpueqFS yfrSkvRhGcvzPCExvBtxEWEFjyJYGgp8AHwjtrRcqawuRZjGHopxBGyvj0bUJ+jZz7+8+OaBt5Fx 7zAQESupF3wmepo3cUgMdjiuaoScyjYTaB+zpgeChvygT+4oDzEsFbxoehXz8ZY2Li7h9ZSIqQW0 Bbqu+aR0KcFwvGxkimCQC612a40LWzl/A2BqHtfpdNqdas7PALDvg6VWlyLPWnet2sp4FkD26zzv dqVeqbn4Av+VOZ0brVar3kh1sUwNyH6tzeHXKqu1zWUHb0AWX5/D11qb7faqgzcgi1+dw3cvNFZr Lt6AQkbj8RxaB7TbTbnnkBFn26XwNYCvVVL4DAXZkGeXFjHisVqUaxG+zUUXABrIsKIxUtOEjLAP adzG0UBQrAXgdYILb+ySL+eWtCwkfUET1fQ+TDCUxIzfq6ffv3r6GB3efXJ496fDe/cO7/5oGTlU 2zgOilQvv/3sz4cfoz8ef/3y/hfleFnE//bDJ89+/bwcCOUzU+f5l49+f/Lo+YNPX3x3vwS+KfCg CO/TiEh0jRygPR6BYcYrruZkIE5H0Q8xLVJsxoHEMdZSSvh3VOigr00xS6Pj6NEirgdvCmgfZcDL k9uOwr1QTBQtkXwljBzgDuesxUWpF65oWQU39ydxUC5cTIq4PYz3y2S3cezEtzNJoG9maekY3g6J o+Yuw7HCAYmJQvodHxNSYt0tSh2/7lBfcMlHCt2iqIVpqUv6dOBk04xom0YQl2mZzRBvxzc7N1GL szKrt8i+i4SqwKxE+T5hjhsv44nCURnLPo5Y0eFXsQrLlOxNhV/EdaSCSAeEcdQZEinLaK4LsLcQ 9CsYOlZp2HfYNHKRQtFxGc+rmPMicouP2yGOkjJsj8ZhEfuBHEOKYrTLVRl8h7sVop8hDjheGO6b lDjhPr4b3KCBo9IsQfSbidCxhFbtdOCIxn/XjhmFfmxz4OzaMTTA5189LMmst7URb8KeVFYJ20fa 7yLc0abb5mJI3/6eu4Un8S6BNJ/feN613Hct1/vPt9xF9XzSRjvrrdB29dxgh2IzIkcLJ+QRZayn poxclWZIlrBPDLuwqOnM8ZDkJ6YkhK9pX3dwgcCGBgmuPqIq7IU4gQG76mkmgUxZBxIlXMLBziyX 8tZ4GNKVPRbW9YHB9gOJ1Q4f2uUVvZydC3I2ZrcJzOEzE7SiGZxU2MqFlCmY/TrCqlqpE0urGtVM q3Ok5SZDDOdNg8XcmzCAIBhbwMurcEDXouFgghkZar/bvTcLi4nCWYZIhnhI0hhpu+djVDVBynLF 3ARA7pTESB/yjvFaQVpDs30DaScJUlFcbYG4LHpvEqUsg2dR0nV7pBxZXCxOFqODpteoL9c95OOk 6Y3gTAtfowSiLvXMh1kAN0O+Ejbtjy1mU+WzaDYyw9wiqMI1hfX7nMFOH0iEVFtYhjY1zKs0BVis JVn9l+vg1rMywGb6a2ixsgbJ8K9pAX50Q0tGI+KrYrALK9p39jFtpXyiiOiFwwM0YBOxhyH8OlXB niGVcDVhOoJ+gHs07W3zym3OadEVb68Mzq5jloQ4bbe6RLNKtnBTx7kO5qmgHthWqrsx7vSmmJI/ I1OKafw/M0XvJ3BTsDLUEfDhHldgpOu16XGhQg5dKAmp3xUwOJjeAdkCd7HwGpIKbpPNf0H29X9b c5aHKWs48Kk9GiBBYT9SoSBkF9qSyb5jmFXTvcuyZCkjk1EFdWVi1R6QfcL6ugeu6r3dQyGkuukm aRswuKP55z6nFTQI9JBTrDenh+R7r62Bf3ryscUMRrl92Aw0mf9zFUt2VUtvyLO9t2iIfjEbs2pZ VYCwwlbQSMv+NVU45VZrO9acxcv1TDmI4rzFsJgPRAnc9yD9B/Y/KnxGTBrrDbXP96C3IvihQTOD tIGsPmcHD6QbpF0cwOBkF20yaVbWtenopL2WbdZnPOnmco84W2t2knif0tn5cOaKc2rxLJ2detjx tV1b6GqI7NEShaVRdpAxgTG/aRV/deKD2xDoLbjfnzAlTTLBb0oCw+jZM3UAxW8lGtKNvwAAAP// AwBQSwMEFAAGAAgAAAAhAMmg4yFeAwAAwgcAABEAAAB3b3JkL3NldHRpbmdzLnhtbJxVTW/bOBC9 L7D/QdB5HevDdgIhSlFHdbNF0i2qdu8jibaIkCJBUlacX79DUaySrtst9mTqvZnHmeHM+PrNE2fB kShNRZeH8UUUBqSrRUO7Qx5+/bJbXIWBNtA1wERH8vBEdPjm5vffrodME2PQTAco0elM5GGvukzX LeGgF5zWSmixN4ta8Ezs97Qm0084eag8bI2R2XI5OV0ISTpU2wvFwegLoQ5L51mIuuekM8skijZL RRgYDFi3VGqvxv+vGl7VepHjz5I4cubthjj6meWU7iBU883jV8KzDlKJmmiNleXMpcuBdl5Gs1/R cfW8p5UCdXohcoPP9iwED4ZMElVjQfHNoyhcWqLCy7ERCvFRmLJXSvRdc0cAsR/SOyHMRGPYYl8a MATFtSSMjS1UMwIY/JAdFHAO+OQOGSUbsoeemS9QlUZINDoCpneZTAE1CgYUea9ocycUfRadAVZK qBH0xnHsjamWDE6zYTF7v8MGP3mPxGXbOPu/iTK0BvYf1nULCmrMdbr+FmNRgnnNxtbsVnCp8OWc Pna9BGPr2muye3cPJ9EbzHo5ZDOFY9doa2MPn7GYXjCKijQu1lNulp2ZNEm3q9Td8h1TpJfF1Tlm lWzi9KzPKl1fvd2e87naXl4mm3PMdrVOt+tzzI+jLrbRroitD1ZgyptndvY+qZtrd9phVQPuuuAW eKUoBA92OtGLZ5V63NLO8xXBLUFeMmVfeXKxcITmwNgOX84TOJiOsc9fkP0ozB5AHWblseg8U2dR bNkP39TsABH1HidFOtVBgfyzaxD2F8ar1aRHO3NPucd1X5Xeq8MhfUHh2P11VFZwORdoyAzuVWIr dA9z+5Nu8bW040VAm7eaQh4+t4vbj9YbG42p0q5j8gBSuqGpDnEeMnpoTWzdDH41oB7Hj+qQTFwy cvhlufEDapssWk8Ha+COaDUdZiz1WDpjK4+tZmztsfWMbTy2sVh7wkWFq+QR154/WnwvGBMDae48 mIf/glwRdAuS4FPbTYOzJrIRmFaPDo4ZecItSBpq8J9O0obDUx6u42TcE5M1Lhac3le2Vskay1do 0IDBN3B9/sp57PvvYhmyhtQUe7Q88WreJhcucEa1KYnExWOEwpTH5fjH2Bfzn+/NPwAAAP//AwBQ SwMEFAAGAAgAAAAhAJa1U1VDAgAAQgcAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWy0lEFu2zAQRfcF egeB+0YUbSuKETlw3GiZReMegJZpi4BICiRtNQfoqquiy94hPUCRnqYBmlt0KMkKYNeIhKQSQMB/ qOH48c+cX3wSubdl2nAlYxScYOQxmaoll+sYfZwn7yLkGUvlkuZKshjdMoMuJm/fnJfjlZLWePC9 NGMdo8zaYuz7Js2YoOZEFUxCbKW0oBZ+6rWvViuesvcq3QgmrU8wDn3NcmrhbJPxwqAmW9klW6n0 stAqZcZAsSKv8wnKJZo01XnlWFIBVc9ozheaV4GCSmVYALEtzWOECU7wCFb3DvHArch3GdKMasNs uxHX8ooKnt/uVFNyY+pAwW2a7fQt1ZwuclaHDF9DYGMWOEZXAcaYJAmqlSBGQxCms1YhUFT9nDV7 Bq0C1wOFVXmqLcFZlQcUyNN8VdXp1/dzQOLh192f+x+P3z8//vx6BMcl4HAYHI5q/SeOKHwdHJGr mkSnTzhIhJPBbEQapcURhM/gAI5BTxxzLpjxrlnpfVCC1s45NAjBIRAZAQ9nlEEvg+gqb2WorgZx QKatHeBiZ6CcRsNgnwjuYJA6T3eDzGkGFR+1Rlj1iEPhzPH/O4Vc7YMI8ehyHwR5DkQAzuhpjYe7 L7/vv1UgaG6vYY7sevuGi5uNbJr+YJoEYBYMJoEj67dH+9CNVU3ebsMETnLPoAECXiFRlDhpH1GX 7sGVw7p7ZUYFTNVjZnHdUneN655+ZunfNVP3p8EtTyTcWMV4eGCWls1LxmozX83kLwAAAP//AwBQ SwMEFAAGAAgAAAAhAD1CZLZLAQAAwAIAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbJRSyU7DMBC9 I/EPke/UAQQtUZNKVVUuZREU7m4yaSzZHst2E9KvZ5oUKMuBnmZ7b/xmxuPJm1ZRDc5LNCk7H8Qs ApNjIc06ZS/L+dmIRT4IUwiFBlLWgmeT7PRk3CQNrJ4hBEL6iLoYn7iUVSHYhHOfV6CFH6AFQ7US nRaBQrfmWJYyhxnmGw0m8Is4vuYOlAikwFfSerbv1vynW4OusA5z8J6EaNX300IalpHGQtZ+b6Mm kQWNOBoNhzfx1eWwA6ywaGeypmItFFUZ38G1cAsow0c2/sw+yXX1R3qJ9jd2iiGg/pEnQdPC7d4I XxxDq2UE9NuU0QHIsSKnZXd+jgppsWITsJehDpQdx1x9U3Qc1x1OfgyVd1fohu7dbNzb7jBog9Ry C3N0U4eNB9cdgD5E+2Be7xZdJJTC5vH+lgKiHvy77B0AAP//AwBQSwMEFAAGAAgAAAAhAGKvstKB AQAA0AIAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAnFLBTuMwEL0j7T9EuVOnBQpUU1eoaMWB3a3UAGfLniQWjm3ZBtG/3zGhadDe1qd5b+zn N8+GzUdvincMUTu7LuezqizQSqe0bdflU/3z/KYsYhJWCeMsrssDxnLDf5zBLjiPIWmMBUnYuC67 lPyKsSg77EWcUdtSp3GhF4lgaJlrGi3x3sm3Hm1ii6paMvxIaBWqcz8KloPi6j39r6hyMvuLz/XB k2EONfbeiIT8d7ZjZsqlHtjIQu2SMLXukc+JHgHsRIsxc0MBLy4owvOLG2BDDdtOBCETRciXl7cL YBMC7rw3WopE6fJfWgYXXZOKP585FFkA2HQLUDZ7lG9BpwOvgE0hPGpLXq4ugQ0VmQuiDcJ35Ogq Wxwh7KUwuKUIeCNMRGAnArau98IeODk9ViT4Gp987e5zRl9HvpOTOV906vZeSHJzvcw3nyaetGBP waCiEY6CJwIe6F2CybfSWduiOu75t5EzfB4+KJ8vZhWtz9COHA0+/hz+FwAA//8DAFBLAwQUAAYA CAAAACEADUPjaZEBAADmAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAfJJNTsMwEIX3SNwh8j513PJTojSVAHVFJSSKQOyMPW1NE8ey3aY5 BJyBFUdgxXXKOXCSNm0QYueZefN55tnRcJ0m3gq0EZkcINIJkAeSZVzI2QDdT0Z+H3nGUslpkkkY oAIMGsbHRxFTIcs03OpMgbYCjOdI0oRMDdDcWhVibNgcUmo6TiFdcZrplFoX6hlWlC3oDHA3CM5w CpZyaikugb5qiGiL5KxBqqVOKgBnGBJIQVqDSYfgvdaCTs2fDVXlQJkKWyi303bcQzZndbFRr41o hHmed/JeNYabn+DH8c1dtaovZOkVAxRHnIVW2ATiCO+P7mSWzy/AbJ1uAldgGqjNdLz5ev/+/Ni8 vlWNu2zp9wKKPNPcuN5W5Jo5GKaFsu4Va3Ir4dQJNXbsnnUqgF8WsVkUpNurOL8q5UUaVqL8EHGt aEK3VOVhPStwz7kS1h7uKg+9q+vJCMXOmL4fXPiETMh52A3CIHgqF2r1ly7ViXQ72r9EcloRTyZB P+ydtYk7QO1N+2fGPwAAAP//AwBQSwMEFAAGAAgAAAAhAP/H+6V1BwAAgDoAAA8AAAB3b3JkL3N0 eWxlcy54bWy0m81y2zYQx++d6TtweHf15ciNJ0rGcZLGM07qWPL0DJGQiYYiVBKK7dz7AD33HdoH 6LRv05nmLQosKJgiRXFXZE4xP7A/LHbxX9rBPntxv4y9TzzNhEwm/uC7vu/xJJChSG4n/s3szdH3 vpcploQslgmf+A888188//abZ3enmXqIeeZpA0l2mk78SKnVaa+XBRFfsuw7ueKJfraQ6ZIpfZne 9uRiIQL+SgbrJU9Ub9jvj3spj5nS8CwSq8zPrd1hrN3JNFylMuBZpme7jK29JROJ/1xPL5TBK75g 61hl5jK9SvPL/Ar+eSMTlXl3pywLhJjpiWsXlyKR6duzJBO+fsJZps4ywSb+v//88d/ff375/dcv f/1mnkTmlZ1jgkwVTL0UofB7Bpd91sM+sXjiD4ebO+cGv3UvZsnt5h5Pjm6m29P4HB2dvze35tru xGfp0fTMGOuBj5t/C76utjzXVzCVFQv0qmkzbKG4jp4OhjEaCxPl4dBdXK9jfYOpS7MQOQdsaF7R sr4srbiOq47y1GaJfsoXlzL4yMOp0g8mPhD0zZuLq1TIVKiHif/0qZmDvjnlS/FWhCE3SZnfu0ki EfKfIp7cZDx8vP/hDaRYbjGQ60RpD8YnkAVxFr6+D/jKpJg2nTAT4fdmQGzMZgUOTGgtHmdjb5So cPOXDXJgw7iTEnFmtpEH898LAq/XrUFD41HRAbBLmuuovYnj9iaetDcxbm/ipL0JLZ5tI2Jzo5CV +KAqGdjkK+bE6OmelDUjKlnUOKKSNI0jKjnSOKKSEo0jKhnQOKIS8MYRlfg2jqiEc++IgIFwlbNo BKuB2tgzoWJuxu8VoEFLqcurjXfFUnabslXkmcJanvY+sZyu5wo3VZDTw8VyqlKZ3DauiC7QZuse rMmvl6uIZUJ/0TQsva20h4NmbB5z74dUhI2oJzb5Kj7Bt8nOEnYVs4BHMg556s34vY0oYfx76U3t h0bj5FqG9VLcRsqbRlByG2HjmnyvXwlr/1Lob6CmiI5rXGkyjorhuCYv642/46FYLzdLg/gaGVs9 J4S5hIAp7tWb8bFZxWrSN3phAoBxwZYLugtgHzF/W1zo9k2MMfO3pehA+4j528J1oH3Ij/3xJSvN K5Z+9FDb64S8d89lLNPFOt7sgcYdfELewQ6Bc4G8iZ19lEickHfwlnx6Z0Ggf3PD5Ck5Fo86SqCQ w2EpsNnwvpCDUpK9AcEjcoBKrCGB1U5rCSCy6F7zT8L84YlaDECl3bdm43Ye1ayALkGob+gPa6ma v6GHNZqHpVwk+s8lGfdwtFHNzsPS8nyy9Y4Q43aFjwBqVwEJoHalkACqyY/6bx5XE/GQ9sWRwCLL sqtikHZoZT4hK7MD0UpAR3UT8f1Vs3vrc6FaNxEUcoCqdRNBIUenVMtc3USwOqubCFZN1aiPUVFT KU6R62YR5L4EEB51I94IUDfijQB1I94IUHvxboZ0J94IFlkbnKYWxRsBglcov+o7UFG8ESCyNli1 y/9mtKl7YGX/L7cdiDeCQg5QVbwRFHJ06sQbwYJXKJlQYjmpQ7C6EW8EqBvxRoC6EW8EqBvxRoC6 EW8EqL14N0O6E28Ei6wNTlOL4o0AkeXBgYrijQDBKxRt2CnesOu/ungjKOQAVcUbQSFHpySo7iMV wSIHqMRy4o1gwSuUZMhZkNwUp7oRb4RH3Yg3AtSNeCNA3Yg3AtRevJsh3Yk3gkXWBqepRfFGgMjy 4EBF8UaAyNqwU7xhM3518UZQyAGqijeCQo5OSVCdziFY5ACVWE68ESzIl9bijQDBK4eCKB51I94I j7oRbwSoG/FGgNqLdzOkO/FGsMja4DS1KN4IEFkeHKgo3ggQWRt2ijfska8u3ggKOUBV8UZQyNEp CaoTbwSLHKASy0kdgtWNeCNAkJitxRsBglcOAMEuooSpG/FGeNSNeCNA7cW7GdKdeCNYZG1wmloU bwSILA8OVBRvBIisDeacrT4vij6eOqhJAuw5g82pBjRwWBMkLDB38JoveKo7mXjz6ZCWwI2HBGJN emBdfCnlRw93sHtUkyBolJjHQsKR7gc4pVNoRBid7OkkmP147r21DTCVcZBS2ydvdPdQsV0IOpRM 45Cep3pY6Zad1eZkubGmG4RMX1feAgR9aBe6IYhBx49p8dHvQEtV3ugD/2WbA+Fn3e4Wbt7p90fD 0cvjkXUmb49i4c/rTF2bQ8UXyeOr9p0sYauZhJ2ac/r5A9dUlbdRHcN/FZmLvI1qraR51fZOQQea bcdKtxrRJv6MRXLJjK/QZeZu2LG6lw1sgOfVtQoivViB7urat1b9ymLVHOKHBXvsINksW36Y//GT z763daTUzrZmlsocXN83w0FlhjacHhx5tytenZduIYOZNE3Mnf2Ct9U8toHQP9iA6xZECJ5Nv/Ce WbP6+TmP43dMR0Dnplzp9ah5NeYLZZ8O+lCzS6bmUim5rB+fwpF2ML/LgM6h4mTs5f7ESNbLOU91 T9q+ZR/uWHZ7MtdG2CnAJhOwK65nmKfC5qfs+f8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAN38lTdm AQAAIAUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAA ACEAHpEat/MAAABOAgAACwAAAAAAAAAAAAAAAACfAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAA ACEA1mSzUfoAAAAxAwAAHAAAAAAAAAAAAAAAAADDBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwu cmVsc1BLAQItABQABgAIAAAAIQCwwnxQhkcAAHt2BQARAAAAAAAAAAAAAAAAAP8IAAB3b3JkL2Rv Y3VtZW50LnhtbFBLAQItABQABgAIAAAAIQDHHG0UnAYAAFEbAAAVAAAAAAAAAAAAAAAAALRQAAB3 b3JkL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAyaDjIV4DAADCBwAAEQAAAAAAAAAA AAAAAACDVwAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAlrVTVUMCAABCBwAAEgAA AAAAAAAAAAAAAAAQWwAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAD1CZLZLAQAA wAIAABQAAAAAAAAAAAAAAAAAg10AAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAh AGKvstKBAQAA0AIAABAAAAAAAAAAAAAAAAAAAF8AAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYA CAAAACEADUPjaZEBAADmAgAAEQAAAAAAAAAAAAAAAAC3YQAAZG9jUHJvcHMvY29yZS54bWxQSwEC LQAUAAYACAAAACEA/8f7pXUHAACAOgAADwAAAAAAAAAAAAAAAAB/ZAAAd29yZC9zdHlsZXMueG1s UEsFBgAAAAALAAsAwQIAACFsAAAAAA== ------=_NextPart_000_0177_016CD529.1E152140-- From bfoster@redhat.com Mon Sep 14 08:25:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6AF977F37 for ; Mon, 14 Sep 2015 08:25:05 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3D4D08F8037 for ; Mon, 14 Sep 2015 06:25:02 -0700 (PDT) X-ASG-Debug-ID: 1442237097-04bdf04db5e2760001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id CFEZNsaPzcIgGxqI (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 06:24:57 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 4F232C0B9186; Mon, 14 Sep 2015 13:24:57 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EDOu12031221; Mon, 14 Sep 2015 09:24:57 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id C153E124BCD; Mon, 14 Sep 2015 09:24:55 -0400 (EDT) Date: Mon, 14 Sep 2015 09:24:55 -0400 From: Brian Foster To: Dave Chinner Cc: David Jeffery , xfs@oss.sgi.com Subject: Re: [PATCH] xfs: add missing ilock around dio write last extent alignment Message-ID: <20150914132455.GA22770@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH] xfs: add missing ilock around dio write last extent alignment References: <1441809812-60175-1-git-send-email-bfoster@redhat.com> <20150913235835.GV26895@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150913235835.GV26895@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442237097 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Mon, Sep 14, 2015 at 09:58:35AM +1000, Dave Chinner wrote: > On Wed, Sep 09, 2015 at 10:43:32AM -0400, Brian Foster wrote: > > The iomap codepath (via get_blocks()) acquires and release the inode > > lock in the case of a direct write that requires block allocation. This > > is because xfs_iomap_write_direct() allocates a transaction, which means > > the ilock must be dropped and reacquired after the transaction is > > allocated and reserved. > > > > xfs_iomap_write_direct() invokes xfs_iomap_eof_align_last_fsb() before > > the transaction is created and thus before the ilock is reacquired. This > > can lead to calls to xfs_iread_extents() and reads of the in-core extent > > list without any synchronization (via xfs_bmap_eof() and > > xfs_bmap_last_extent()). xfs_iread_extents() assert fails if the ilock > > is not held, but this is not currently seen in practice as the current > > callers had already invoked xfs_bmapi_read(). > > > > What has been seen in practice are reports of crashes down in the > > xfs_bmap_eof() codepath on direct writes due to seemingly bogus pointer > > references from xfs_iext_get_ext(). While an explicit reproducer is not > > currently available to confirm the cause of the problem, crash analysis > > and code inspection from David Jeffrey had identified the insufficient > > locking. > > > > xfs_iomap_eof_align_last_fsb() is called from other contexts with the > > inode lock already held. __xfs_get_blocks() acquires and drops the ilock > > with variable flags. Therefore, take the simple approach to cycle ilock > > around the last extent alignment call from xfs_iomap_write_direct(). > > > > Reported-by: David Jeffery > > Signed-off-by: Brian Foster > > --- > > fs/xfs/xfs_iomap.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c > > index 1f86033..4d7534e 100644 > > --- a/fs/xfs/xfs_iomap.c > > +++ b/fs/xfs/xfs_iomap.c > > @@ -142,7 +142,9 @@ xfs_iomap_write_direct( > > offset_fsb = XFS_B_TO_FSBT(mp, offset); > > last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); > > if ((offset + count) > XFS_ISIZE(ip)) { > > + xfs_ilock(ip, XFS_ILOCK_EXCL); > > error = xfs_iomap_eof_align_last_fsb(mp, ip, extsz, &last_fsb); > > + xfs_iunlock(ip, XFS_ILOCK_EXCL); > > XFS_ILOCK_SHARED? > I suspect that is technically sufficient in this particular call path given that we've called xfs_bmapi_read(). The problem is that there is a call to xfs_iread_extents() buried a few calls deep in xfs_bmap_last_extent(). My understanding is that we need the exclusive lock because it's not safe for multiple threads to populate the in-core extent list at the same time, so I don't really want to replace the existing race with a landmine should the context happen to change in the future. > Also, looking at __xfs_get_blocks(), we drop the ilock immediately > before calling xfs_iomap_write_direct(), which we already hold in > shared mode for the xfs_bmapi_read() for direct IO. > > Can we push that lock dropping into xfs_iomap_write_direct() after > we've done the xfs_iomap_eof_align_last_fsb() call and before we do > transaction reservations so we don't need an extra lock round-trip > here? e.g. xfs_iomap_write_delay() is called under the lock context > held by __xfs_get_blocks().... > That was my initial thought when looking at this code... e.g., to just carry the lock over and drop it prior to transaction setup. I didn't go that route because __xfs_get_blocks() uses a variable locking mode and it seemed ugly to pass along the lock mode to xfs_iomap_direct_write(). Further, given the above it also looked like we'd have to check and cycle the ilock EXCL if it were ILOCK_SHARED. Finally, xfs_iomap_direct_write() has a call to xfs_qm_dqattach() which itself acquires ILOCK_EXCL. Looking at xfs_iomap_write_delay(), we do have a dqattach_locked() variant but it also expects to have ILOCK_EXCL. Hmm, so in the common case both the extent list and a quota are handled once and thus the only notable lock cycle is the align_last_fsb() case. I think we could do something like this: - Create a shared lock safe variant of xfs_iomap_eof_align_last_fsb() to be called from xfs_iomap_write_direct(). - __xfs_get_blocks() continues to call xfs_ilock_data_map_shared(), but unconditionally demotes XFS_ILOCK_EXCL to XFS_ILOCK_SHARED before calling xfs_iomap_write_direct(). - xfs_iomap_write_direct() moves the xfs_qm_dqattach() call to immediately before the transaction allocation. E.g., it executes the existing align_last_fsb() bits and whatnot under XFS_ILOCK_SHARED, drops the lock, potentially attaches the quota and carries on as normal with the transaction. The only thing I'm not sure about is the shared lock safe version of xfs_iomap_eof_align_last_fsb(). The xfs_iread_extents() call is a few calls deep and xfs_bmap_last_extent() is called from other contexts. I suppose we could call it as is and pull up an assert to check for XFS_IFEXTENTS such that the situation is explicitly documented in the appropriate context (we do already have the assert in xfs_iread_extents() if it were called). Also, I take it we can safely assume the in-core extent list is still around if we still hold the lock from the xfs_bmapi_read() call. Thoughts? I guess I'll float another patch... Brian > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From unwieldier59@inbox.ru Mon Sep 14 09:34:23 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2C0057F37 for ; Mon, 14 Sep 2015 09:34:23 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 1C01730404E for ; Mon, 14 Sep 2015 07:34:19 -0700 (PDT) X-ASG-Debug-ID: 1442241250-04cbb005e9f1460001-NocioJ Received: from [178.207.210.82] ([178.207.210.82]) by cuda.sgi.com with ESMTP id 3onIqbEj2dk6qI2d for ; Mon, 14 Sep 2015 07:34:12 -0700 (PDT) X-Barracuda-Envelope-From: unwieldier59@inbox.ru X-Barracuda-Apparent-Source-IP: 178.207.210.82 To: xfs Subject: =?koi8-r?B?5MXbxdfB0SDB0sXOxMEgz8bJ08E=?= From: =?koi8-r?B?4c7E0sXKIObJzMnQ3tXL?= X-ASG-Orig-Subj: =?koi8-r?B?5MXbxdfB0SDB0sXOxMEgz8bJ08E=?= Message-Id: <76638071.20150914173404@inbox.ru> MIME-Version: 1.0 Date: Mon, 14 Sep 2015 17:34:04 +0300 Content-Type: text/plain; charset=koi8-r X-Priority: 3 (Normal) X-Mailer: MyBB mailer X-Barracuda-Connect: UNKNOWN[178.207.210.82] X-Barracuda-Start-Time: 1442241250 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 2.10 X-Barracuda-Spam-Status: No, SCORE=2.10 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC7_SA_HREF_FROM_MISMATCH_TEXT_URIx1_HL, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22529 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 2.00 BSF_SC7_SA_HREF_FROM_MISMATCH_TEXT_URIx1_HL Custom Rule HREF_FROM_MISMATCH_TEXT_URIx1_HL óÄÁÅÔÓÑ × ÎÁÅÍ ÎÅÂÏÌØÛÏÊ ÏÆÉÓ - http://www.cian.ru/sale/suburban/7718320/ From bfoster@redhat.com Mon Sep 14 12:02:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 14AC47F37 for ; Mon, 14 Sep 2015 12:02:40 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id CAB7930404E for ; Mon, 14 Sep 2015 10:02:36 -0700 (PDT) X-ASG-Debug-ID: 1442250155-04bdf04db5ef7c0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id wakNk03qUk5CV2ZG (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 10:02:35 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id EA962A9A for ; Mon, 14 Sep 2015 17:02:34 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EH2YS7000980 for ; Mon, 14 Sep 2015 13:02:34 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 5B4C3124BCD; Mon, 14 Sep 2015 13:02:33 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH v2] xfs: add missing ilock around dio write last extent alignment Date: Mon, 14 Sep 2015 13:02:33 -0400 X-ASG-Orig-Subj: [PATCH v2] xfs: add missing ilock around dio write last extent alignment Message-Id: <1442250153-38295-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442250155 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 The iomap codepath (via get_blocks()) acquires and release the inode lock in the case of a direct write that requires block allocation. This is because xfs_iomap_write_direct() allocates a transaction, which means the ilock must be dropped and reacquired after the transaction is allocated and reserved. xfs_iomap_write_direct() invokes xfs_iomap_eof_align_last_fsb() before the transaction is created and thus before the ilock is reacquired. This can lead to calls to xfs_iread_extents() and reads of the in-core extent list without any synchronization (via xfs_bmap_eof() and xfs_bmap_last_extent()). xfs_iread_extents() assert fails if the ilock is not held, but this is not currently seen in practice as the current callers had already invoked xfs_bmapi_read(). What has been seen in practice are reports of crashes down in the xfs_bmap_eof() codepath on direct writes due to seemingly bogus pointer references from xfs_iext_get_ext(). While an explicit reproducer is not currently available to confirm the cause of the problem, crash analysis and code inspection from David Jeffrey had identified the insufficient locking. xfs_iomap_eof_align_last_fsb() is called from other contexts with the inode lock already held, so we cannot acquire it therein. __xfs_get_blocks() acquires and drops the ilock with variable flags to cover the event that the extent list must be read in. The common case is that __xfs_get_blocks() acquires the shared ilock. To provide locking around the last extent alignment call without adding more lock cycles to the dio path, update xfs_iomap_write_direct() to expect the shared ilock held on entry and do the extent alignment under its protection. Demote the lock, if necessary, from __xfs_get_blocks() and push the xfs_qm_dqattach() call outside of the shared lock critical section. Also, add an assert to document that the extent list is always expected to be present in this path. Otherwise, we risk a call to xfs_iread_extents() while under the shared ilock. This is safe as all current callers have executed an xfs_bmapi_read() call under the current iolock context. Reported-by: David Jeffery Signed-off-by: Brian Foster --- Note that I opted not to complicate the pnfs caller, but I could do so similar to __xfs_get_blocks() if we think it's necessary... Brian v2: - Updated xfs_iomap_write_direct() to use ilock acquired by caller. v1: http://oss.sgi.com/pipermail/xfs/2015-September/043570.html fs/xfs/xfs_aops.c | 10 +++++----- fs/xfs/xfs_iomap.c | 33 ++++++++++++++++++++++++++------- fs/xfs/xfs_pnfs.c | 5 +++++ 3 files changed, 36 insertions(+), 12 deletions(-) diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c index 458fced..c5e743c 100644 --- a/fs/xfs/xfs_aops.c +++ b/fs/xfs/xfs_aops.c @@ -1403,12 +1403,12 @@ __xfs_get_blocks( imap.br_startblock == DELAYSTARTBLOCK))) { if (direct || xfs_get_extsz_hint(ip)) { /* - * Drop the ilock in preparation for starting the block - * allocation transaction. It will be retaken - * exclusively inside xfs_iomap_write_direct for the - * actual allocation. + * xfs_iomap_write_direct() expects the shared lock. It + * is unlocked on return. */ - xfs_iunlock(ip, lockmode); + if (lockmode == XFS_ILOCK_EXCL) + xfs_ilock_demote(ip, lockmode); + error = xfs_iomap_write_direct(ip, offset, size, &imap, nimaps); if (error) diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 1f86033..1beda33 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -131,20 +131,29 @@ xfs_iomap_write_direct( uint qblocks, resblks, resrtextents; int committed; int error; - - error = xfs_qm_dqattach(ip, 0); - if (error) - return error; + int lockmode; rt = XFS_IS_REALTIME_INODE(ip); extsz = xfs_get_extsz_hint(ip); + lockmode = XFS_ILOCK_SHARED; /* locked by caller */ + + ASSERT(xfs_isilocked(ip, lockmode)); offset_fsb = XFS_B_TO_FSBT(mp, offset); last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); if ((offset + count) > XFS_ISIZE(ip)) { + /* + * Assert that the in-core extent list is present since this can + * call xfs_iread_extents() and we only have the ilock shared. + * This should be safe because the lock was held around a bmapi + * call in the caller and we only need it to access the in-core + * list. + */ + ASSERT(XFS_IFORK_PTR(ip, XFS_DATA_FORK)->if_flags & + XFS_IFEXTENTS); error = xfs_iomap_eof_align_last_fsb(mp, ip, extsz, &last_fsb); if (error) - return error; + goto out_unlock; } else { if (nmaps && (imap->br_startblock == HOLESTARTBLOCK)) last_fsb = MIN(last_fsb, (xfs_fileoff_t) @@ -174,6 +183,15 @@ xfs_iomap_write_direct( } /* + * Drop the shared lock acquired by the caller, attach the dquot if + * necessary and move on to transaction setup. + */ + xfs_iunlock(ip, lockmode); + error = xfs_qm_dqattach(ip, 0); + if (error) + return error; + + /* * Allocate and setup the transaction */ tp = xfs_trans_alloc(mp, XFS_TRANS_DIOSTRAT); @@ -187,7 +205,8 @@ xfs_iomap_write_direct( return error; } - xfs_ilock(ip, XFS_ILOCK_EXCL); + lockmode = XFS_ILOCK_EXCL; + xfs_ilock(ip, lockmode); error = xfs_trans_reserve_quota_nblks(tp, ip, qblocks, 0, quota_flag); if (error) @@ -229,7 +248,7 @@ xfs_iomap_write_direct( error = xfs_alert_fsblock_zero(ip, imap); out_unlock: - xfs_iunlock(ip, XFS_ILOCK_EXCL); + xfs_iunlock(ip, lockmode); return error; out_bmap_cancel: diff --git a/fs/xfs/xfs_pnfs.c b/fs/xfs/xfs_pnfs.c index ab4a606..dc62219 100644 --- a/fs/xfs/xfs_pnfs.c +++ b/fs/xfs/xfs_pnfs.c @@ -181,6 +181,11 @@ xfs_fs_map_blocks( ASSERT(imap.br_startblock != DELAYSTARTBLOCK); if (!nimaps || imap.br_startblock == HOLESTARTBLOCK) { + /* + * xfs_iomap_write_direct() expects to take ownership of + * the shared ilock. + */ + xfs_ilock(ip, XFS_ILOCK_SHARED); error = xfs_iomap_write_direct(ip, offset, length, &imap, nimaps); if (error) -- 2.1.0 From grant.keller@sonic.com Mon Sep 14 13:59:04 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 5F7757F37 for ; Mon, 14 Sep 2015 13:59:04 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 4DE6C8F8033 for ; Mon, 14 Sep 2015 11:59:01 -0700 (PDT) X-ASG-Debug-ID: 1442257138-04cb6c355ce1520001-NocioJ Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by cuda.sgi.com with ESMTP id kg7CaDGYdvyEIyFH (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 14 Sep 2015 11:58:59 -0700 (PDT) X-Barracuda-Envelope-From: grant.keller@sonic.com X-Barracuda-Apparent-Source-IP: 64.142.111.80 Received: from [64.142.18.25] (gwork.noc.sonic.net [64.142.18.25]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t8EIwvau003336 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 14 Sep 2015 11:58:58 -0700 To: xfs@oss.sgi.com From: Grant Keller Subject: rm Tainted warning after kernel update. X-Enigmail-Draft-Status: N1110 X-ASG-Orig-Subj: rm Tainted warning after kernel update. Message-ID: <55F718A1.10801@sonic.com> Date: Mon, 14 Sep 2015 11:57:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYAvtKZgfXa+FMoOL56JCwhUebCRgfeIyMqDBVgkZg9NGFa1sYbEKN5M3Mci5Awklp5rVUf92n8Sve067A794Cn X-Sonic-ID: C;oHM2pxJb5RGe2r0U9jFv0A== M;YGZlpxJb5RGe2r0U9jFv0A== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-Barracuda-Connect: c.mail.sonic.net[64.142.111.80] X-Barracuda-Start-Time: 1442257139 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22536 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Hello, I have a server running Scientific Linux 6.7, and since updating to kernel 2.6.32-573.3.1.el6.x86_64 the following error has begun appearing in our message logs: Sep 14 11:43:03 localhost kernel: ------------[ cut here ]------------ Sep 14 11:43:03 localhost kernel: WARNING: at fs/dcache.c:758 d_delete+0x260/0x2c0() (Tainted: G W -- ------------ ) Sep 14 11:43:03 localhost kernel: Hardware name: X7DB8 Sep 14 11:43:03 localhost kernel: Modules linked in: nfsd nfs_acl auth_rpcgss autofs4 lockd sunrpc p4_clockmod freq_table speedstep_lib nf_conntrack_ftp iptable_mangle xt_comment nf_conntrack_ipv4 nf_defrag_ipv4 xt_multiport iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 xfs exportfs ppdev parport_pc parport sg e1000e microcode serio_raw iTCO_wdt iTCO_vendor_support ixgbe ptp pps_core mdio i2c_i801 lpc_ich mfd_core i5000_edac edac_core i5k_amb ioatdma dca shpchp ext4 jbd2 mbcache sd_mod crc_t10dif 3w_9xxx pata_acpi ata_generic ata_piix radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ipmi_msghandler] Sep 14 11:43:03 localhost kernel: Pid: 15893, comm: rm Tainted: G W -- ------------ 2.6.32-573.3.1.el6.x86_64 #1 Sep 14 11:43:03 localhost kernel: Call Trace: Sep 14 11:43:03 localhost kernel: [] ? warn_slowpath_common+0x91/0xe0 Sep 14 11:43:03 localhost kernel: [] ? warn_slowpath_null+0x1a/0x20 Sep 14 11:43:03 localhost kernel: [] ? d_delete+0x260/0x2c0 Sep 14 11:43:03 localhost kernel: [] ? vfs_rmdir+0xe8/0xf0 Sep 14 11:43:03 localhost kernel: [] ? do_rmdir+0x184/0x1f0 Sep 14 11:43:03 localhost kernel: [] ? __fput+0x1a1/0x210 Sep 14 11:43:03 localhost kernel: [] ? audit_syscall_entry+0x1d7/0x200 Sep 14 11:43:03 localhost kernel: [] ? sys_unlinkat+0x2d/0x40 Sep 14 11:43:03 localhost kernel: [] ? system_call_fastpath+0x16/0x1b Sep 14 11:43:03 localhost kernel: ---[ end trace 6080ec4a7ec5ec25 ]--- This happens when we are expiring older backups from the archives, so I have quite a few of these. We have xfsprogs 3.1.1-16.el6.x86_64 installed. Looking for advice on how to proceed. -- Grant Keller System Operations 707-237-2451 grant.keller@sonic.com From bfoster@redhat.com Mon Sep 14 14:18:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 61F8A7F37 for ; Mon, 14 Sep 2015 14:18:05 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3FFB28F8035 for ; Mon, 14 Sep 2015 12:18:05 -0700 (PDT) X-ASG-Debug-ID: 1442258280-04cbb005ecf90a0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id YUmat5cBNB911nZP (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 12:18:01 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id DE54E2F810E; Mon, 14 Sep 2015 19:18:00 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJI0Di023846; Mon, 14 Sep 2015 15:18:00 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id AD8FB124BCD; Mon, 14 Sep 2015 15:17:58 -0400 (EDT) Date: Mon, 14 Sep 2015 15:17:58 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 01/13] xfs_repair: remove trace-only 'n' member from da_level_state Message-ID: <20150914191757.GA34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 01/13] xfs_repair: remove trace-only 'n' member from da_level_state References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-2-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441827251-13128-2-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442258281 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:33:59PM -0500, Eric Sandeen wrote: > The da_level_state structure contains an 'n' member > when XR_DIR_TRACE is enabled, which is a) write only, and > b) set by a macro which doesn't exist (XFS_BUF_TO_DA_INTNODE) > > Removing this structure member fixes compilation with > XR_DIR_TRACE enabled, and also makes da_level_state identical > to dir2_level_state, so the two can be combined later. > > Signed-off-by: Eric Sandeen > Signed-off-by: Eric Sandeen > --- Reviewed-by: Brian Foster > repair/attr_repair.c | 9 --------- > 1 files changed, 0 insertions(+), 9 deletions(-) > > diff --git a/repair/attr_repair.c b/repair/attr_repair.c > index debe9e8..d63bc87 100644 > --- a/repair/attr_repair.c > +++ b/repair/attr_repair.c > @@ -59,9 +59,6 @@ typedef unsigned char da_freemap_t; > */ > typedef struct da_level_state { > xfs_buf_t *bp; /* block bp */ > -#ifdef XR_DIR_TRACE > - xfs_da_intnode_t *n; /* bp data */ > -#endif > xfs_dablk_t bno; /* file block number */ > xfs_dahash_t hashval; /* last verified hashval */ > int index; /* current index in block */ > @@ -232,9 +229,6 @@ traverse_int_dablock(xfs_mount_t *mp, > da_cursor->level[i].bp = bp; > da_cursor->level[i].bno = bno; > da_cursor->level[i].index = 0; > -#ifdef XR_DIR_TRACE > - da_cursor->level[i].n = XFS_BUF_TO_DA_INTNODE(bp); > -#endif > > /* > * set up new bno for next level down > @@ -624,9 +618,6 @@ verify_da_path(xfs_mount_t *mp, > cursor->level[this_level].bno = dabno; > cursor->level[this_level].hashval = > be32_to_cpu(btree[0].hashval); > -#ifdef XR_DIR_TRACE > - cursor->level[this_level].n = newnode; > -#endif > entry = cursor->level[this_level].index = 0; > > /* > -- > 1.7.1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Mon Sep 14 14:18:10 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id E42DA7F50 for ; Mon, 14 Sep 2015 14:18:10 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id D767A304053 for ; Mon, 14 Sep 2015 12:18:07 -0700 (PDT) X-ASG-Debug-ID: 1442258286-04cb6c355de1be0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id sQQKt9L7po78ZtUX (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 12:18:06 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 1CEEBC0B2003; Mon, 14 Sep 2015 19:18:06 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJI5eC024891; Mon, 14 Sep 2015 15:18:05 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 651D9124BCD; Mon, 14 Sep 2015 15:18:04 -0400 (EDT) Date: Mon, 14 Sep 2015 15:18:04 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 02/13] xfs_repair: remove type from da & dir2 cursors Message-ID: <20150914191803.GB34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 02/13] xfs_repair: remove type from da & dir2 cursors References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-3-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441827251-13128-3-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1442258286 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:34:00PM -0500, Eric Sandeen wrote: > The type field in these cursors is only set (and only > in the attr code), and it's never read; just remove > it. > > Signed-off-by: Eric Sandeen > Signed-off-by: Eric Sandeen > --- Reviewed-by: Brian Foster > repair/attr_repair.c | 2 -- > repair/dir2.h | 1 - > 2 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/repair/attr_repair.c b/repair/attr_repair.c > index d63bc87..f29a5bd 100644 > --- a/repair/attr_repair.c > +++ b/repair/attr_repair.c > @@ -67,7 +67,6 @@ typedef struct da_level_state { > > typedef struct da_bt_cursor { > int active; /* highest level in tree (# levels-1) */ > - int type; /* 0 if dir, 1 if attr */ > xfs_ino_t ino; > xfs_dablk_t greatest_bno; > xfs_dinode_t *dip; > @@ -1477,7 +1476,6 @@ process_node_attr( > */ > memset(&da_cursor, 0, sizeof(da_bt_cursor_t)); > da_cursor.active = 0; > - da_cursor.type = 0; > da_cursor.ino = ino; > da_cursor.dip = dip; > da_cursor.greatest_bno = 0; > diff --git a/repair/dir2.h b/repair/dir2.h > index df68d5c..3cc1941 100644 > --- a/repair/dir2.h > +++ b/repair/dir2.h > @@ -51,7 +51,6 @@ typedef struct dir2_level_state { > > typedef struct dir2_bt_cursor { > int active; /* highest level in tree (# levels-1) */ > - int type; /* 0 if dir, 1 if attr */ > xfs_ino_t ino; > xfs_dablk_t greatest_bno; > xfs_dinode_t *dip; > -- > 1.7.1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Mon Sep 14 14:18:16 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A5E497F37 for ; Mon, 14 Sep 2015 14:18:16 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 419ADAC006 for ; Mon, 14 Sep 2015 12:18:13 -0700 (PDT) X-ASG-Debug-ID: 1442258291-04bdf04db3f35a0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id yGMTgl0sRQOadKZw (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 12:18:12 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E2383461C8; Mon, 14 Sep 2015 19:18:11 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJIBmD019985; Mon, 14 Sep 2015 15:18:11 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id E33BF124BCD; Mon, 14 Sep 2015 15:18:09 -0400 (EDT) Date: Mon, 14 Sep 2015 15:18:09 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 03/13] xfs_repair: make CRC checking consistent in path verification Message-ID: <20150914191809.GC34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 03/13] xfs_repair: make CRC checking consistent in path verification References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-4-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441827251-13128-4-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442258292 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:34:01PM -0500, Eric Sandeen wrote: > verify_da_path and verify_dir2_path both take steps to > re-compute the CRC of the block if it otherwise looks > ok and no other changes are needed. They do this inside > a loop, but the approach differs; verify_da_path expects > its caller to check the first buffer prior to the loop, > and verify_dir2_path expects its caller to check the last > buffer after the loop. > > Make this consistent by semi-arbitrarily choosing to make > verify_da_path (and its caller) match the method used by > verify_dir2_path, and check the last buffer after the > loop is done. > The code here seems Ok, but I don't think the commit log description describes what the code is doing. I could also just have misread it. This code is recursive and hairy enough as it is... As I follow it, we init the cursor to the leftmost descendant in traverse_int_dablock(). I don't see any crc verification in there. We get into process_leaf_attr_level() and it reads and walks through the leaf blocks, doing the crc check of each one. Each leaf block we verify corresponds to an entry in the node block, so the verify_da_path() walks the node entry index along until we slide over to the next node block. At that point, we verify the crc of the current node buffer, write it out and replace that level in the cursor with the next one. Eventually we hit the end of the leaf block chain and call verify_final_da_path(). If I'm following all that correctly, it looks to me that before this change we would have never verified the crc of the first node block. At least, I can't find where that might happen. After this change, that first node block crc is checked immediately before it's written out. But now that the post-read check is gone, I don't see where the last node block is crc-checked. Perhaps this should be checked in verify_final_da_path()..? Taking a quick look at the dir2 side, it looks like it checks the crc in traverse_int_dir2block() and bails out on -EFSBADCRC (presumably to rebuild the whole thing..?). As noted above, it does the pre-write crc check and I don't see where it would check the final node block(s) either. Hmm, this code is hairy enough it might be worth running through a debugger or doing a targeted corruption to see if I'm missing something... Brian > Signed-off-by: Eric Sandeen > Signed-off-by: Eric Sandeen > --- > repair/attr_repair.c | 24 ++++++++++++++---------- > 1 files changed, 14 insertions(+), 10 deletions(-) > > diff --git a/repair/attr_repair.c b/repair/attr_repair.c > index f29a5bd..aba0782 100644 > --- a/repair/attr_repair.c > +++ b/repair/attr_repair.c > @@ -606,6 +606,14 @@ verify_da_path(xfs_mount_t *mp, > ASSERT(cursor->level[this_level].dirty == 0 || > (cursor->level[this_level].dirty && !no_modify)); > > + /* > + * If block looks ok but CRC didn't match, make sure to > + * recompute it. > + */ > + if (!no_modify && > + cursor->level[this_level].bp->b_error == -EFSBADCRC) > + cursor->level[this_level].dirty = 1; > + > if (cursor->level[this_level].dirty && !no_modify) > libxfs_writebuf(cursor->level[this_level].bp, 0); > else > @@ -618,14 +626,6 @@ verify_da_path(xfs_mount_t *mp, > cursor->level[this_level].hashval = > be32_to_cpu(btree[0].hashval); > entry = cursor->level[this_level].index = 0; > - > - /* > - * We want to rewrite the buffer on a CRC error seeing as it > - * contains what appears to be a valid node block, but only if > - * we are fixing errors. > - */ > - if (bp->b_error == -EFSBADCRC && !no_modify) > - cursor->level[this_level].dirty++; > } > /* > * ditto for block numbers > @@ -1363,8 +1363,6 @@ process_leaf_attr_level(xfs_mount_t *mp, > da_bno, dev_bno, ino); > goto error_out; > } > - if (bp->b_error == -EFSBADCRC) > - repair++; > > leaf = bp->b_addr; > xfs_attr3_leaf_hdr_from_disk(mp->m_attr_geo, &leafhdr, leaf); > @@ -1419,6 +1417,12 @@ process_leaf_attr_level(xfs_mount_t *mp, > } > > current_hashval = greatest_hashval; > + /* > + * If block looks ok but CRC didn't match, make sure to > + * recompute it. > + */ > + if (!no_modify && bp->b_error == -EFSBADCRC) > + repair++; > > if (repair && !no_modify) > libxfs_writebuf(bp, 0); > -- > 1.7.1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Mon Sep 14 14:18:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 6F6997F37 for ; Mon, 14 Sep 2015 14:18:22 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id DD39AAC006 for ; Mon, 14 Sep 2015 12:18:21 -0700 (PDT) X-ASG-Debug-ID: 1442258298-04cb6c355ae1c00001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id BMW7HZ9Dqr5QcBXT (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 12:18:19 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id D84DF80091; Mon, 14 Sep 2015 19:18:18 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJII2u020511; Mon, 14 Sep 2015 15:18:18 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 24C35124BCD; Mon, 14 Sep 2015 15:18:17 -0400 (EDT) Date: Mon, 14 Sep 2015 15:18:17 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 04/13] xfs_repair: use multibuffer read routines in attr_repair.c Message-ID: <20150914191816.GD34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 04/13] xfs_repair: use multibuffer read routines in attr_repair.c References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-5-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1441827251-13128-5-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442258299 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:34:02PM -0500, Eric Sandeen wrote: > verify_da_path and traverse_int_dablock are similar to > verify_dir2_path and traverse_int_dir2block, but one > difference is that the dir2 code reads using the > multibuffer capable da_read_buf() routine, whereas > the attr code doesn't need to, and just calls > libxfs_readbuf. > > The multibuffer code falls back just fine when the > geometry indicates that it's not needed, so use that > same code in the attribute routines, and remove > another dir2 / da difference. We make da_read_buf() > non-static to facilitate this. > > Finally, add a local *geo to these routines, > to make the code even more similar at this point. > The geometry will get passed in later in the series. > > Signed-off-by: Eric Sandeen > Signed-off-by: Eric Sandeen > --- > repair/attr_repair.c | 49 +++++++++++++++++++++++++++++++++---------------- > repair/dir2.c | 22 +++++++++++++--------- > repair/dir2.h | 8 ++++++++ > 3 files changed, 54 insertions(+), 25 deletions(-) > > diff --git a/repair/attr_repair.c b/repair/attr_repair.c > index aba0782..fe81df4 100644 > --- a/repair/attr_repair.c > +++ b/repair/attr_repair.c > @@ -138,14 +138,20 @@ traverse_int_dablock(xfs_mount_t *mp, > xfs_dablk_t *rbno, > int whichfork) > { > + bmap_ext_t *bmp; struct bmap_ext (and several other places below) > xfs_dablk_t bno; > int i; > + int nex; > xfs_da_intnode_t *node; > + bmap_ext_t lbmp; > xfs_fsblock_t fsbno; > xfs_buf_t *bp; > + struct xfs_da_geometry *geo; > struct xfs_da_node_entry *btree; > struct xfs_da3_icnode_hdr nodehdr; > > + geo = mp->m_attr_geo; > + > /* > * traverse down left-side of tree until we hit the > * left-most leaf block setting up the btree cursor along > @@ -160,13 +166,16 @@ traverse_int_dablock(xfs_mount_t *mp, > /* > * read in each block along the way and set up cursor > */ > - fsbno = blkmap_get(da_cursor->blkmap, bno); > + nex = blkmap_getn(da_cursor->blkmap, bno, > + geo->fsbcount, &bmp, &lbmp); > ... attr_repair.c: In function ‘process_attributes’: attr_repair.c:185:5: warning: ‘fsbno’ may be used uninitialized in this function [-Wmaybe-uninitialized] do_warn( ... Brian > - if (fsbno == NULLFSBLOCK) > + if (nex == 0) > goto error_out; > > - bp = libxfs_readbuf(mp->m_dev, XFS_FSB_TO_DADDR(mp, fsbno), > - XFS_FSB_TO_BB(mp, 1), 0, &xfs_da3_node_buf_ops); > + bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); > + if (bmp != &lbmp) > + free(bmp); > + > if (!bp) { > if (whichfork == XFS_DATA_FORK) > do_warn( > @@ -192,12 +201,10 @@ traverse_int_dablock(xfs_mount_t *mp, > goto error_out; > } > > - if (nodehdr.count > mp->m_attr_geo->node_ents) { > + if (nodehdr.count > geo->node_ents) { > do_warn(_("bad record count in inode %" PRIu64 ", " > "count = %d, max = %d\n"), > - da_cursor->ino, > - nodehdr.count, > - mp->m_attr_geo->node_ents); > + da_cursor->ino, nodehdr.count, geo->node_ents); > libxfs_putbuf(bp); > goto error_out; > } > @@ -492,9 +499,15 @@ verify_da_path(xfs_mount_t *mp, > int bad; > int entry; > int this_level = p_level + 1; > + bmap_ext_t *bmp; > + int nex; > + bmap_ext_t lbmp; > + struct xfs_da_geometry *geo; > struct xfs_da_node_entry *btree; > struct xfs_da3_icnode_hdr nodehdr; > > + geo = mp->m_attr_geo; > + > /* > * index is currently set to point to the entry that > * should be processed now in this level. > @@ -536,17 +549,21 @@ verify_da_path(xfs_mount_t *mp, > */ > dabno = nodehdr.forw; > ASSERT(dabno != 0); > - fsbno = blkmap_get(cursor->blkmap, dabno); > - > - if (fsbno == NULLFSBLOCK) { > - do_warn(_("can't get map info for block %u " > - "of directory inode %" PRIu64 "\n"), > + nex = blkmap_getn(cursor->blkmap, dabno, geo->fsbcount, > + &bmp, &lbmp); > + if (nex == 0) { > + do_warn( > +_("can't get map info for block %u of directory inode %" PRIu64 "\n"), > dabno, cursor->ino); > return(1); > } > > - bp = libxfs_readbuf(mp->m_dev, XFS_FSB_TO_DADDR(mp, fsbno), > - XFS_FSB_TO_BB(mp, 1), 0, &xfs_da3_node_buf_ops); > + fsbno = bmp[0].startblock; > + > + bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); > + if (bmp != &lbmp) > + free(bmp); > + > if (!bp) { > do_warn( > _("can't read block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), > @@ -577,7 +594,7 @@ verify_da_path(xfs_mount_t *mp, > dabno, fsbno, cursor->ino); > bad++; > } > - if (nodehdr.count > mp->m_attr_geo->node_ents) { > + if (nodehdr.count > geo->node_ents) { > do_warn( > _("entry count %d too large in block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), > nodehdr.count, > diff --git a/repair/dir2.c b/repair/dir2.c > index 54c49eb..44367c6 100644 > --- a/repair/dir2.c > +++ b/repair/dir2.c > @@ -92,7 +92,7 @@ namecheck(char *name, int length) > * Multibuffer handling. > * V2 directory blocks can be noncontiguous, needing multiple buffers. > */ > -static struct xfs_buf * > +struct xfs_buf * > da_read_buf( > xfs_mount_t *mp, > int nex, > @@ -143,9 +143,12 @@ traverse_int_dir2block(xfs_mount_t *mp, > int nex; > xfs_da_intnode_t *node; > bmap_ext_t lbmp; > + struct xfs_da_geometry *geo; > struct xfs_da_node_entry *btree; > struct xfs_da3_icnode_hdr nodehdr; > > + geo = mp->m_dir_geo; > + > /* > * traverse down left-side of tree until we hit the > * left-most leaf block setting up the btree cursor along > @@ -161,7 +164,7 @@ traverse_int_dir2block(xfs_mount_t *mp, > * read in each block along the way and set up cursor > */ > nex = blkmap_getn(da_cursor->blkmap, bno, > - mp->m_dir_geo->fsbcount, &bmp, &lbmp); > + geo->fsbcount, &bmp, &lbmp); > > if (nex == 0) > goto error_out; > @@ -207,13 +210,11 @@ _("corrupt tree block %u for directory inode %" PRIu64 "\n"), > goto error_out; > } > btree = M_DIROPS(mp)->node_tree_p(node); > - if (nodehdr.count > mp->m_dir_geo->node_ents) { > - libxfs_putbuf(bp); > + if (nodehdr.count > geo->node_ents) { > do_warn( > _("bad record count in inode %" PRIu64 ", count = %d, max = %d\n"), > - da_cursor->ino, > - nodehdr.count, > - mp->m_dir_geo->node_ents); > + da_cursor->ino, nodehdr.count, geo->node_ents); > + libxfs_putbuf(bp); > goto error_out; > } > /* > @@ -488,9 +489,12 @@ verify_dir2_path(xfs_mount_t *mp, > bmap_ext_t *bmp; > int nex; > bmap_ext_t lbmp; > + struct xfs_da_geometry *geo; > struct xfs_da_node_entry *btree; > struct xfs_da3_icnode_hdr nodehdr; > > + geo = mp->m_dir_geo; > + > /* > * index is currently set to point to the entry that > * should be processed now in this level. > @@ -532,7 +536,7 @@ verify_dir2_path(xfs_mount_t *mp, > */ > dabno = nodehdr.forw; > ASSERT(dabno != 0); > - nex = blkmap_getn(cursor->blkmap, dabno, mp->m_dir_geo->fsbcount, > + nex = blkmap_getn(cursor->blkmap, dabno, geo->fsbcount, > &bmp, &lbmp); > if (nex == 0) { > do_warn( > @@ -574,7 +578,7 @@ _("bad back pointer in block %u for directory inode %" PRIu64 "\n"), > dabno, cursor->ino); > bad++; > } > - if (nodehdr.count > mp->m_dir_geo->node_ents) { > + if (nodehdr.count > geo->node_ents) { > do_warn( > _("entry count %d too large in block %u for directory inode %" PRIu64 "\n"), > nodehdr.count, > diff --git a/repair/dir2.h b/repair/dir2.h > index 3cc1941..186633f 100644 > --- a/repair/dir2.h > +++ b/repair/dir2.h > @@ -58,6 +58,14 @@ typedef struct dir2_bt_cursor { > struct blkmap *blkmap; > } dir2_bt_cursor_t; > > +#include "bmap.h" /* Goes away in later refactoring */ > +struct xfs_buf * > +da_read_buf( > + xfs_mount_t *mp, > + int nex, > + bmap_ext_t *bmp, > + const struct xfs_buf_ops *ops); > + > int > process_dir2( > xfs_mount_t *mp, > -- > 1.7.1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Mon Sep 14 14:18:25 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2E3D37F61 for ; Mon, 14 Sep 2015 14:18:25 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 1DC02304048 for ; Mon, 14 Sep 2015 12:18:25 -0700 (PDT) X-ASG-Debug-ID: 1442258303-04cb6c355ce1c20001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id kCQ7lsEBtX05UsxS (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 12:18:24 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id B23D3C0B2003; Mon, 14 Sep 2015 19:18:23 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJINIs024978; Mon, 14 Sep 2015 15:18:23 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 171D0124BCD; Mon, 14 Sep 2015 15:18:22 -0400 (EDT) Date: Mon, 14 Sep 2015 15:18:22 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 05/13] xfs_repair: fix use-after-free in verify_final_dir2_path Message-ID: <20150914191821.GE34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 05/13] xfs_repair: fix use-after-free in verify_final_dir2_path References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-6-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441827251-13128-6-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1442258304 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:34:03PM -0500, Eric Sandeen wrote: > Way back in 2002, commit 948ce18 fixed a potential use-after-free > in verify_final_da_path, but the same fix was not applied to > verify_final_dir2_path; apply it now. > > Signed-off-by: Eric Sandeen > Signed-off-by: Eric Sandeen > --- Reviewed-by: Brian Foster > repair/dir2.c | 9 ++++++++- > 1 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/repair/dir2.c b/repair/dir2.c > index 44367c6..898b27e 100644 > --- a/repair/dir2.c > +++ b/repair/dir2.c > @@ -330,6 +330,7 @@ verify_final_dir2_path(xfs_mount_t *mp, > const int p_level) > { > xfs_da_intnode_t *node; > + xfs_dahash_t hashval; > int bad = 0; > int entry; > int this_level = p_level + 1; > @@ -409,6 +410,12 @@ _("would correct bad hashval in non-leaf dir block\n" > } > > /* > + * Note: squirrel hashval away _before_ releasing the > + * buffer, preventing a use-after-free problem. > + */ > + hashval = be32_to_cpu(btree[entry].hashval); > + > + /* > * release/write buffer > */ > ASSERT(cursor->level[this_level].dirty == 0 || > @@ -430,7 +437,7 @@ _("would correct bad hashval in non-leaf dir block\n" > * set hashvalue to correctl reflect the now-validated > * last entry in this block and continue upwards validation > */ > - cursor->level[this_level].hashval = be32_to_cpu(btree[entry].hashval); > + cursor->level[this_level].hashval = hashval; > > return(verify_final_dir2_path(mp, cursor, this_level)); > } > -- > 1.7.1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Mon Sep 14 14:18:49 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id DF9B27F5D for ; Mon, 14 Sep 2015 14:18:48 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 57D44AC001 for ; Mon, 14 Sep 2015 12:18:48 -0700 (PDT) X-ASG-Debug-ID: 1442258307-04cbb005e9f90d0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id mMwAgGEHyzo78NfM (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 12:18:28 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id BC8103B3C7; Mon, 14 Sep 2015 19:18:27 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJIR8G020081; Mon, 14 Sep 2015 15:18:27 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 0D374124BCD; Mon, 14 Sep 2015 15:18:26 -0400 (EDT) Date: Mon, 14 Sep 2015 15:18:25 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 06/13] xfs_repair: add XR_DIR_TRACE to dir2.c Message-ID: <20150914191825.GF34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 06/13] xfs_repair: add XR_DIR_TRACE to dir2.c References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-7-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441827251-13128-7-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442258308 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:34:04PM -0500, Eric Sandeen wrote: > attr_repair.c has many printf-tracepoints under > #ifdef XR_DIR_TRACE, but the similar code in dir2.c does not. > > Add these same tracepoints to remove more differences between > these two pieces of code. > > Not all messages are quite correct; those will be fixed up last. > For now we just make the code more obviously similar. > > Signed-off-by: Eric Sandeen > Signed-off-by: Eric Sandeen > --- Reviewed-by: Brian Foster > repair/dir2.c | 39 ++++++++++++++++++++++++++++++++++++--- > 1 files changed, 36 insertions(+), 3 deletions(-) > > diff --git a/repair/dir2.c b/repair/dir2.c > index 898b27e..d9bd5fc 100644 > --- a/repair/dir2.c > +++ b/repair/dir2.c > @@ -337,6 +337,11 @@ verify_final_dir2_path(xfs_mount_t *mp, > struct xfs_da_node_entry *btree; > struct xfs_da3_icnode_hdr nodehdr; > > +#ifdef XR_DIR_TRACE > + fprintf(stderr, "in verify_final_dir2_path, this_level = %d\n", > + this_level); > +#endif > + > /* > * the index should point to the next "unprocessed" entry > * in the block which should be the final (rightmost) entry > @@ -388,8 +393,17 @@ verify_final_dir2_path(xfs_mount_t *mp, > /* > * ok, now check descendant block number against this level > */ > - if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) > + if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { > +#ifdef XR_DIR_TRACE > + fprintf(stderr, "bad directory btree pointer, child bno should " > + "be %d, block bno is %d, hashval is %u\n", > + be16_to_cpu(btree[entry].before), > + cursor->level[p_level].bno, > + cursor->level[p_level].hashval); > + fprintf(stderr, "verify_final_dir2_path returns 1 (bad) #1a\n"); > +#endif > return(1); > + } > > if (cursor->level[p_level].hashval != > be32_to_cpu(btree[entry].hashval)) { > @@ -431,8 +445,12 @@ _("would correct bad hashval in non-leaf dir block\n" > /* > * bail out if this is the root block (top of tree) > */ > - if (this_level >= cursor->active) > + if (this_level >= cursor->active) { > +#ifdef XR_DIR_TRACE > + fprintf(stderr, "verify_final_dir2_path returns 0 (ok)\n"); > +#endif > return(0); > + } > /* > * set hashvalue to correctl reflect the now-validated > * last entry in this block and continue upwards validation > @@ -600,6 +618,9 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), > bad++; > } > if (bad) { > +#ifdef XR_DIR_TRACE > + fprintf(stderr, "verify_dir2_path returns 1 (bad) #4\n"); > +#endif > libxfs_putbuf(bp); > return(1); > } > @@ -631,8 +652,17 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), > /* > * ditto for block numbers > */ > - if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) > + if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { > +#ifdef XR_DIR_TRACE > + fprintf(stderr, "bad directory btree pointer, child bno " > + "should be %d, block bno is %d, hashval is %u\n", > + be32_to_cpu(btree[entry].before), > + cursor->level[p_level].bno, > + cursor->level[p_level].hashval); > + fprintf(stderr, "verify_dir2_path returns 1 (bad) #1a\n"); > +#endif > return(1); > + } > /* > * ok, now validate last hashvalue in the descendant > * block against the hashval in the current entry > @@ -659,6 +689,9 @@ _("would correct bad hashval in interior dir block\n" > * (which should point to the next descendant block) > */ > cursor->level[this_level].index++; > +#ifdef XR_DIR_TRACE > + fprintf(stderr, "verify_dir2_path returns 0 (ok)\n"); > +#endif > return(0); > } > > -- > 1.7.1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Mon Sep 14 14:24:59 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id C14747F3F for ; Mon, 14 Sep 2015 14:24:59 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 7B7AC8F8033 for ; Mon, 14 Sep 2015 12:24:59 -0700 (PDT) X-ASG-Debug-ID: 1442258696-04bdf04db3f37d0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id LSOQEEDDgOVT8vDe for ; Mon, 14 Sep 2015 12:24:56 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 5A5D763CBCF5; Mon, 14 Sep 2015 14:24:56 -0500 (CDT) Subject: Re: [PATCH 04/13] xfs_repair: use multibuffer read routines in attr_repair.c To: Brian Foster X-ASG-Orig-Subj: Re: [PATCH 04/13] xfs_repair: use multibuffer read routines in attr_repair.c References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-5-git-send-email-sandeen@sandeen.net> <20150914191816.GD34083@bfoster.bfoster> Cc: xfs@oss.sgi.com From: Eric Sandeen Message-ID: <55F71F05.90905@sandeen.net> Date: Mon, 14 Sep 2015 14:24:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150914191816.GD34083@bfoster.bfoster> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1442258696 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22537 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/14/15 2:18 PM, Brian Foster wrote: > On Wed, Sep 09, 2015 at 02:34:02PM -0500, Eric Sandeen wrote: >> verify_da_path and traverse_int_dablock are similar to >> verify_dir2_path and traverse_int_dir2block, but one >> difference is that the dir2 code reads using the >> multibuffer capable da_read_buf() routine, whereas >> the attr code doesn't need to, and just calls >> libxfs_readbuf. >> >> The multibuffer code falls back just fine when the >> geometry indicates that it's not needed, so use that >> same code in the attribute routines, and remove >> another dir2 / da difference. We make da_read_buf() >> non-static to facilitate this. >> >> Finally, add a local *geo to these routines, >> to make the code even more similar at this point. >> The geometry will get passed in later in the series. >> >> Signed-off-by: Eric Sandeen >> Signed-off-by: Eric Sandeen >> --- >> repair/attr_repair.c | 49 +++++++++++++++++++++++++++++++++---------------- >> repair/dir2.c | 22 +++++++++++++--------- >> repair/dir2.h | 8 ++++++++ >> 3 files changed, 54 insertions(+), 25 deletions(-) >> >> diff --git a/repair/attr_repair.c b/repair/attr_repair.c >> index aba0782..fe81df4 100644 >> --- a/repair/attr_repair.c >> +++ b/repair/attr_repair.c >> @@ -138,14 +138,20 @@ traverse_int_dablock(xfs_mount_t *mp, >> xfs_dablk_t *rbno, >> int whichfork) >> { >> + bmap_ext_t *bmp; Well, yeah - I thought about that. The goal was to make it as close as possible to the other code, so I decided against the struct foo's. I could do a "get rid of typedefs" as the last patch to the new util code if you like. > struct bmap_ext > > (and several other places below) > >> xfs_dablk_t bno; >> int i; >> + int nex; >> xfs_da_intnode_t *node; >> + bmap_ext_t lbmp; >> xfs_fsblock_t fsbno; >> xfs_buf_t *bp; >> + struct xfs_da_geometry *geo; >> struct xfs_da_node_entry *btree; >> struct xfs_da3_icnode_hdr nodehdr; >> >> + geo = mp->m_attr_geo; >> + >> /* >> * traverse down left-side of tree until we hit the >> * left-most leaf block setting up the btree cursor along >> @@ -160,13 +166,16 @@ traverse_int_dablock(xfs_mount_t *mp, >> /* >> * read in each block along the way and set up cursor >> */ >> - fsbno = blkmap_get(da_cursor->blkmap, bno); >> + nex = blkmap_getn(da_cursor->blkmap, bno, >> + geo->fsbcount, &bmp, &lbmp); >> > > ... > attr_repair.c: In function ‘process_attributes’: > attr_repair.c:185:5: warning: ‘fsbno’ may be used uninitialized in this function [-Wmaybe-uninitialized] hm, whoops. Well, it goes away in the long run, but I can still fix that up. Thanks, -Eric > do_warn( > ... > > Brian > >> - if (fsbno == NULLFSBLOCK) >> + if (nex == 0) >> goto error_out; >> >> - bp = libxfs_readbuf(mp->m_dev, XFS_FSB_TO_DADDR(mp, fsbno), >> - XFS_FSB_TO_BB(mp, 1), 0, &xfs_da3_node_buf_ops); >> + bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); >> + if (bmp != &lbmp) >> + free(bmp); >> + >> if (!bp) { >> if (whichfork == XFS_DATA_FORK) >> do_warn( >> @@ -192,12 +201,10 @@ traverse_int_dablock(xfs_mount_t *mp, >> goto error_out; >> } >> >> - if (nodehdr.count > mp->m_attr_geo->node_ents) { >> + if (nodehdr.count > geo->node_ents) { >> do_warn(_("bad record count in inode %" PRIu64 ", " >> "count = %d, max = %d\n"), >> - da_cursor->ino, >> - nodehdr.count, >> - mp->m_attr_geo->node_ents); >> + da_cursor->ino, nodehdr.count, geo->node_ents); >> libxfs_putbuf(bp); >> goto error_out; >> } >> @@ -492,9 +499,15 @@ verify_da_path(xfs_mount_t *mp, >> int bad; >> int entry; >> int this_level = p_level + 1; >> + bmap_ext_t *bmp; >> + int nex; >> + bmap_ext_t lbmp; >> + struct xfs_da_geometry *geo; >> struct xfs_da_node_entry *btree; >> struct xfs_da3_icnode_hdr nodehdr; >> >> + geo = mp->m_attr_geo; >> + >> /* >> * index is currently set to point to the entry that >> * should be processed now in this level. >> @@ -536,17 +549,21 @@ verify_da_path(xfs_mount_t *mp, >> */ >> dabno = nodehdr.forw; >> ASSERT(dabno != 0); >> - fsbno = blkmap_get(cursor->blkmap, dabno); >> - >> - if (fsbno == NULLFSBLOCK) { >> - do_warn(_("can't get map info for block %u " >> - "of directory inode %" PRIu64 "\n"), >> + nex = blkmap_getn(cursor->blkmap, dabno, geo->fsbcount, >> + &bmp, &lbmp); >> + if (nex == 0) { >> + do_warn( >> +_("can't get map info for block %u of directory inode %" PRIu64 "\n"), >> dabno, cursor->ino); >> return(1); >> } >> >> - bp = libxfs_readbuf(mp->m_dev, XFS_FSB_TO_DADDR(mp, fsbno), >> - XFS_FSB_TO_BB(mp, 1), 0, &xfs_da3_node_buf_ops); >> + fsbno = bmp[0].startblock; >> + >> + bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); >> + if (bmp != &lbmp) >> + free(bmp); >> + >> if (!bp) { >> do_warn( >> _("can't read block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), >> @@ -577,7 +594,7 @@ verify_da_path(xfs_mount_t *mp, >> dabno, fsbno, cursor->ino); >> bad++; >> } >> - if (nodehdr.count > mp->m_attr_geo->node_ents) { >> + if (nodehdr.count > geo->node_ents) { >> do_warn( >> _("entry count %d too large in block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), >> nodehdr.count, >> diff --git a/repair/dir2.c b/repair/dir2.c >> index 54c49eb..44367c6 100644 >> --- a/repair/dir2.c >> +++ b/repair/dir2.c >> @@ -92,7 +92,7 @@ namecheck(char *name, int length) >> * Multibuffer handling. >> * V2 directory blocks can be noncontiguous, needing multiple buffers. >> */ >> -static struct xfs_buf * >> +struct xfs_buf * >> da_read_buf( >> xfs_mount_t *mp, >> int nex, >> @@ -143,9 +143,12 @@ traverse_int_dir2block(xfs_mount_t *mp, >> int nex; >> xfs_da_intnode_t *node; >> bmap_ext_t lbmp; >> + struct xfs_da_geometry *geo; >> struct xfs_da_node_entry *btree; >> struct xfs_da3_icnode_hdr nodehdr; >> >> + geo = mp->m_dir_geo; >> + >> /* >> * traverse down left-side of tree until we hit the >> * left-most leaf block setting up the btree cursor along >> @@ -161,7 +164,7 @@ traverse_int_dir2block(xfs_mount_t *mp, >> * read in each block along the way and set up cursor >> */ >> nex = blkmap_getn(da_cursor->blkmap, bno, >> - mp->m_dir_geo->fsbcount, &bmp, &lbmp); >> + geo->fsbcount, &bmp, &lbmp); >> >> if (nex == 0) >> goto error_out; >> @@ -207,13 +210,11 @@ _("corrupt tree block %u for directory inode %" PRIu64 "\n"), >> goto error_out; >> } >> btree = M_DIROPS(mp)->node_tree_p(node); >> - if (nodehdr.count > mp->m_dir_geo->node_ents) { >> - libxfs_putbuf(bp); >> + if (nodehdr.count > geo->node_ents) { >> do_warn( >> _("bad record count in inode %" PRIu64 ", count = %d, max = %d\n"), >> - da_cursor->ino, >> - nodehdr.count, >> - mp->m_dir_geo->node_ents); >> + da_cursor->ino, nodehdr.count, geo->node_ents); >> + libxfs_putbuf(bp); >> goto error_out; >> } >> /* >> @@ -488,9 +489,12 @@ verify_dir2_path(xfs_mount_t *mp, >> bmap_ext_t *bmp; >> int nex; >> bmap_ext_t lbmp; >> + struct xfs_da_geometry *geo; >> struct xfs_da_node_entry *btree; >> struct xfs_da3_icnode_hdr nodehdr; >> >> + geo = mp->m_dir_geo; >> + >> /* >> * index is currently set to point to the entry that >> * should be processed now in this level. >> @@ -532,7 +536,7 @@ verify_dir2_path(xfs_mount_t *mp, >> */ >> dabno = nodehdr.forw; >> ASSERT(dabno != 0); >> - nex = blkmap_getn(cursor->blkmap, dabno, mp->m_dir_geo->fsbcount, >> + nex = blkmap_getn(cursor->blkmap, dabno, geo->fsbcount, >> &bmp, &lbmp); >> if (nex == 0) { >> do_warn( >> @@ -574,7 +578,7 @@ _("bad back pointer in block %u for directory inode %" PRIu64 "\n"), >> dabno, cursor->ino); >> bad++; >> } >> - if (nodehdr.count > mp->m_dir_geo->node_ents) { >> + if (nodehdr.count > geo->node_ents) { >> do_warn( >> _("entry count %d too large in block %u for directory inode %" PRIu64 "\n"), >> nodehdr.count, >> diff --git a/repair/dir2.h b/repair/dir2.h >> index 3cc1941..186633f 100644 >> --- a/repair/dir2.h >> +++ b/repair/dir2.h >> @@ -58,6 +58,14 @@ typedef struct dir2_bt_cursor { >> struct blkmap *blkmap; >> } dir2_bt_cursor_t; >> >> +#include "bmap.h" /* Goes away in later refactoring */ >> +struct xfs_buf * >> +da_read_buf( >> + xfs_mount_t *mp, >> + int nex, >> + bmap_ext_t *bmp, >> + const struct xfs_buf_ops *ops); >> + >> int >> process_dir2( >> xfs_mount_t *mp, >> -- >> 1.7.1 >> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs > From bfoster@redhat.com Mon Sep 14 14:30:27 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 731CB7F37 for ; Mon, 14 Sep 2015 14:30:27 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 6301C8F8037 for ; Mon, 14 Sep 2015 12:30:27 -0700 (PDT) X-ASG-Debug-ID: 1442259025-04cb6c355de2020001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id rPAk6iGZ7uxQR0Sa (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 12:30:25 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 6A1A9A2C00; Mon, 14 Sep 2015 19:30:25 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJUOVI003378; Mon, 14 Sep 2015 15:30:25 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 8F8EA124BCD; Mon, 14 Sep 2015 15:30:23 -0400 (EDT) Date: Mon, 14 Sep 2015 15:30:23 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 04/13] xfs_repair: use multibuffer read routines in attr_repair.c Message-ID: <20150914193023.GG34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 04/13] xfs_repair: use multibuffer read routines in attr_repair.c References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-5-git-send-email-sandeen@sandeen.net> <20150914191816.GD34083@bfoster.bfoster> <55F71F05.90905@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55F71F05.90905@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1442259025 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Mon, Sep 14, 2015 at 02:24:53PM -0500, Eric Sandeen wrote: > > > On 9/14/15 2:18 PM, Brian Foster wrote: > > On Wed, Sep 09, 2015 at 02:34:02PM -0500, Eric Sandeen wrote: > >> verify_da_path and traverse_int_dablock are similar to > >> verify_dir2_path and traverse_int_dir2block, but one > >> difference is that the dir2 code reads using the > >> multibuffer capable da_read_buf() routine, whereas > >> the attr code doesn't need to, and just calls > >> libxfs_readbuf. > >> > >> The multibuffer code falls back just fine when the > >> geometry indicates that it's not needed, so use that > >> same code in the attribute routines, and remove > >> another dir2 / da difference. We make da_read_buf() > >> non-static to facilitate this. > >> > >> Finally, add a local *geo to these routines, > >> to make the code even more similar at this point. > >> The geometry will get passed in later in the series. > >> > >> Signed-off-by: Eric Sandeen > >> Signed-off-by: Eric Sandeen > >> --- > >> repair/attr_repair.c | 49 +++++++++++++++++++++++++++++++++---------------- > >> repair/dir2.c | 22 +++++++++++++--------- > >> repair/dir2.h | 8 ++++++++ > >> 3 files changed, 54 insertions(+), 25 deletions(-) > >> > >> diff --git a/repair/attr_repair.c b/repair/attr_repair.c > >> index aba0782..fe81df4 100644 > >> --- a/repair/attr_repair.c > >> +++ b/repair/attr_repair.c > >> @@ -138,14 +138,20 @@ traverse_int_dablock(xfs_mount_t *mp, > >> xfs_dablk_t *rbno, > >> int whichfork) > >> { > >> + bmap_ext_t *bmp; > > Well, yeah - I thought about that. The goal was to make it as close > as possible to the other code, so I decided against the struct foo's. > > I could do a "get rid of typedefs" as the last patch to the new util > code if you like. > Ah, right. Don't worry about this then. > > struct bmap_ext > > > > (and several other places below) > > > >> xfs_dablk_t bno; > >> int i; > >> + int nex; > >> xfs_da_intnode_t *node; > >> + bmap_ext_t lbmp; > >> xfs_fsblock_t fsbno; > >> xfs_buf_t *bp; > >> + struct xfs_da_geometry *geo; > >> struct xfs_da_node_entry *btree; > >> struct xfs_da3_icnode_hdr nodehdr; > >> > >> + geo = mp->m_attr_geo; > >> + > >> /* > >> * traverse down left-side of tree until we hit the > >> * left-most leaf block setting up the btree cursor along > >> @@ -160,13 +166,16 @@ traverse_int_dablock(xfs_mount_t *mp, > >> /* > >> * read in each block along the way and set up cursor > >> */ > >> - fsbno = blkmap_get(da_cursor->blkmap, bno); > >> + nex = blkmap_getn(da_cursor->blkmap, bno, > >> + geo->fsbcount, &bmp, &lbmp); > >> > > > > ... > > attr_repair.c: In function ‘process_attributes’: > > attr_repair.c:185:5: warning: ‘fsbno’ may be used uninitialized in this function [-Wmaybe-uninitialized] > > hm, whoops. Well, it goes away in the long run, but I can still fix > that up. > I figured it might (haven't got that far yet), but I'd still rather not have regressions in the history if we can help it, even if transient. Brian > Thanks, > -Eric > > > do_warn( > > ... > > > > Brian > > > >> - if (fsbno == NULLFSBLOCK) > >> + if (nex == 0) > >> goto error_out; > >> > >> - bp = libxfs_readbuf(mp->m_dev, XFS_FSB_TO_DADDR(mp, fsbno), > >> - XFS_FSB_TO_BB(mp, 1), 0, &xfs_da3_node_buf_ops); > >> + bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); > >> + if (bmp != &lbmp) > >> + free(bmp); > >> + > >> if (!bp) { > >> if (whichfork == XFS_DATA_FORK) > >> do_warn( > >> @@ -192,12 +201,10 @@ traverse_int_dablock(xfs_mount_t *mp, > >> goto error_out; > >> } > >> > >> - if (nodehdr.count > mp->m_attr_geo->node_ents) { > >> + if (nodehdr.count > geo->node_ents) { > >> do_warn(_("bad record count in inode %" PRIu64 ", " > >> "count = %d, max = %d\n"), > >> - da_cursor->ino, > >> - nodehdr.count, > >> - mp->m_attr_geo->node_ents); > >> + da_cursor->ino, nodehdr.count, geo->node_ents); > >> libxfs_putbuf(bp); > >> goto error_out; > >> } > >> @@ -492,9 +499,15 @@ verify_da_path(xfs_mount_t *mp, > >> int bad; > >> int entry; > >> int this_level = p_level + 1; > >> + bmap_ext_t *bmp; > >> + int nex; > >> + bmap_ext_t lbmp; > >> + struct xfs_da_geometry *geo; > >> struct xfs_da_node_entry *btree; > >> struct xfs_da3_icnode_hdr nodehdr; > >> > >> + geo = mp->m_attr_geo; > >> + > >> /* > >> * index is currently set to point to the entry that > >> * should be processed now in this level. > >> @@ -536,17 +549,21 @@ verify_da_path(xfs_mount_t *mp, > >> */ > >> dabno = nodehdr.forw; > >> ASSERT(dabno != 0); > >> - fsbno = blkmap_get(cursor->blkmap, dabno); > >> - > >> - if (fsbno == NULLFSBLOCK) { > >> - do_warn(_("can't get map info for block %u " > >> - "of directory inode %" PRIu64 "\n"), > >> + nex = blkmap_getn(cursor->blkmap, dabno, geo->fsbcount, > >> + &bmp, &lbmp); > >> + if (nex == 0) { > >> + do_warn( > >> +_("can't get map info for block %u of directory inode %" PRIu64 "\n"), > >> dabno, cursor->ino); > >> return(1); > >> } > >> > >> - bp = libxfs_readbuf(mp->m_dev, XFS_FSB_TO_DADDR(mp, fsbno), > >> - XFS_FSB_TO_BB(mp, 1), 0, &xfs_da3_node_buf_ops); > >> + fsbno = bmp[0].startblock; > >> + > >> + bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); > >> + if (bmp != &lbmp) > >> + free(bmp); > >> + > >> if (!bp) { > >> do_warn( > >> _("can't read block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), > >> @@ -577,7 +594,7 @@ verify_da_path(xfs_mount_t *mp, > >> dabno, fsbno, cursor->ino); > >> bad++; > >> } > >> - if (nodehdr.count > mp->m_attr_geo->node_ents) { > >> + if (nodehdr.count > geo->node_ents) { > >> do_warn( > >> _("entry count %d too large in block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), > >> nodehdr.count, > >> diff --git a/repair/dir2.c b/repair/dir2.c > >> index 54c49eb..44367c6 100644 > >> --- a/repair/dir2.c > >> +++ b/repair/dir2.c > >> @@ -92,7 +92,7 @@ namecheck(char *name, int length) > >> * Multibuffer handling. > >> * V2 directory blocks can be noncontiguous, needing multiple buffers. > >> */ > >> -static struct xfs_buf * > >> +struct xfs_buf * > >> da_read_buf( > >> xfs_mount_t *mp, > >> int nex, > >> @@ -143,9 +143,12 @@ traverse_int_dir2block(xfs_mount_t *mp, > >> int nex; > >> xfs_da_intnode_t *node; > >> bmap_ext_t lbmp; > >> + struct xfs_da_geometry *geo; > >> struct xfs_da_node_entry *btree; > >> struct xfs_da3_icnode_hdr nodehdr; > >> > >> + geo = mp->m_dir_geo; > >> + > >> /* > >> * traverse down left-side of tree until we hit the > >> * left-most leaf block setting up the btree cursor along > >> @@ -161,7 +164,7 @@ traverse_int_dir2block(xfs_mount_t *mp, > >> * read in each block along the way and set up cursor > >> */ > >> nex = blkmap_getn(da_cursor->blkmap, bno, > >> - mp->m_dir_geo->fsbcount, &bmp, &lbmp); > >> + geo->fsbcount, &bmp, &lbmp); > >> > >> if (nex == 0) > >> goto error_out; > >> @@ -207,13 +210,11 @@ _("corrupt tree block %u for directory inode %" PRIu64 "\n"), > >> goto error_out; > >> } > >> btree = M_DIROPS(mp)->node_tree_p(node); > >> - if (nodehdr.count > mp->m_dir_geo->node_ents) { > >> - libxfs_putbuf(bp); > >> + if (nodehdr.count > geo->node_ents) { > >> do_warn( > >> _("bad record count in inode %" PRIu64 ", count = %d, max = %d\n"), > >> - da_cursor->ino, > >> - nodehdr.count, > >> - mp->m_dir_geo->node_ents); > >> + da_cursor->ino, nodehdr.count, geo->node_ents); > >> + libxfs_putbuf(bp); > >> goto error_out; > >> } > >> /* > >> @@ -488,9 +489,12 @@ verify_dir2_path(xfs_mount_t *mp, > >> bmap_ext_t *bmp; > >> int nex; > >> bmap_ext_t lbmp; > >> + struct xfs_da_geometry *geo; > >> struct xfs_da_node_entry *btree; > >> struct xfs_da3_icnode_hdr nodehdr; > >> > >> + geo = mp->m_dir_geo; > >> + > >> /* > >> * index is currently set to point to the entry that > >> * should be processed now in this level. > >> @@ -532,7 +536,7 @@ verify_dir2_path(xfs_mount_t *mp, > >> */ > >> dabno = nodehdr.forw; > >> ASSERT(dabno != 0); > >> - nex = blkmap_getn(cursor->blkmap, dabno, mp->m_dir_geo->fsbcount, > >> + nex = blkmap_getn(cursor->blkmap, dabno, geo->fsbcount, > >> &bmp, &lbmp); > >> if (nex == 0) { > >> do_warn( > >> @@ -574,7 +578,7 @@ _("bad back pointer in block %u for directory inode %" PRIu64 "\n"), > >> dabno, cursor->ino); > >> bad++; > >> } > >> - if (nodehdr.count > mp->m_dir_geo->node_ents) { > >> + if (nodehdr.count > geo->node_ents) { > >> do_warn( > >> _("entry count %d too large in block %u for directory inode %" PRIu64 "\n"), > >> nodehdr.count, > >> diff --git a/repair/dir2.h b/repair/dir2.h > >> index 3cc1941..186633f 100644 > >> --- a/repair/dir2.h > >> +++ b/repair/dir2.h > >> @@ -58,6 +58,14 @@ typedef struct dir2_bt_cursor { > >> struct blkmap *blkmap; > >> } dir2_bt_cursor_t; > >> > >> +#include "bmap.h" /* Goes away in later refactoring */ > >> +struct xfs_buf * > >> +da_read_buf( > >> + xfs_mount_t *mp, > >> + int nex, > >> + bmap_ext_t *bmp, > >> + const struct xfs_buf_ops *ops); > >> + > >> int > >> process_dir2( > >> xfs_mount_t *mp, > >> -- > >> 1.7.1 > >> > >> _______________________________________________ > >> xfs mailing list > >> xfs@oss.sgi.com > >> http://oss.sgi.com/mailman/listinfo/xfs > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Mon Sep 14 14:44:07 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id F26787F3F for ; Mon, 14 Sep 2015 14:44:06 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 8B699AC003 for ; Mon, 14 Sep 2015 12:44:06 -0700 (PDT) X-ASG-Debug-ID: 1442259844-04bdf04db5f3ea0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id xr5BJsJFI5syOohq (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 12:44:05 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 945BEA062E; Mon, 14 Sep 2015 19:44:04 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJi4Ma007405; Mon, 14 Sep 2015 15:44:04 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id BFB2F124BCD; Mon, 14 Sep 2015 15:44:02 -0400 (EDT) Date: Mon, 14 Sep 2015 15:44:02 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 07/13] xfs_repair: Remove BUF_PTR from attr_repair.c Message-ID: <20150914194402.GH34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 07/13] xfs_repair: Remove BUF_PTR from attr_repair.c References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-8-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441827251-13128-8-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1442259845 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:34:05PM -0500, Eric Sandeen wrote: > The BUF_PTR macro was removed from kernelspace a while ago > (6292604 xfs: Remove the macro XFS_BUF_PTR) but it lives > on in some parts of xfsprogs. dir2.c doesn't use it, > but similar code in attr_repair.c does. remove it from > attr_repair.c to converge the code. > > Remove a related but unnecessary cast from a *void b_addr > in dir2.c while we're at it. > > Signed-off-by: Eric Sandeen > Signed-off-by: Eric Sandeen > --- Reviewed-by: Brian Foster > repair/attr_repair.c | 12 ++++++------ > repair/dir2.c | 2 +- > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/repair/attr_repair.c b/repair/attr_repair.c > index fe81df4..5ae2356 100644 > --- a/repair/attr_repair.c > +++ b/repair/attr_repair.c > @@ -188,7 +188,7 @@ traverse_int_dablock(xfs_mount_t *mp, > goto error_out; > } > > - node = (xfs_da_intnode_t *)XFS_BUF_PTR(bp); > + node = bp->b_addr; > btree = M_DIROPS(mp)->node_tree_p(node); > M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); > > @@ -335,7 +335,7 @@ verify_final_da_path(xfs_mount_t *mp, > * in the block which should be the final (rightmost) entry > */ > entry = cursor->level[this_level].index; > - node = (xfs_da_intnode_t *)XFS_BUF_PTR(cursor->level[this_level].bp); > + node = cursor->level[this_level].bp->b_addr; > btree = M_DIROPS(mp)->node_tree_p(node); > M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); > > @@ -513,7 +513,7 @@ verify_da_path(xfs_mount_t *mp, > * should be processed now in this level. > */ > entry = cursor->level[this_level].index; > - node = (xfs_da_intnode_t *)XFS_BUF_PTR(cursor->level[this_level].bp); > + node = cursor->level[this_level].bp->b_addr; > btree = M_DIROPS(mp)->node_tree_p(node); > M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); > > @@ -571,7 +571,7 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), > return(1); > } > > - newnode = (xfs_da_intnode_t *)XFS_BUF_PTR(bp); > + newnode = bp->b_addr; > btree = M_DIROPS(mp)->node_tree_p(newnode); > M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, newnode); > > @@ -1040,7 +1040,7 @@ rmtval_get(xfs_mount_t *mp, xfs_ino_t ino, blkmap_t *blkmap, > ASSERT(mp->m_sb.sb_blocksize == XFS_BUF_COUNT(bp)); > > length = MIN(XFS_BUF_COUNT(bp) - hdrsize, valuelen - amountdone); > - memmove(value, XFS_BUF_PTR(bp) + hdrsize, length); > + memmove(value, bp->b_addr + hdrsize, length); > amountdone += length; > value += length; > i++; > @@ -1620,7 +1620,7 @@ process_longform_attr( > } > > /* verify leaf block */ > - leaf = (xfs_attr_leafblock_t *)XFS_BUF_PTR(bp); > + leaf = bp->b_addr; > xfs_attr3_leaf_hdr_from_disk(mp->m_attr_geo, &leafhdr, leaf); > > /* check sibling pointers in leaf block or root block 0 before > diff --git a/repair/dir2.c b/repair/dir2.c > index d9bd5fc..9398df5 100644 > --- a/repair/dir2.c > +++ b/repair/dir2.c > @@ -347,7 +347,7 @@ verify_final_dir2_path(xfs_mount_t *mp, > * in the block which should be the final (rightmost) entry > */ > entry = cursor->level[this_level].index; > - node = (xfs_da_intnode_t *)(cursor->level[this_level].bp->b_addr); > + node = cursor->level[this_level].bp->b_addr; > btree = M_DIROPS(mp)->node_tree_p(node); > M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); > > -- > 1.7.1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Mon Sep 14 14:44:11 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id F34FD7F54 for ; Mon, 14 Sep 2015 14:44:10 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id E56C78F8035 for ; Mon, 14 Sep 2015 12:44:10 -0700 (PDT) X-ASG-Debug-ID: 1442259849-04cb6c355be2470001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id YPhj1fhMK0AMM9O4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 12:44:10 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 64AC88E3C3; Mon, 14 Sep 2015 19:44:09 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJi9e8002641; Mon, 14 Sep 2015 15:44:09 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id B00D9124BCD; Mon, 14 Sep 2015 15:44:07 -0400 (EDT) Date: Mon, 14 Sep 2015 15:44:07 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 08/13] xfs_repair: catch bad level/depth in da node Message-ID: <20150914194407.GI34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 08/13] xfs_repair: catch bad level/depth in da node References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-9-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441827251-13128-9-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442259849 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:34:06PM -0500, Eric Sandeen wrote: > Two tests added some time ago to dir2.c: > > 44dae5e xfs_repair: test for bad level in dir2 node > 28148f6 xfs_repair: catch bad depth in traverse_int_dir2block > > never made it to the similar tree-walking code in attr_repair.c; > fix that up here. The error string details will be fixed up > later. > > Signed-off-by; Eric Sandeen > > Signed-off-by: Eric Sandeen > --- Reviewed-by: Brian Foster > repair/attr_repair.c | 12 ++++++++++-- > 1 files changed, 10 insertions(+), 2 deletions(-) > > diff --git a/repair/attr_repair.c b/repair/attr_repair.c > index 5ae2356..2aafdf6 100644 > --- a/repair/attr_repair.c > +++ b/repair/attr_repair.c > @@ -212,9 +212,17 @@ traverse_int_dablock(xfs_mount_t *mp, > /* > * maintain level counter > */ > - if (i == -1) > + if (i == -1) { > i = da_cursor->active = nodehdr.level; > - else { > + if (i < 1 || i >= XFS_DA_NODE_MAXDEPTH) { > + do_warn( > +_("bad header depth for directory inode %" PRIu64 "\n"), > + da_cursor->ino); > + libxfs_putbuf(bp); > + i = -1; > + goto error_out; > + } > + } else { > if (nodehdr.level == i - 1) { > i--; > } else { > -- > 1.7.1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Mon Sep 14 14:44:16 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 5ABD57F3F for ; Mon, 14 Sep 2015 14:44:16 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 2BE82304048 for ; Mon, 14 Sep 2015 12:44:15 -0700 (PDT) X-ASG-Debug-ID: 1442259854-04bdf04db4f3ec0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id ZPRorkQiIjGybivC (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 12:44:14 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 9187DA303F; Mon, 14 Sep 2015 19:44:14 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJiEv4010712; Mon, 14 Sep 2015 15:44:14 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id DF30C124BCD; Mon, 14 Sep 2015 15:44:12 -0400 (EDT) Date: Mon, 14 Sep 2015 15:44:12 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 09/13] xfs_repair: better checking of v5 attributes Message-ID: <20150914194412.GJ34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 09/13] xfs_repair: better checking of v5 attributes References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-10-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441827251-13128-10-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1442259854 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:34:07PM -0500, Eric Sandeen wrote: > The commit: > > 0519f66 xfs_repair: better checking of v5 metadata fields > > added new corruption checks to dir2.c but missed the similar > code in attr_repair.c; add that here. > > Signed-off-by: Eric Sandeen > Signed-off-by: Eric Sandeen > --- > repair/attr_repair.c | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/repair/attr_repair.c b/repair/attr_repair.c > index 2aafdf6..c8ba484 100644 > --- a/repair/attr_repair.c > +++ b/repair/attr_repair.c > @@ -201,6 +201,15 @@ traverse_int_dablock(xfs_mount_t *mp, > goto error_out; > } > > + /* corrupt node; rebuild the dir. */ > + if (bp->b_error == -EFSBADCRC || bp->b_error == -EFSCORRUPTED) { > + libxfs_putbuf(bp); > + do_warn( > +_("corrupt tree block %u for directory inode %" PRIu64 "\n"), > + bno, da_cursor->ino); > + goto error_out; > + } > + Hmm, well this certainly looks similar, but is it the right thing to do for xattrs? I haven't followed through how exactly directories are rebuilt, but there does appear to be a recovery path in the dir2 context. A failure there simply puts the inode on a "bad" list to be rebuilt later, presumably from data collected from all of the inodes. If we fail here, it looks like we just clear the attribute fork. So are we failing too hard, too soon here if a dablock crc happens to be incorrect? Brian > if (nodehdr.count > geo->node_ents) { > do_warn(_("bad record count in inode %" PRIu64 ", " > "count = %d, max = %d\n"), > -- > 1.7.1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Mon Sep 14 14:55:18 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 528E77F37 for ; Mon, 14 Sep 2015 14:55:18 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 30F9E8F8035 for ; Mon, 14 Sep 2015 12:55:17 -0700 (PDT) X-ASG-Debug-ID: 1442260516-04cbb005e9f9d70001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id ISj9iYrNA44H6liL (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 12:55:16 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 06A05461D4; Mon, 14 Sep 2015 19:55:15 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJtFSC008347; Mon, 14 Sep 2015 15:55:15 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id D0788124BCD; Mon, 14 Sep 2015 15:55:13 -0400 (EDT) Date: Mon, 14 Sep 2015 15:55:13 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 10/13] xfs_repair: Remove more differences between attr & dir2 Message-ID: <20150914195513.GK34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 10/13] xfs_repair: Remove more differences between attr & dir2 References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-11-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441827251-13128-11-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442260516 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:34:08PM -0500, Eric Sandeen wrote: > This is a hodgepodge of unrelated but not-completely-trivial > chagnes to both the dir2 and attr code to make their common > code more similar. > > * It removes the whichfork checking in attr_repair, because we > only get there with XFS_ATTR_FORK. > * It changes the magic-checking logic slightly to match. > * It swaps some (bp == NULL) tests for (!bp) > > These should be purely cosmetic changes. > > Signed-off-by: Eric Sandeen > Signed-off-by: Eric Sandeen > --- Reviewed-by: Brian Foster > repair/attr_repair.c | 20 +++++--------------- > repair/dir2.c | 14 ++++++++------ > 2 files changed, 13 insertions(+), 21 deletions(-) > > diff --git a/repair/attr_repair.c b/repair/attr_repair.c > index c8ba484..26a0e71 100644 > --- a/repair/attr_repair.c > +++ b/repair/attr_repair.c > @@ -177,19 +177,13 @@ traverse_int_dablock(xfs_mount_t *mp, > free(bmp); > > if (!bp) { > - if (whichfork == XFS_DATA_FORK) > - do_warn( > - _("can't read block %u (fsbno %" PRIu64 ") for directory inode %" PRIu64 "\n"), > - bno, fsbno, da_cursor->ino); > - else > - do_warn( > + do_warn( > _("can't read block %u (fsbno %" PRIu64 ") for attrbute fork of inode %" PRIu64 "\n"), > bno, fsbno, da_cursor->ino); > goto error_out; > } > > node = bp->b_addr; > - btree = M_DIROPS(mp)->node_tree_p(node); > M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); > > if (nodehdr.magic != XFS_DA_NODE_MAGIC && > @@ -210,6 +204,7 @@ _("corrupt tree block %u for directory inode %" PRIu64 "\n"), > goto error_out; > } > > + btree = M_DIROPS(mp)->node_tree_p(node); > if (nodehdr.count > geo->node_ents) { > do_warn(_("bad record count in inode %" PRIu64 ", " > "count = %d, max = %d\n"), > @@ -235,14 +230,9 @@ _("bad header depth for directory inode %" PRIu64 "\n"), > if (nodehdr.level == i - 1) { > i--; > } else { > - if (whichfork == XFS_DATA_FORK) > - do_warn(_("bad directory btree for " > - "directory inode %" PRIu64 "\n"), > - da_cursor->ino); > - else > - do_warn(_("bad attribute fork btree " > - "for inode %" PRIu64 "\n"), > - da_cursor->ino); > + do_warn(_("bad attribute fork btree " > + "for inode %" PRIu64 "\n"), > + da_cursor->ino); > libxfs_putbuf(bp); > goto error_out; > } > diff --git a/repair/dir2.c b/repair/dir2.c > index 9398df5..8cf981f 100644 > --- a/repair/dir2.c > +++ b/repair/dir2.c > @@ -172,7 +172,7 @@ traverse_int_dir2block(xfs_mount_t *mp, > bp = da_read_buf(mp, nex, bmp, &xfs_da3_node_buf_ops); > if (bmp != &lbmp) > free(bmp); > - if (bp == NULL) { > + if (!bp) { > do_warn( > _("can't read block %u for directory inode %" PRIu64 "\n"), > bno, da_cursor->ino); > @@ -192,8 +192,10 @@ _("found non-root LEAFN node in inode %" PRIu64 " bno = %u\n"), > *rbno = 0; > libxfs_putbuf(bp); > return(1); > - } else if (!(nodehdr.magic == XFS_DA_NODE_MAGIC || > - nodehdr.magic == XFS_DA3_NODE_MAGIC)) { > + } > + > + if (nodehdr.magic != XFS_DA_NODE_MAGIC && > + nodehdr.magic != XFS_DA3_NODE_MAGIC) { > libxfs_putbuf(bp); > do_warn( > _("bad dir magic number 0x%x in inode %" PRIu64 " bno = %u\n"), > @@ -574,7 +576,7 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), > if (bmp != &lbmp) > free(bmp); > > - if (bp == NULL) { > + if (!bp) { > do_warn( > _("can't read block %u for directory inode %" PRIu64 "\n"), > dabno, cursor->ino); > @@ -589,8 +591,8 @@ _("can't read block %u for directory inode %" PRIu64 "\n"), > * entry count, verify level > */ > bad = 0; > - if (!(nodehdr.magic == XFS_DA_NODE_MAGIC || > - nodehdr.magic == XFS_DA3_NODE_MAGIC)) { > + if (nodehdr.magic != XFS_DA_NODE_MAGIC && > + nodehdr.magic != XFS_DA3_NODE_MAGIC) { > do_warn( > _("bad magic number %x in block %u for directory inode %" PRIu64 "\n"), > nodehdr.magic, > -- > 1.7.1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Mon Sep 14 14:56:14 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id D3D827F37 for ; Mon, 14 Sep 2015 14:56:14 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 922EC8F8037 for ; Mon, 14 Sep 2015 12:56:14 -0700 (PDT) X-ASG-Debug-ID: 1442260571-04bdf04db5f4300001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 1LqVMwGbea4HS58Z (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 12:56:12 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id BC5C2C0AD289; Mon, 14 Sep 2015 19:56:11 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EJuBaw012933; Mon, 14 Sep 2015 15:56:11 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id E0E25124BCD; Mon, 14 Sep 2015 15:56:09 -0400 (EDT) Date: Mon, 14 Sep 2015 15:56:09 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 11/13] xfs_repair: whitespace & comments Message-ID: <20150914195609.GL34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 11/13] xfs_repair: whitespace & comments References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-12-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441827251-13128-12-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442260572 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:34:09PM -0500, Eric Sandeen wrote: > This patch does nothing but fix up whitespace and comments > to match across dir2.c and attr_repair.c > > At this point, a diff of repair/dir2.c and attr_repair.c > show them to be identical in function. > > Signed-off-by: Eric Sandeen > Signed-off-by: Eric Sandeen > --- Reviewed-by: Brian Foster > repair/attr_repair.c | 36 ++++++++++++++++++------------------ > repair/dir2.c | 46 ++++++++++++++++++++++++---------------------- > 2 files changed, 42 insertions(+), 40 deletions(-) > > diff --git a/repair/attr_repair.c b/repair/attr_repair.c > index 26a0e71..0804a22 100644 > --- a/repair/attr_repair.c > +++ b/repair/attr_repair.c > @@ -187,7 +187,7 @@ traverse_int_dablock(xfs_mount_t *mp, > M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); > > if (nodehdr.magic != XFS_DA_NODE_MAGIC && > - nodehdr.magic != XFS_DA3_NODE_MAGIC) { > + nodehdr.magic != XFS_DA3_NODE_MAGIC) { > do_warn(_("bad dir/attr magic number in inode %" PRIu64 ", " > "file bno = %u, fsbno = %" PRIu64 "\n"), > da_cursor->ino, bno, fsbno); > @@ -205,7 +205,7 @@ _("corrupt tree block %u for directory inode %" PRIu64 "\n"), > } > > btree = M_DIROPS(mp)->node_tree_p(node); > - if (nodehdr.count > geo->node_ents) { > + if (nodehdr.count > geo->node_ents) { > do_warn(_("bad record count in inode %" PRIu64 ", " > "count = %d, max = %d\n"), > da_cursor->ino, nodehdr.count, geo->node_ents); > @@ -226,10 +226,10 @@ _("bad header depth for directory inode %" PRIu64 "\n"), > i = -1; > goto error_out; > } > - } else { > - if (nodehdr.level == i - 1) { > + } else { > + if (nodehdr.level == i - 1) { > i--; > - } else { > + } else { > do_warn(_("bad attribute fork btree " > "for inode %" PRIu64 "\n"), > da_cursor->ino); > @@ -256,7 +256,7 @@ _("bad header depth for directory inode %" PRIu64 "\n"), > return(1); > > error_out: > - while (i > 1 && i <= da_cursor->active) { > + while (i > 1 && i <= da_cursor->active) { > libxfs_putbuf(da_cursor->level[i].bp); > i++; > } > @@ -351,7 +351,7 @@ verify_final_da_path(xfs_mount_t *mp, > * that all entries are used, encountered and expected hashvals > * match, etc. > */ > - if (entry != nodehdr.count - 1) { > + if (entry != nodehdr.count - 1) { > do_warn(_("directory/attribute block used/count " > "inconsistency - %d/%hu\n"), > entry, nodehdr.count); > @@ -368,7 +368,7 @@ verify_final_da_path(xfs_mount_t *mp, > be32_to_cpu(btree[entry].hashval)); > bad++; > } > - if (nodehdr.forw != 0) { > + if (nodehdr.forw != 0) { > do_warn(_("bad directory/attribute forward block pointer, " > "expected 0, saw %u\n"), > nodehdr.forw); > @@ -402,7 +402,7 @@ verify_final_da_path(xfs_mount_t *mp, > } > > if (cursor->level[p_level].hashval != be32_to_cpu(btree[entry].hashval)) { > - if (!no_modify) { > + if (!no_modify) { > do_warn(_("correcting bad hashval in non-leaf " > "dir/attr block\n\tin (level %d) in " > "inode %" PRIu64 ".\n"), > @@ -410,7 +410,7 @@ verify_final_da_path(xfs_mount_t *mp, > btree[entry].hashval = cpu_to_be32( > cursor->level[p_level].hashval); > cursor->level[this_level].dirty++; > - } else { > + } else { > do_warn(_("would correct bad hashval in non-leaf " > "dir/attr block\n\tin (level %d) in " > "inode %" PRIu64 ".\n"), > @@ -440,7 +440,7 @@ verify_final_da_path(xfs_mount_t *mp, > /* > * bail out if this is the root block (top of tree) > */ > - if (this_level >= cursor->active) { > + if (this_level >= cursor->active) { > #ifdef XR_DIR_TRACE > fprintf(stderr, "verify_final_da_path returns 0 (ok)\n"); > #endif > @@ -529,7 +529,7 @@ verify_da_path(xfs_mount_t *mp, > * block and move on to the next block. > * and update cursor value for said level > */ > - if (entry >= nodehdr.count) { > + if (entry >= nodehdr.count) { > /* > * update the hash value for this level before > * validating it. bno value should be ok since > @@ -588,7 +588,7 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), > */ > bad = 0; > if (nodehdr.magic != XFS_DA_NODE_MAGIC && > - nodehdr.magic != XFS_DA3_NODE_MAGIC) { > + nodehdr.magic != XFS_DA3_NODE_MAGIC) { > do_warn( > _("bad magic number %x in block %u (%" PRIu64 ") for directory inode %" PRIu64 "\n"), > nodehdr.magic, > @@ -615,7 +615,7 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), > dabno, fsbno, cursor->ino); > bad++; > } > - if (bad) { > + if (bad) { > #ifdef XR_DIR_TRACE > fprintf(stderr, "verify_da_path returns 1 (bad) #4\n"); > #endif > @@ -654,7 +654,7 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), > /* > * ditto for block numbers > */ > - if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { > + if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { > #ifdef XR_DIR_TRACE > fprintf(stderr, "bad directory btree pointer, child bno " > "should be %d, block bno is %d, hashval is %u\n", > @@ -670,8 +670,8 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), > * block against the hashval in the current entry > */ > if (cursor->level[p_level].hashval != > - be32_to_cpu(btree[entry].hashval)) { > - if (!no_modify) { > + be32_to_cpu(btree[entry].hashval)) { > + if (!no_modify) { > do_warn(_("correcting bad hashval in interior " > "dir/attr block\n\tin (level %d) in " > "inode %" PRIu64 ".\n"), > @@ -679,7 +679,7 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), > btree[entry].hashval = cpu_to_be32( > cursor->level[p_level].hashval); > cursor->level[this_level].dirty++; > - } else { > + } else { > do_warn(_("would correct bad hashval in interior " > "dir/attr block\n\tin (level %d) in " > "inode %" PRIu64 ".\n"), > diff --git a/repair/dir2.c b/repair/dir2.c > index 8cf981f..7b47a9e 100644 > --- a/repair/dir2.c > +++ b/repair/dir2.c > @@ -183,7 +183,7 @@ _("can't read block %u for directory inode %" PRIu64 "\n"), > M_DIROPS(mp)->node_hdr_from_disk(&nodehdr, node); > > if (nodehdr.magic == XFS_DIR2_LEAFN_MAGIC || > - nodehdr.magic == XFS_DIR3_LEAFN_MAGIC) { > + nodehdr.magic == XFS_DIR3_LEAFN_MAGIC) { > if ( i != -1 ) { > do_warn( > _("found non-root LEAFN node in inode %" PRIu64 " bno = %u\n"), > @@ -195,7 +195,7 @@ _("found non-root LEAFN node in inode %" PRIu64 " bno = %u\n"), > } > > if (nodehdr.magic != XFS_DA_NODE_MAGIC && > - nodehdr.magic != XFS_DA3_NODE_MAGIC) { > + nodehdr.magic != XFS_DA3_NODE_MAGIC) { > libxfs_putbuf(bp); > do_warn( > _("bad dir magic number 0x%x in inode %" PRIu64 " bno = %u\n"), > @@ -212,7 +212,7 @@ _("corrupt tree block %u for directory inode %" PRIu64 "\n"), > goto error_out; > } > btree = M_DIROPS(mp)->node_tree_p(node); > - if (nodehdr.count > geo->node_ents) { > + if (nodehdr.count > geo->node_ents) { > do_warn( > _("bad record count in inode %" PRIu64 ", count = %d, max = %d\n"), > da_cursor->ino, nodehdr.count, geo->node_ents); > @@ -233,9 +233,9 @@ _("bad header depth for directory inode %" PRIu64 "\n"), > goto error_out; > } > } else { > - if (nodehdr.level == i - 1) { > + if (nodehdr.level == i - 1) { > i--; > - } else { > + } else { > do_warn( > _("bad directory btree for directory inode %" PRIu64 "\n"), > da_cursor->ino); > @@ -262,7 +262,7 @@ _("bad directory btree for directory inode %" PRIu64 "\n"), > return(1); > > error_out: > - while (i > 1 && i <= da_cursor->active) { > + while (i > 1 && i <= da_cursor->active) { > libxfs_putbuf(da_cursor->level[i].bp); > i++; > } > @@ -358,7 +358,7 @@ verify_final_dir2_path(xfs_mount_t *mp, > * that all entries are used, encountered and expected hashvals > * match, etc. > */ > - if (entry != nodehdr.count - 1) { > + if (entry != nodehdr.count - 1) { > do_warn( > _("directory block used/count inconsistency - %d / %hu\n"), > entry, nodehdr.count); > @@ -368,20 +368,20 @@ verify_final_dir2_path(xfs_mount_t *mp, > * hash values monotonically increasing ??? > */ > if (cursor->level[this_level].hashval >= > - be32_to_cpu(btree[entry].hashval)) { > + be32_to_cpu(btree[entry].hashval)) { > do_warn(_("directory/attribute block hashvalue inconsistency, " > "expected > %u / saw %u\n"), > cursor->level[this_level].hashval, > be32_to_cpu(btree[entry].hashval)); > bad++; > } > - if (nodehdr.forw != 0) { > + if (nodehdr.forw != 0) { > do_warn(_("bad directory/attribute forward block pointer, " > "expected 0, saw %u\n"), > nodehdr.forw); > bad++; > } > - if (bad) { > + if (bad) { > do_warn(_("bad directory block in inode %" PRIu64 "\n"), cursor->ino); > return(1); > } > @@ -408,8 +408,8 @@ verify_final_dir2_path(xfs_mount_t *mp, > } > > if (cursor->level[p_level].hashval != > - be32_to_cpu(btree[entry].hashval)) { > - if (!no_modify) { > + be32_to_cpu(btree[entry].hashval)) { > + if (!no_modify) { > do_warn( > _("correcting bad hashval in non-leaf dir block\n" > "\tin (level %d) in inode %" PRIu64 ".\n"), > @@ -417,7 +417,7 @@ _("correcting bad hashval in non-leaf dir block\n" > btree[entry].hashval = cpu_to_be32( > cursor->level[p_level].hashval); > cursor->level[this_level].dirty++; > - } else { > + } else { > do_warn( > _("would correct bad hashval in non-leaf dir block\n" > "\tin (level %d) in inode %" PRIu64 ".\n"), > @@ -454,7 +454,7 @@ _("would correct bad hashval in non-leaf dir block\n" > return(0); > } > /* > - * set hashvalue to correctl reflect the now-validated > + * set hashvalue to correctly reflect the now-validated > * last entry in this block and continue upwards validation > */ > cursor->level[this_level].hashval = hashval; > @@ -536,7 +536,7 @@ verify_dir2_path(xfs_mount_t *mp, > * block and move on to the next block. > * and update cursor value for said level > */ > - if (entry >= nodehdr.count) { > + if (entry >= nodehdr.count) { > /* > * update the hash value for this level before > * validating it. bno value should be ok since > @@ -599,27 +599,27 @@ _("bad magic number %x in block %u for directory inode %" PRIu64 "\n"), > dabno, cursor->ino); > bad++; > } > - if (nodehdr.back != cursor->level[this_level].bno) { > + if (nodehdr.back != cursor->level[this_level].bno) { > do_warn( > _("bad back pointer in block %u for directory inode %" PRIu64 "\n"), > dabno, cursor->ino); > bad++; > } > - if (nodehdr.count > geo->node_ents) { > + if (nodehdr.count > geo->node_ents) { > do_warn( > _("entry count %d too large in block %u for directory inode %" PRIu64 "\n"), > nodehdr.count, > dabno, cursor->ino); > bad++; > } > - if (nodehdr.level != this_level) { > + if (nodehdr.level != this_level) { > do_warn( > _("bad level %d in block %u for directory inode %" PRIu64 "\n"), > nodehdr.level, > dabno, cursor->ino); > bad++; > } > - if (bad) { > + if (bad) { > #ifdef XR_DIR_TRACE > fprintf(stderr, "verify_dir2_path returns 1 (bad) #4\n"); > #endif > @@ -643,6 +643,8 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), > libxfs_writebuf(cursor->level[this_level].bp, 0); > else > libxfs_putbuf(cursor->level[this_level].bp); > + > + /* switch cursor to point at the new buffer we just read */ > cursor->level[this_level].bp = bp; > cursor->level[this_level].dirty = 0; > cursor->level[this_level].bno = dabno; > @@ -670,8 +672,8 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), > * block against the hashval in the current entry > */ > if (cursor->level[p_level].hashval != > - be32_to_cpu(btree[entry].hashval)) { > - if (!no_modify) { > + be32_to_cpu(btree[entry].hashval)) { > + if (!no_modify) { > do_warn( > _("correcting bad hashval in interior dir block\n" > "\tin (level %d) in inode %" PRIu64 ".\n"), > @@ -679,7 +681,7 @@ _("correcting bad hashval in interior dir block\n" > btree[entry].hashval = cpu_to_be32( > cursor->level[p_level].hashval); > cursor->level[this_level].dirty++; > - } else { > + } else { > do_warn( > _("would correct bad hashval in interior dir block\n" > "\tin (level %d) in inode %" PRIu64 ".\n"), > -- > 1.7.1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Mon Sep 14 15:06:25 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 06BD07F37 for ; Mon, 14 Sep 2015 15:06:25 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id E708C304048 for ; Mon, 14 Sep 2015 13:06:21 -0700 (PDT) X-ASG-Debug-ID: 1442261179-04cb6c355be2d90001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id XKyF8NwUBTDafQ1t (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 14 Sep 2015 13:06:20 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 7D915C0B200E; Mon, 14 Sep 2015 20:06:19 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8EK6JAX023176; Mon, 14 Sep 2015 16:06:19 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id AE162124BCD; Mon, 14 Sep 2015 16:06:17 -0400 (EDT) Date: Mon, 14 Sep 2015 16:06:17 -0400 From: Brian Foster To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 13/13] xfs_repair: Fix up warning strings in da_util.c Message-ID: <20150914200617.GM34083@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH 13/13] xfs_repair: Fix up warning strings in da_util.c References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-14-git-send-email-sandeen@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441827251-13128-14-git-send-email-sandeen@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1442261180 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 09, 2015 at 02:34:11PM -0500, Eric Sandeen wrote: > Switch the warning messages based on which fork has > encountered the problem. > > Signed-off-by: Eric Sandeen > Signed-off-by: Eric Sandeen > --- I assume this is being reworked based on the discussion with Carlos (and I'm really not familiar with the localization stuff). That aside, shouldn't this be ordered at some point before these functions are called from both directory and attribute contexts so the messages aren't ever incorrect? Also, one nit below... > repair/attr_repair.c | 2 +- > repair/da_util.c | 97 +++++++++++++++++++++++++++----------------------- > repair/da_util.h | 3 +- > repair/dir2.c | 2 +- > 4 files changed, 56 insertions(+), 48 deletions(-) > ... > diff --git a/repair/da_util.c b/repair/da_util.c > index e5d5535..89d41cc 100644 > --- a/repair/da_util.c > +++ b/repair/da_util.c ... > @@ -361,25 +366,27 @@ verify_final_da_path( > */ > if (cursor->level[this_level].hashval >= > be32_to_cpu(btree[entry].hashval)) { > - do_warn(_("directory/attribute block hashvalue inconsistency, " > - "expected > %u / saw %u\n"), > + do_warn( > +_("%s block hashvalue inconsistency, expected > %u / saw %u\n"), > + FORKNAME(whichfork), > cursor->level[this_level].hashval, > be32_to_cpu(btree[entry].hashval)); > bad++; > } > if (nodehdr.forw != 0) { > - do_warn(_("bad directory/attribute forward block pointer, " > - "expected 0, saw %u\n"), > - nodehdr.forw); > + do_warn( > +_("bad %s forward block pointer, expected 0, saw %u\n"), > + FORKNAME(whichfork), nodehdr.forw); > bad++; > } > if (bad) { > - do_warn(_("bad directory block in inode %" PRIu64 "\n"), cursor->ino); > + do_warn(_("bad %s block in inode %" PRIu64 "\n"), > + FORKNAME(whichfork), cursor->ino); > return 1; > } > /* > * keep track of greatest block # -- that gets > - * us the length of the directory > + * us the length of the directory/attribute Trailing whitespace above. Brian > */ > if (cursor->level[this_level].bno > cursor->greatest_bno) > cursor->greatest_bno = cursor->level[this_level].bno; > @@ -389,9 +396,9 @@ verify_final_da_path( > */ > if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { > #ifdef XR_DIR_TRACE > - fprintf(stderr, "bad directory btree pointer, child bno should " > + fprintf(stderr, "bad %s btree pointer, child bno should " > "be %d, block bno is %d, hashval is %u\n", > - be16_to_cpu(btree[entry].before), > + FORKNAME(whichfork), be16_to_cpu(btree[entry].before), > cursor->level[p_level].bno, > cursor->level[p_level].hashval); > fprintf(stderr, "verify_final_da_path returns 1 (bad) #1a\n"); > @@ -403,17 +410,17 @@ verify_final_da_path( > be32_to_cpu(btree[entry].hashval)) { > if (!no_modify) { > do_warn( > -_("correcting bad hashval in non-leaf dir block\n" > +_("correcting bad hashval in non-leaf %s block\n" > "\tin (level %d) in inode %" PRIu64 ".\n"), > - this_level, cursor->ino); > + FORKNAME(whichfork), this_level, cursor->ino); > btree[entry].hashval = cpu_to_be32( > cursor->level[p_level].hashval); > cursor->level[this_level].dirty++; > } else { > do_warn( > -_("would correct bad hashval in non-leaf dir block\n" > +_("would correct bad hashval in non-leaf %s block\n" > "\tin (level %d) in inode %" PRIu64 ".\n"), > - this_level, cursor->ino); > + FORKNAME(whichfork), this_level, cursor->ino); > } > } > > @@ -451,7 +458,7 @@ _("would correct bad hashval in non-leaf dir block\n" > */ > cursor->level[this_level].hashval = hashval; > > - return verify_final_da_path(mp, cursor, this_level); > + return verify_final_da_path(mp, cursor, this_level, whichfork); > } > > /* > @@ -564,8 +571,8 @@ verify_da_path( > &bmp, &lbmp); > if (nex == 0) { > do_warn( > -_("can't get map info for block %u of directory inode %" PRIu64 "\n"), > - dabno, cursor->ino); > +_("can't get map info for %s block %u of inode %" PRIu64 "\n"), > + FORKNAME(whichfork), dabno, cursor->ino); > return 1; > } > > @@ -575,8 +582,8 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), > > if (!bp) { > do_warn( > -_("can't read block %u for directory inode %" PRIu64 "\n"), > - dabno, cursor->ino); > +_("can't read %s block %u for inode %" PRIu64 "\n"), > + FORKNAME(whichfork), dabno, cursor->ino); > return 1; > } > > @@ -592,28 +599,28 @@ _("can't read block %u for directory inode %" PRIu64 "\n"), > if (nodehdr.magic != XFS_DA_NODE_MAGIC && > nodehdr.magic != XFS_DA3_NODE_MAGIC) { > do_warn( > -_("bad magic number %x in block %u for directory inode %" PRIu64 "\n"), > - nodehdr.magic, > +_("bad magic number %x in %s block %u for inode %" PRIu64 "\n"), > + nodehdr.magic, FORKNAME(whichfork), > dabno, cursor->ino); > bad++; > } > if (nodehdr.back != cursor->level[this_level].bno) { > do_warn( > -_("bad back pointer in block %u for directory inode %" PRIu64 "\n"), > - dabno, cursor->ino); > +_("bad back pointer in %s block %u for inode %" PRIu64 "\n"), > + FORKNAME(whichfork), dabno, cursor->ino); > bad++; > } > if (nodehdr.count > geo->node_ents) { > do_warn( > -_("entry count %d too large in block %u for directory inode %" PRIu64 "\n"), > - nodehdr.count, > +_("entry count %d too large in %s block %u for inode %" PRIu64 "\n"), > + nodehdr.count, FORKNAME(whichfork), > dabno, cursor->ino); > bad++; > } > if (nodehdr.level != this_level) { > do_warn( > -_("bad level %d in block %u for directory inode %" PRIu64 "\n"), > - nodehdr.level, > +_("bad level %d in %s block %u for inode %" PRIu64 "\n"), > + nodehdr.level, FORKNAME(whichfork), > dabno, cursor->ino); > bad++; > } > @@ -659,9 +666,9 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), > */ > if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { > #ifdef XR_DIR_TRACE > - fprintf(stderr, "bad directory btree pointer, child bno " > + fprintf(stderr, "bad %s btree pointer, child bno " > "should be %d, block bno is %d, hashval is %u\n", > - be32_to_cpu(btree[entry].before), > + FORKNAME(whichfork), be32_to_cpu(btree[entry].before), > cursor->level[p_level].bno, > cursor->level[p_level].hashval); > fprintf(stderr, "verify_da_path returns 1 (bad) #1a\n"); > @@ -676,17 +683,17 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), > be32_to_cpu(btree[entry].hashval)) { > if (!no_modify) { > do_warn( > -_("correcting bad hashval in interior dir block\n" > +_("correcting bad hashval in interior %s block\n" > "\tin (level %d) in inode %" PRIu64 ".\n"), > - this_level, cursor->ino); > + FORKNAME(whichfork), this_level, cursor->ino); > btree[entry].hashval = cpu_to_be32( > cursor->level[p_level].hashval); > cursor->level[this_level].dirty++; > } else { > do_warn( > -_("would correct bad hashval in interior dir block\n" > +_("would correct bad hashval in interior %s block\n" > "\tin (level %d) in inode %" PRIu64 ".\n"), > - this_level, cursor->ino); > + FORKNAME(whichfork), this_level, cursor->ino); > } > } > /* > diff --git a/repair/da_util.h b/repair/da_util.h > index 7971d63..442f9f1 100644 > --- a/repair/da_util.h > +++ b/repair/da_util.h > @@ -78,5 +78,6 @@ int > verify_final_da_path( > xfs_mount_t *mp, > da_bt_cursor_t *cursor, > - const int p_level); > + const int p_level, > + int whichfork); > #endif /* _XR_DA_UTIL_H */ > diff --git a/repair/dir2.c b/repair/dir2.c > index 492b3e7..61912d1 100644 > --- a/repair/dir2.c > +++ b/repair/dir2.c > @@ -1179,7 +1179,7 @@ _("bad sibling back pointer for block %u in directory inode %" PRIu64 "\n"), > } else > libxfs_putbuf(bp); > } while (da_bno != 0); > - if (verify_final_da_path(mp, da_cursor, 0)) { > + if (verify_final_da_path(mp, da_cursor, 0, XFS_DATA_FORK)) { > /* > * Verify the final path up (right-hand-side) if still ok. > */ > -- > 1.7.1 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Mon Sep 14 15:11:28 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 8D2C07F37 for ; Mon, 14 Sep 2015 15:11:28 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 7BA9C304048 for ; Mon, 14 Sep 2015 13:11:28 -0700 (PDT) X-ASG-Debug-ID: 1442261485-04cbb005e9fa390001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id TxlJEP1WMTecNyCq for ; Mon, 14 Sep 2015 13:11:25 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 5427263CBCF5 for ; Mon, 14 Sep 2015 15:11:25 -0500 (CDT) Subject: Re: [PATCH 13/13] xfs_repair: Fix up warning strings in da_util.c To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 13/13] xfs_repair: Fix up warning strings in da_util.c References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-14-git-send-email-sandeen@sandeen.net> <20150914200617.GM34083@bfoster.bfoster> From: Eric Sandeen Message-ID: <55F729EB.2090605@sandeen.net> Date: Mon, 14 Sep 2015 15:11:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150914200617.GM34083@bfoster.bfoster> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1442261485 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22538 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/14/15 3:06 PM, Brian Foster wrote: > On Wed, Sep 09, 2015 at 02:34:11PM -0500, Eric Sandeen wrote: >> Switch the warning messages based on which fork has >> encountered the problem. >> >> Signed-off-by: Eric Sandeen >> Signed-off-by: Eric Sandeen >> --- > > I assume this is being reworked based on the discussion with Carlos (and > I'm really not familiar with the localization stuff). That aside, > shouldn't this be ordered at some point before these functions are > called from both directory and attribute contexts so the messages aren't > ever incorrect? Well, tradeoffs I guess. I ordered it to make review easy. If we think message correctness is a bisectability issue, I could rework it so that it's always correct, but it didn't seem like that big a deal to me. > Also, one nit below... > >> repair/attr_repair.c | 2 +- >> repair/da_util.c | 97 +++++++++++++++++++++++++++----------------------- >> repair/da_util.h | 3 +- >> repair/dir2.c | 2 +- >> 4 files changed, 56 insertions(+), 48 deletions(-) >> > ... >> diff --git a/repair/da_util.c b/repair/da_util.c >> index e5d5535..89d41cc 100644 >> --- a/repair/da_util.c >> +++ b/repair/da_util.c > ... >> @@ -361,25 +366,27 @@ verify_final_da_path( >> */ >> if (cursor->level[this_level].hashval >= >> be32_to_cpu(btree[entry].hashval)) { >> - do_warn(_("directory/attribute block hashvalue inconsistency, " >> - "expected > %u / saw %u\n"), >> + do_warn( >> +_("%s block hashvalue inconsistency, expected > %u / saw %u\n"), >> + FORKNAME(whichfork), >> cursor->level[this_level].hashval, >> be32_to_cpu(btree[entry].hashval)); >> bad++; >> } >> if (nodehdr.forw != 0) { >> - do_warn(_("bad directory/attribute forward block pointer, " >> - "expected 0, saw %u\n"), >> - nodehdr.forw); >> + do_warn( >> +_("bad %s forward block pointer, expected 0, saw %u\n"), >> + FORKNAME(whichfork), nodehdr.forw); >> bad++; >> } >> if (bad) { >> - do_warn(_("bad directory block in inode %" PRIu64 "\n"), cursor->ino); >> + do_warn(_("bad %s block in inode %" PRIu64 "\n"), >> + FORKNAME(whichfork), cursor->ino); >> return 1; >> } >> /* >> * keep track of greatest block # -- that gets >> - * us the length of the directory >> + * us the length of the directory/attribute > > Trailing whitespace above. ok :) Thanks, -Eric > Brian > >> */ >> if (cursor->level[this_level].bno > cursor->greatest_bno) >> cursor->greatest_bno = cursor->level[this_level].bno; >> @@ -389,9 +396,9 @@ verify_final_da_path( >> */ >> if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { >> #ifdef XR_DIR_TRACE >> - fprintf(stderr, "bad directory btree pointer, child bno should " >> + fprintf(stderr, "bad %s btree pointer, child bno should " >> "be %d, block bno is %d, hashval is %u\n", >> - be16_to_cpu(btree[entry].before), >> + FORKNAME(whichfork), be16_to_cpu(btree[entry].before), >> cursor->level[p_level].bno, >> cursor->level[p_level].hashval); >> fprintf(stderr, "verify_final_da_path returns 1 (bad) #1a\n"); >> @@ -403,17 +410,17 @@ verify_final_da_path( >> be32_to_cpu(btree[entry].hashval)) { >> if (!no_modify) { >> do_warn( >> -_("correcting bad hashval in non-leaf dir block\n" >> +_("correcting bad hashval in non-leaf %s block\n" >> "\tin (level %d) in inode %" PRIu64 ".\n"), >> - this_level, cursor->ino); >> + FORKNAME(whichfork), this_level, cursor->ino); >> btree[entry].hashval = cpu_to_be32( >> cursor->level[p_level].hashval); >> cursor->level[this_level].dirty++; >> } else { >> do_warn( >> -_("would correct bad hashval in non-leaf dir block\n" >> +_("would correct bad hashval in non-leaf %s block\n" >> "\tin (level %d) in inode %" PRIu64 ".\n"), >> - this_level, cursor->ino); >> + FORKNAME(whichfork), this_level, cursor->ino); >> } >> } >> >> @@ -451,7 +458,7 @@ _("would correct bad hashval in non-leaf dir block\n" >> */ >> cursor->level[this_level].hashval = hashval; >> >> - return verify_final_da_path(mp, cursor, this_level); >> + return verify_final_da_path(mp, cursor, this_level, whichfork); >> } >> >> /* >> @@ -564,8 +571,8 @@ verify_da_path( >> &bmp, &lbmp); >> if (nex == 0) { >> do_warn( >> -_("can't get map info for block %u of directory inode %" PRIu64 "\n"), >> - dabno, cursor->ino); >> +_("can't get map info for %s block %u of inode %" PRIu64 "\n"), >> + FORKNAME(whichfork), dabno, cursor->ino); >> return 1; >> } >> >> @@ -575,8 +582,8 @@ _("can't get map info for block %u of directory inode %" PRIu64 "\n"), >> >> if (!bp) { >> do_warn( >> -_("can't read block %u for directory inode %" PRIu64 "\n"), >> - dabno, cursor->ino); >> +_("can't read %s block %u for inode %" PRIu64 "\n"), >> + FORKNAME(whichfork), dabno, cursor->ino); >> return 1; >> } >> >> @@ -592,28 +599,28 @@ _("can't read block %u for directory inode %" PRIu64 "\n"), >> if (nodehdr.magic != XFS_DA_NODE_MAGIC && >> nodehdr.magic != XFS_DA3_NODE_MAGIC) { >> do_warn( >> -_("bad magic number %x in block %u for directory inode %" PRIu64 "\n"), >> - nodehdr.magic, >> +_("bad magic number %x in %s block %u for inode %" PRIu64 "\n"), >> + nodehdr.magic, FORKNAME(whichfork), >> dabno, cursor->ino); >> bad++; >> } >> if (nodehdr.back != cursor->level[this_level].bno) { >> do_warn( >> -_("bad back pointer in block %u for directory inode %" PRIu64 "\n"), >> - dabno, cursor->ino); >> +_("bad back pointer in %s block %u for inode %" PRIu64 "\n"), >> + FORKNAME(whichfork), dabno, cursor->ino); >> bad++; >> } >> if (nodehdr.count > geo->node_ents) { >> do_warn( >> -_("entry count %d too large in block %u for directory inode %" PRIu64 "\n"), >> - nodehdr.count, >> +_("entry count %d too large in %s block %u for inode %" PRIu64 "\n"), >> + nodehdr.count, FORKNAME(whichfork), >> dabno, cursor->ino); >> bad++; >> } >> if (nodehdr.level != this_level) { >> do_warn( >> -_("bad level %d in block %u for directory inode %" PRIu64 "\n"), >> - nodehdr.level, >> +_("bad level %d in %s block %u for inode %" PRIu64 "\n"), >> + nodehdr.level, FORKNAME(whichfork), >> dabno, cursor->ino); >> bad++; >> } >> @@ -659,9 +666,9 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), >> */ >> if (cursor->level[p_level].bno != be32_to_cpu(btree[entry].before)) { >> #ifdef XR_DIR_TRACE >> - fprintf(stderr, "bad directory btree pointer, child bno " >> + fprintf(stderr, "bad %s btree pointer, child bno " >> "should be %d, block bno is %d, hashval is %u\n", >> - be32_to_cpu(btree[entry].before), >> + FORKNAME(whichfork), be32_to_cpu(btree[entry].before), >> cursor->level[p_level].bno, >> cursor->level[p_level].hashval); >> fprintf(stderr, "verify_da_path returns 1 (bad) #1a\n"); >> @@ -676,17 +683,17 @@ _("bad level %d in block %u for directory inode %" PRIu64 "\n"), >> be32_to_cpu(btree[entry].hashval)) { >> if (!no_modify) { >> do_warn( >> -_("correcting bad hashval in interior dir block\n" >> +_("correcting bad hashval in interior %s block\n" >> "\tin (level %d) in inode %" PRIu64 ".\n"), >> - this_level, cursor->ino); >> + FORKNAME(whichfork), this_level, cursor->ino); >> btree[entry].hashval = cpu_to_be32( >> cursor->level[p_level].hashval); >> cursor->level[this_level].dirty++; >> } else { >> do_warn( >> -_("would correct bad hashval in interior dir block\n" >> +_("would correct bad hashval in interior %s block\n" >> "\tin (level %d) in inode %" PRIu64 ".\n"), >> - this_level, cursor->ino); >> + FORKNAME(whichfork), this_level, cursor->ino); >> } >> } >> /* >> diff --git a/repair/da_util.h b/repair/da_util.h >> index 7971d63..442f9f1 100644 >> --- a/repair/da_util.h >> +++ b/repair/da_util.h >> @@ -78,5 +78,6 @@ int >> verify_final_da_path( >> xfs_mount_t *mp, >> da_bt_cursor_t *cursor, >> - const int p_level); >> + const int p_level, >> + int whichfork); >> #endif /* _XR_DA_UTIL_H */ >> diff --git a/repair/dir2.c b/repair/dir2.c >> index 492b3e7..61912d1 100644 >> --- a/repair/dir2.c >> +++ b/repair/dir2.c >> @@ -1179,7 +1179,7 @@ _("bad sibling back pointer for block %u in directory inode %" PRIu64 "\n"), >> } else >> libxfs_putbuf(bp); >> } while (da_bno != 0); >> - if (verify_final_da_path(mp, da_cursor, 0)) { >> + if (verify_final_da_path(mp, da_cursor, 0, XFS_DATA_FORK)) { >> /* >> * Verify the final path up (right-hand-side) if still ok. >> */ >> -- >> 1.7.1 >> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From zhao.mingyue@h3c.com Mon Sep 14 21:59:25 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id BBBE87F37 for ; Mon, 14 Sep 2015 21:59:25 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 9E96E304048 for ; Mon, 14 Sep 2015 19:59:22 -0700 (PDT) X-ASG-Debug-ID: 1442285956-04cbb005e9105250001-NocioJ Received: from h3cmg01-ex.h3c.com (smtp.h3c.com [60.191.123.56]) by cuda.sgi.com with ESMTP id fzJpTiCqcILMuqUc for ; Mon, 14 Sep 2015 19:59:17 -0700 (PDT) X-Barracuda-Envelope-From: zhao.mingyue@h3c.com X-Barracuda-Apparent-Source-IP: 60.191.123.56 Received: from H3CHUB03-EX.srv.huawei-3com.com (unknown [10.63.20.169]) by h3cmg01-ex.h3c.com with smtp id 4df4_07f6_80393bfa_19f4_444c_8fb0_904abb36f759; Tue, 15 Sep 2015 10:59:15 +0800 Received: from H3CMLB12-EX.srv.huawei-3com.com ([fe80::f091:bd11:f0a9:5cbe]) by H3CHUB03-EX.srv.huawei-3com.com ([fe80::ec6c:67e6:67f8:ce53%15]) with mapi id 14.01.0355.002; Tue, 15 Sep 2015 10:59:08 +0800 From: "zhao.mingyue@h3c.com" To: "xfs@oss.sgi.com" CC: Xudonghai Subject: umount hanging problem Thread-Topic: umount hanging problem X-ASG-Orig-Subj: umount hanging problem Thread-Index: AdDvYnxvTUX278yqSA21efgUzMyWCg== Date: Tue, 15 Sep 2015 02:59:53 +0000 Message-ID: <1CB94550540AE44E9CAAE8CD5AF40BF846CEDB68@H3CMLB12-EX.srv.huawei-3com.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.70.129] Content-Type: multipart/alternative; boundary="_000_1CB94550540AE44E9CAAE8CD5AF40BF846CEDB68H3CMLB12EXsrvhu_" MIME-Version: 1.0 X-Barracuda-Connect: smtp.h3c.com[60.191.123.56] X-Barracuda-Start-Time: 1442285957 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.69 X-Barracuda-Spam-Status: No, SCORE=1.69 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HELO_DYNAMIC_DHCP, HELO_DYNAMIC_DHCP_2, HTML_MESSAGE, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22550 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 HTML_MESSAGE BODY: HTML included in message 1.66 HELO_DYNAMIC_DHCP_2 HELO_DYNAMIC_DHCP_2 --_000_1CB94550540AE44E9CAAE8CD5AF40BF846CEDB68H3CMLB12EXsrvhu_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksZXZlcnlvbmUNCg0KIEkgaGF2ZSBzb21lIHF1ZXN0aW9uIGFib3V0IFhGUyBGSUxFc3lzdGVt o6xjYW4gc29tZW9uZSBoZWxwIG1lIHNvdmxlIG15IHByb2JsZW0go78NCg0KIEkgYnVpbHQgYSBP cmFjbGUgZGF0YWJhc2Ugb24gYSByYmQgYmxvY2sgd2hpY2ggaGFkIGJlZW4gY3JlYXRlZCB4ZnMg ZmlsZXN5c3RlbSCjrHRoZW4gSSByZW1vdmVkIHRoZSByYmQgYmxvY2sgo6x0aGVuIHRoZSBmaWxl IGRpcmVjdG9yeSBvZiB0aGUgb3JhY2xlIHdhcyBicm9rZW4gYW5kIGNvdWxkbqGvdCBiZSB1c2Vk o6xuZXh0o6xJIHJlY292ZXIgdGhlIHJiZCBibG9jaw0KDQphbmQgdW1vdW50IHRoZSBmaWxlIGRp cmVjdG9yeSBvZiB0aGUgb3JhY2xlIKOsd2hhdCBoYXBwZWQgbmV4dCBpcyB0aGUgcXVlc3Rpb24g d2hpY2ggSSB3YXMgY29uZnVzZWQgo6x0aGUgcHJvY2VzcyBvZiB0aGUgdW1vdW50IGlzIGh1bmdp bmcgdGhlcmUgYW5kIGNvdWxkbqGvdCBiZSBraWxsZWSjrGhvdyB0byBzb2x2ZSB0aGUgcHJvYmxl bSCjv6O/DQoNCnRoYW5rc6OhDQoNCg0KDQoNCnBhcnQgb2YgdGhlIGxvZyBpcyBhcyBmb2xsb3dz o7oNCg0KU2VwIDExIDEwOjIyOjI5IGxvY2FsaG9zdCBzeXN0ZW1kOiBTdGFydGVkIEZpbmdlcnBy aW50IEF1dGhlbnRpY2F0aW9uIERhZW1vbi4NClNlcCAxMSAxMDoyMjoyOSBsb2NhbGhvc3QgZnBy aW50ZDogTGF1bmNoaW5nIEZwcmludE9iamVjdA0KU2VwIDExIDEwOjIyOjI5IGxvY2FsaG9zdCBm cHJpbnRkOiAqKiBNZXNzYWdlOiBELUJ1cyBzZXJ2aWNlIGxhdW5jaGVkIHdpdGggbmFtZTogbmV0 LnJlYWN0aXZhdGVkLkZwcmludA0KU2VwIDExIDEwOjIyOjI5IGxvY2FsaG9zdCBmcHJpbnRkOiAq KiBNZXNzYWdlOiBlbnRlcmluZyBtYWluIGxvb3ANClNlcCAxMSAxMDoyMjozOSBsb2NhbGhvc3Qg a2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0KU2Vw IDExIDEwOjIyOjQ3IGxvY2FsaG9zdCBzeXN0ZW1kLWxvZ2luZDogUmVtb3ZlZCBzZXNzaW9uIDEu DQpTZXAgMTEgMTA6MjI6NTkgbG9jYWxob3N0IGZwcmludGQ6ICoqIE1lc3NhZ2U6IE5vIGRldmlj ZXMgaW4gdXNlLCBleGl0DQpTZXAgMTEgMTA6MjM6MDkgbG9jYWxob3N0IGtlcm5lbDogWEZTIChk bS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NClNlcCAxMSAxMDoyMzoxOSBs b2NhbGhvc3Qgc3lzdGVtZC1sb2dpbmQ6IFJlbW92ZWQgc2Vzc2lvbiAxMzYuDQpTZXAgMTEgMTA6 MjM6MzkgbG9jYWxob3N0IGtlcm5lbDogWEZTIChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3Ig NSByZXR1cm5lZC4NClNlcCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qga2VybmVsOiBJTkZPOiB0YXNr IHVtb3VudDoyNzk1MCBibG9ja2VkIGZvciBtb3JlIHRoYW4gMTIwIHNlY29uZHMuDQpTZXAgMTEg MTA6MjM6NDQgbG9jYWxob3N0IGtlcm5lbDogImVjaG8gMCA+IC9wcm9jL3N5cy9rZXJuZWwvaHVu Z190YXNrX3RpbWVvdXRfc2VjcyIgZGlzYWJsZXMgdGhpcyBtZXNzYWdlLg0KU2VwIDExIDEwOjIz OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IHVtb3VudCAgICAgICAgICBEIGZmZmY4ODBlMWZhZjM2ODAg ICAgIDAgMjc5NTAgIDI3Nzc1IDB4MDAwMDAwODQNClNlcCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qg a2VybmVsOiBmZmZmODgwZGQzMjQ3ZDkwIDAwMDAwMDAwMDAwMDAwODYgZmZmZjg4MDZmNzMwZGIw MCBmZmZmODgwZGQzMjQ3ZmQ4DQpTZXAgMTEgMTA6MjM6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZm Zjg4MGRkMzI0N2ZkOCBmZmZmODgwZGQzMjQ3ZmQ4IGZmZmY4ODA2ZjczMGRiMDAgZmZmZjg4MDZl N2NlYWU4MA0KU2VwIDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IGZmZmY4ODA2Y2I4ODhi NDggZmZmZjg4MDZlN2NlYWVjMCBmZmZmODgwNmU3Y2VhZWU4IGZmZmY4ODA2ZTdjZWFlOTANClNl cCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qga2VybmVsOiBDYWxsIFRyYWNlOg0KU2VwIDExIDEwOjIz OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTYwOTI1OT5dIHNjaGVkdWxlKzB4Mjkv MHg3MA0KU2VwIDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmZhMDJmMWFj MT5dIHhmc19haWxfcHVzaF9hbGxfc3luYysweGMxLzB4MTEwIFt4ZnNdDQpTZXAgMTEgMTA6MjM6 NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMDk4MjMwPl0gPyB3YWtlX3VwX2JpdCsw eDMwLzB4MzANClNlcCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmYTAy YTFjNDg+XSB4ZnNfdW5tb3VudGZzKzB4NjgvMHgxNjAgW3hmc10NClNlcCAxMSAxMDoyMzo0NCBs b2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmYTAyYTI0ZWI+XSA/IHhmc19tcnVfY2FjaGVfZGVz dHJveSsweDZiLzB4OTAgW3hmc10NClNlcCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qga2VybmVsOiBb PGZmZmZmZmZmYTAyYTM3MDE+XSB4ZnNfZnNfcHV0X3N1cGVyKzB4MjEvMHg2MCBbeGZzXQ0KU2Vw IDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFjODkzNj5dIGdlbmVy aWNfc2h1dGRvd25fc3VwZXIrMHg1Ni8weGUwDQpTZXAgMTEgMTA6MjM6NDQgbG9jYWxob3N0IGtl cm5lbDogWzxmZmZmZmZmZjgxMWM4YzE3Pl0ga2lsbF9ibG9ja19zdXBlcisweDI3LzB4NzANClNl cCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExYzhmNGQ+XSBkZWFj dGl2YXRlX2xvY2tlZF9zdXBlcisweDNkLzB4NjANClNlcCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qg a2VybmVsOiBbPGZmZmZmZmZmODExYzk1NTY+XSBkZWFjdGl2YXRlX3N1cGVyKzB4NDYvMHg2MA0K U2VwIDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFlNjI2NT5dIG1u dHB1dF9ub19leHBpcmUrMHhjNS8weDEyMA0KU2VwIDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJu ZWw6IFs8ZmZmZmZmZmY4MTFlNzM5Zj5dIFN5U191bW91bnQrMHg5Zi8weDNjMA0KU2VwIDExIDEw OjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTYxM2RhOT5dIHN5c3RlbV9jYWxs X2Zhc3RwYXRoKzB4MTYvMHgxYg0KU2VwIDExIDEwOjIzOjU3IGxvY2FsaG9zdCBzeXN0ZW1kLWxv Z2luZDogUmVtb3ZlZCBzZXNzaW9uIDEzMy4NClNlcCAxMSAxMDoyNDowOSBsb2NhbGhvc3Qga2Vy bmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0KU2VwIDEx IDEwOjI0OjM5IGxvY2FsaG9zdCBrZXJuZWw6IFhGUyAoZG0tMik6IHhmc19sb2dfZm9yY2U6IGVy cm9yIDUgcmV0dXJuZWQuDQpTZXAgMTEgMTA6MjU6MDkgbG9jYWxob3N0IGtlcm5lbDogWEZTIChk bS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NClNlcCAxMSAxMDoyNTozOSBs b2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVy bmVkLg0KU2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IElORk86IHRhc2sgdW1vdW50 OjI3OTUwIGJsb2NrZWQgZm9yIG1vcmUgdGhhbiAxMjAgc2Vjb25kcy4NClNlcCAxMSAxMDoyNTo0 NCBsb2NhbGhvc3Qga2VybmVsOiAiZWNobyAwID4gL3Byb2Mvc3lzL2tlcm5lbC9odW5nX3Rhc2tf dGltZW91dF9zZWNzIiBkaXNhYmxlcyB0aGlzIG1lc3NhZ2UuDQpTZXAgMTEgMTA6MjU6NDQgbG9j YWxob3N0IGtlcm5lbDogdW1vdW50ICAgICAgICAgIEQgZmZmZjg4MGUxZmFmMzY4MCAgICAgMCAy Nzk1MCAgMjc3NzUgMHgwMDAwMDA4NA0KU2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6 IGZmZmY4ODBkZDMyNDdkOTAgMDAwMDAwMDAwMDAwMDA4NiBmZmZmODgwNmY3MzBkYjAwIGZmZmY4 ODBkZDMyNDdmZDgNClNlcCAxMSAxMDoyNTo0NCBsb2NhbGhvc3Qga2VybmVsOiBmZmZmODgwZGQz MjQ3ZmQ4IGZmZmY4ODBkZDMyNDdmZDggZmZmZjg4MDZmNzMwZGIwMCBmZmZmODgwNmU3Y2VhZTgw DQpTZXAgMTEgMTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4MDZjYjg4OGI0OCBmZmZm ODgwNmU3Y2VhZWMwIGZmZmY4ODA2ZTdjZWFlZTggZmZmZjg4MDZlN2NlYWU5MA0KU2VwIDExIDEw OjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IENhbGwgVHJhY2U6DQpTZXAgMTEgMTA6MjU6NDQgbG9j YWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxNjA5MjU5Pl0gc2NoZWR1bGUrMHgyOS8weDcwDQpT ZXAgMTEgMTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZmEwMmYxYWMxPl0geGZz X2FpbF9wdXNoX2FsbF9zeW5jKzB4YzEvMHgxMTAgW3hmc10NClNlcCAxMSAxMDoyNTo0NCBsb2Nh bGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODEwOTgyMzA+XSA/IHdha2VfdXBfYml0KzB4MzAvMHgz MA0KU2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmZhMDJhMWM0OD5d IHhmc191bm1vdW50ZnMrMHg2OC8weDE2MCBbeGZzXQ0KU2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9z dCBrZXJuZWw6IFs8ZmZmZmZmZmZhMDJhMjRlYj5dID8geGZzX21ydV9jYWNoZV9kZXN0cm95KzB4 NmIvMHg5MCBbeGZzXQ0KU2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZm ZmZhMDJhMzcwMT5dIHhmc19mc19wdXRfc3VwZXIrMHgyMS8weDYwIFt4ZnNdDQpTZXAgMTEgMTA6 MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM4OTM2Pl0gZ2VuZXJpY19zaHV0 ZG93bl9zdXBlcisweDU2LzB4ZTANClNlcCAxMSAxMDoyNTo0NCBsb2NhbGhvc3Qga2VybmVsOiBb PGZmZmZmZmZmODExYzhjMTc+XSBraWxsX2Jsb2NrX3N1cGVyKzB4MjcvMHg3MA0KU2VwIDExIDEw OjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFjOGY0ZD5dIGRlYWN0aXZhdGVf bG9ja2VkX3N1cGVyKzB4M2QvMHg2MA0KU2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6 IFs8ZmZmZmZmZmY4MTFjOTU1Nj5dIGRlYWN0aXZhdGVfc3VwZXIrMHg0Ni8weDYwDQpTZXAgMTEg MTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWU2MjY1Pl0gbW50cHV0X25v X2V4cGlyZSsweGM1LzB4MTIwDQpTZXAgMTEgMTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxm ZmZmZmZmZjgxMWU3MzlmPl0gU3lTX3Vtb3VudCsweDlmLzB4M2MwDQpTZXAgMTEgMTA6MjU6NDQg bG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxNjEzZGE5Pl0gc3lzdGVtX2NhbGxfZmFzdHBh dGgrMHgxNi8weDFiDQpTZXAgMTEgMTA6MjY6MDUgbG9jYWxob3N0IHN5c3RlbWQtbG9naW5kOiBO ZXcgc2Vzc2lvbiAxMzggb2YgdXNlciByb290Lg0KU2VwIDExIDEwOjI2OjA1IGxvY2FsaG9zdCBz eXN0ZW1kOiBTdGFydGluZyBTZXNzaW9uIDEzOCBvZiB1c2VyIHJvb3QuDQpTZXAgMTEgMTA6MjY6 MDUgbG9jYWxob3N0IHN5c3RlbWQ6IFN0YXJ0ZWQgU2Vzc2lvbiAxMzggb2YgdXNlciByb290Lg0K U2VwIDExIDEwOjI2OjA5IGxvY2FsaG9zdCBrZXJuZWw6IFhGUyAoZG0tMik6IHhmc19sb2dfZm9y Y2U6IGVycm9yIDUgcmV0dXJuZWQuDQpTZXAgMTEgMTA6MjY6MjkgbG9jYWxob3N0IHN5c3RlbWQt bG9naW5kOiBOZXcgc2Vzc2lvbiAxMzkgb2YgdXNlciByb290Lg0KU2VwIDExIDEwOjI2OjI5IGxv Y2FsaG9zdCBzeXN0ZW1kOiBTdGFydGluZyBTZXNzaW9uIDEzOSBvZiB1c2VyIHJvb3QuDQpTZXAg MTEgMTA6MjY6MjkgbG9jYWxob3N0IHN5c3RlbWQ6IFN0YXJ0ZWQgU2Vzc2lvbiAxMzkgb2YgdXNl ciByb290Lg0KU2VwIDExIDEwOjI2OjMyIGxvY2FsaG9zdCBzeXN0ZW1kLWxvZ2luZDogUmVtb3Zl ZCBzZXNzaW9uIDEzOS4NClNlcCAxMSAxMDoyNjozOSBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRt LTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0KU2VwIDExIDEwOjI3OjA5IGxv Y2FsaG9zdCBrZXJuZWw6IFhGUyAoZG0tMik6IHhmc19sb2dfZm9yY2U6IGVycm9yIDUgcmV0dXJu ZWQuDQpTZXAgMTEgMTA6Mjc6MzggbG9jYWxob3N0IGdvYVsyODc3NV06IGdvYS1kYWVtb24gdmVy c2lvbiAzLjguNSBzdGFydGluZyBbbWFpbi5jOjExMywgbWFpbigpXQ0KU2VwIDExIDEwOjI3OjM4 IGxvY2FsaG9zdCBnb2FbMjg3ODJdOiBHb2FLZXJiZXJvc0lkZW50aXR5TWFuYWdlcjogVXNpbmcg cG9sbGluZyBmb3IgY2hhbmdlIG5vdGlmaWNhdGlvbiBmb3IgY3JlZGVudGlhbCBjYWNoZSB0eXBl ICdLRVlSSU5HJyBbZ29ha2VyYmVyb3NpZGVudGl0eW1hbmFnZXIuYzoxMzk0LCBtb25pdG9yX2Ny ZWRlbnRpYWxzX2NhY2hlKCldDQpTZXAgMTEgMTA6Mjc6NDAgbG9jYWxob3N0IGtlcm5lbDogWEZT IChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NClNlcCAxMSAxMDoyNzo0 NCBsb2NhbGhvc3Qga2VybmVsOiBJTkZPOiB0YXNrIHVtb3VudDoyNzk1MCBibG9ja2VkIGZvciBt b3JlIHRoYW4gMTIwIHNlY29uZHMuDQpTZXAgMTEgMTA6Mjc6NDQgbG9jYWxob3N0IGtlcm5lbDog ImVjaG8gMCA+IC9wcm9jL3N5cy9rZXJuZWwvaHVuZ190YXNrX3RpbWVvdXRfc2VjcyIgZGlzYWJs ZXMgdGhpcyBtZXNzYWdlLg0KU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IHVtb3Vu dCAgICAgICAgICBEIGZmZmY4ODBlMWZhZjM2ODAgICAgIDAgMjc5NTAgIDI3Nzc1IDB4MDAwMDAw ODQNClNlcCAxMSAxMDoyNzo0NCBsb2NhbGhvc3Qga2VybmVsOiBmZmZmODgwZGQzMjQ3ZDkwIDAw MDAwMDAwMDAwMDAwODYgZmZmZjg4MDZmNzMwZGIwMCBmZmZmODgwZGQzMjQ3ZmQ4DQpTZXAgMTEg MTA6Mjc6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4MGRkMzI0N2ZkOCBmZmZmODgwZGQzMjQ3 ZmQ4IGZmZmY4ODA2ZjczMGRiMDAgZmZmZjg4MDZlN2NlYWU4MA0KU2VwIDExIDEwOjI3OjQ0IGxv Y2FsaG9zdCBrZXJuZWw6IGZmZmY4ODA2Y2I4ODhiNDggZmZmZjg4MDZlN2NlYWVjMCBmZmZmODgw NmU3Y2VhZWU4IGZmZmY4ODA2ZTdjZWFlOTANClNlcCAxMSAxMDoyNzo0NCBsb2NhbGhvc3Qga2Vy bmVsOiBDYWxsIFRyYWNlOg0KU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZm ZmZmZmY4MTYwOTI1OT5dIHNjaGVkdWxlKzB4MjkvMHg3MA0KU2VwIDExIDEwOjI3OjQ0IGxvY2Fs aG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmZhMDJmMWFjMT5dIHhmc19haWxfcHVzaF9hbGxfc3luYysw eGMxLzB4MTEwIFt4ZnNdDQpTZXAgMTEgMTA6Mjc6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZm ZmZmZjgxMDk4MjMwPl0gPyB3YWtlX3VwX2JpdCsweDMwLzB4MzANClNlcCAxMSAxMDoyNzo0NCBs b2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmYTAyYTFjNDg+XSB4ZnNfdW5tb3VudGZzKzB4Njgv MHgxNjAgW3hmc10NClNlcCAxMSAxMDoyNzo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZm YTAyYTI0ZWI+XSA/IHhmc19tcnVfY2FjaGVfZGVzdHJveSsweDZiLzB4OTAgW3hmc10NClNlcCAx MSAxMDoyNzo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmYTAyYTM3MDE+XSB4ZnNfZnNf cHV0X3N1cGVyKzB4MjEvMHg2MCBbeGZzXQ0KU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJu ZWw6IFs8ZmZmZmZmZmY4MTFjODkzNj5dIGdlbmVyaWNfc2h1dGRvd25fc3VwZXIrMHg1Ni8weGUw DQpTZXAgMTEgMTA6Mjc6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM4YzE3Pl0g a2lsbF9ibG9ja19zdXBlcisweDI3LzB4NzANClNlcCAxMSAxMDoyNzo0NCBsb2NhbGhvc3Qga2Vy bmVsOiBbPGZmZmZmZmZmODExYzhmNGQ+XSBkZWFjdGl2YXRlX2xvY2tlZF9zdXBlcisweDNkLzB4 NjANClNlcCAxMSAxMDoyNzo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExYzk1NTY+ XSBkZWFjdGl2YXRlX3N1cGVyKzB4NDYvMHg2MA0KU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBr ZXJuZWw6IFs8ZmZmZmZmZmY4MTFlNjI2NT5dIG1udHB1dF9ub19leHBpcmUrMHhjNS8weDEyMA0K U2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFlNzM5Zj5dIFN5 U191bW91bnQrMHg5Zi8weDNjMA0KU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8 ZmZmZmZmZmY4MTYxM2RhOT5dIHN5c3RlbV9jYWxsX2Zhc3RwYXRoKzB4MTYvMHgxYg0KU2VwIDEx IDEwOjI4OjEwIGxvY2FsaG9zdCBrZXJuZWw6IFhGUyAoZG0tMik6IHhmc19sb2dfZm9yY2U6IGVy cm9yIDUgcmV0dXJuZWQuDQpTZXAgMTEgMTA6Mjg6NDAgbG9jYWxob3N0IGtlcm5lbDogWEZTIChk bS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NClNlcCAxMSAxMDoyOToxMCBs b2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVy bmVkLg0KU2VwIDExIDEwOjI5OjQwIGxvY2FsaG9zdCBrZXJuZWw6IFhGUyAoZG0tMik6IHhmc19s b2dfZm9yY2U6IGVycm9yIDUgcmV0dXJuZWQuDQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtl cm5lbDogSU5GTzogdGFzayB1bW91bnQ6Mjc5NTAgYmxvY2tlZCBmb3IgbW9yZSB0aGFuIDEyMCBz ZWNvbmRzLg0KU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6ICJlY2hvIDAgPiAvcHJv Yy9zeXMva2VybmVsL2h1bmdfdGFza190aW1lb3V0X3NlY3MiIGRpc2FibGVzIHRoaXMgbWVzc2Fn ZS4NClNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiB1bW91bnQgICAgICAgICAgRCBm ZmZmODgwZTFmYWYzNjgwICAgICAwIDI3OTUwICAyNzc3NSAweDAwMDAwMDg0DQpTZXAgMTEgMTA6 Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4MGRkMzI0N2Q5MCAwMDAwMDAwMDAwMDAwMDg2 IGZmZmY4ODA2ZjczMGRiMDAgZmZmZjg4MGRkMzI0N2ZkOA0KU2VwIDExIDEwOjI5OjQ0IGxvY2Fs aG9zdCBrZXJuZWw6IGZmZmY4ODBkZDMyNDdmZDggZmZmZjg4MGRkMzI0N2ZkOCBmZmZmODgwNmY3 MzBkYjAwIGZmZmY4ODA2ZTdjZWFlODANClNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVs OiBmZmZmODgwNmNiODg4YjQ4IGZmZmY4ODA2ZTdjZWFlYzAgZmZmZjg4MDZlN2NlYWVlOCBmZmZm ODgwNmU3Y2VhZTkwDQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogQ2FsbCBUcmFj ZToNClNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODE2MDkyNTk+ XSBzY2hlZHVsZSsweDI5LzB4NzANClNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBb PGZmZmZmZmZmYTAyZjFhYzE+XSB4ZnNfYWlsX3B1c2hfYWxsX3N5bmMrMHhjMS8weDExMCBbeGZz XQ0KU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTA5ODIzMD5d ID8gd2FrZV91cF9iaXQrMHgzMC8weDMwDQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5l bDogWzxmZmZmZmZmZmEwMmExYzQ4Pl0geGZzX3VubW91bnRmcysweDY4LzB4MTYwIFt4ZnNdDQpT ZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZmEwMmEyNGViPl0gPyB4 ZnNfbXJ1X2NhY2hlX2Rlc3Ryb3krMHg2Yi8weDkwIFt4ZnNdDQpTZXAgMTEgMTA6Mjk6NDQgbG9j YWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZmEwMmEzNzAxPl0geGZzX2ZzX3B1dF9zdXBlcisweDIx LzB4NjAgW3hmc10NClNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZm ODExYzg5MzY+XSBnZW5lcmljX3NodXRkb3duX3N1cGVyKzB4NTYvMHhlMA0KU2VwIDExIDEwOjI5 OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFjOGMxNz5dIGtpbGxfYmxvY2tfc3Vw ZXIrMHgyNy8weDcwDQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZm ZjgxMWM4ZjRkPl0gZGVhY3RpdmF0ZV9sb2NrZWRfc3VwZXIrMHgzZC8weDYwDQpTZXAgMTEgMTA6 Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM5NTU2Pl0gZGVhY3RpdmF0ZV9z dXBlcisweDQ2LzB4NjANClNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZm ZmZmODExZTYyNjU+XSBtbnRwdXRfbm9fZXhwaXJlKzB4YzUvMHgxMjANClNlcCAxMSAxMDoyOTo0 NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExZTczOWY+XSBTeVNfdW1vdW50KzB4OWYv MHgzYzANClNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODE2MTNk YTk+XSBzeXN0ZW1fY2FsbF9mYXN0cGF0aCsweDE2LzB4MWINClNlcCAxMSAxMDoyOTo0NCBsb2Nh bGhvc3Qga2VybmVsOiBJTkZPOiB0YXNrIG1vdW50OjI4NjY5IGJsb2NrZWQgZm9yIG1vcmUgdGhh biAxMjAgc2Vjb25kcy4NClNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiAiZWNobyAw ID4gL3Byb2Mvc3lzL2tlcm5lbC9odW5nX3Rhc2tfdGltZW91dF9zZWNzIiBkaXNhYmxlcyB0aGlz IG1lc3NhZ2UuDQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogbW91bnQgICAgICAg ICAgIEQgZmZmZjg4MDcwM2NmMzY4MCAgICAgMCAyODY2OSAgMjc5OTAgMHgwMDAwMDA4NA0KU2Vw IDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IGZmZmY4ODA2Y2E1OWZjNDggMDAwMDAwMDAw MDAwMDA4MiBmZmZmODgwZGVhODc3MWMwIGZmZmY4ODA2Y2E1OWZmZDgNClNlcCAxMSAxMDoyOTo0 NCBsb2NhbGhvc3Qga2VybmVsOiBmZmZmODgwNmNhNTlmZmQ4IGZmZmY4ODA2Y2E1OWZmZDggZmZm Zjg4MGRlYTg3NzFjMCBmZmZmODgwZGVhODc3MWMwDQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0 IGtlcm5lbDogZmZmZjg4MGRlYzgxZjA2OCBmZmZmODgwZGVjODFmMDcwIGZmZmZmZmZmMDAwMDAw MDAgZmZmZjg4MGRlYzgxZjA3OA0KU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IENh bGwgVHJhY2U6DQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgx NjA5MjU5Pl0gc2NoZWR1bGUrMHgyOS8weDcwDQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtl cm5lbDogWzxmZmZmZmZmZjgxNjBhYjM1Pl0gcndzZW1fZG93bl93cml0ZV9mYWlsZWQrMHgxMTUv MHgyMjANClNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODEyMDE0 ODE+XSA/IF9fYmxrZGV2X2dldCsweDIyMS8weDRkMA0KU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9z dCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFjODgzMD5dID8gc2V0X2JkZXZfc3VwZXIrMHg0MC8weDQw DQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMmUyOWEzPl0g Y2FsbF9yd3NlbV9kb3duX3dyaXRlX2ZhaWxlZCsweDEzLzB4MjANClNlcCAxMSAxMDoyOTo0NCBs b2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODE2MDg2NGQ+XSA/IGRvd25fd3JpdGUrMHgyZC8w eDMwDQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM5MTdl Pl0gZ3JhYl9zdXBlcisweDJlLzB4YTANClNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVs OiBbPGZmZmZmZmZmODExYzk4MTA+XSBzZ2V0KzB4MmEwLzB4M2QwDQpTZXAgMTEgMTA6Mjk6NDQg bG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM4N2YwPl0gPyBuc190ZXN0X3N1cGVyKzB4 MjAvMHgyMA0KU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFj OWI5Mj5dIG1vdW50X2JkZXYrMHhlMi8weDFmMA0KU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBr ZXJuZWw6IFs8ZmZmZmZmZmZhMDJhNDU4MD5dID8geGZzX3BhcnNlYXJncysweGJmMC8weGJmMCBb eGZzXQ0KU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTJkNjIz MD5dID8gaWRhX2dldF9uZXdfYWJvdmUrMHgyMzAvMHgyYTANClNlcCAxMSAxMDoyOTo0NCBsb2Nh bGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmYTAyYTI3NzU+XSB4ZnNfZnNfbW91bnQrMHgxNS8weDIw IFt4ZnNdDQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWNh NTk5Pl0gbW91bnRfZnMrMHgzOS8weDFiMA0KU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJu ZWw6IFs8ZmZmZmZmZmY4MTE3ODQyMD5dID8gX19hbGxvY19wZXJjcHUrMHgxMC8weDIwDQpTZXAg MTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWU1YTZmPl0gdmZzX2tl cm5fbW91bnQrMHg1Zi8weGYwDQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxm ZmZmZmZmZjgxMWU3ZmJlPl0gZG9fbW91bnQrMHgyNGUvMHhhNDANClNlcCAxMSAxMDoyOTo0NCBs b2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExNzMxN2I+XSA/IHN0cm5kdXBfdXNlcisweDRi LzB4ZjANClNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExZTg4 NDY+XSBTeVNfbW91bnQrMHg5Ni8weGYwDQpTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5l bDogWzxmZmZmZmZmZjgxNjEzZGE5Pl0gc3lzdGVtX2NhbGxfZmFzdHBhdGgrMHgxNi8weDFiDQpT ZXAgMTEgMTA6MzA6MDEgbG9jYWxob3N0IHN5c3RlbWQ6IFN0YXJ0aW5nIFNlc3Npb24gMTQwIG9m IHVzZXIgcm9vdC4NClNlcCAxMSAxMDozMDowMSBsb2NhbGhvc3Qgc3lzdGVtZDogU3RhcnRlZCBT ZXNzaW9uIDE0MCBvZiB1c2VyIHJvb3QuDQpTZXAgMTEgMTA6MzA6MTAgbG9jYWxob3N0IGtlcm5l bDogWEZTIChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NClNlcCAxMSAx MDozMDo0MCBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJv ciA1IHJldHVybmVkLg0KU2VwIDExIDEwOjMxOjEwIGxvY2FsaG9zdCBrZXJuZWw6IFhGUyAoZG0t Mik6IHhmc19sb2dfZm9yY2U6IGVycm9yIDUgcmV0dXJuZWQuDQpTZXAgMTEgMTA6MzE6NDAgbG9j YWxob3N0IGtlcm5lbDogWEZTIChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5l ZC4NClNlcCAxMSAxMDozMTo0NCBsb2NhbGhvc3Qga2VybmVsOiBJTkZPOiB0YXNrIHVtb3VudDoy Nzk1MCBibG9ja2VkIGZvciBtb3JlIHRoYW4gMTIwIHNlY29uZHMuDQpTZXAgMTEgMTA6MzE6NDQg bG9jYWxob3N0IGtlcm5lbDogImVjaG8gMCA+IC9wcm9jL3N5cy9rZXJuZWwvaHVuZ190YXNrX3Rp bWVvdXRfc2VjcyIgZGlzYWJsZXMgdGhpcyBtZXNzYWdlLg0KU2VwIDExIDEwOjMxOjQ0IGxvY2Fs aG9zdCBrZXJuZWw6IHVtb3VudCAgICAgICAgICBEIGZmZmY4ODBlMWZhZjM2ODAgICAgIDAgMjc5 NTAgIDI3Nzc1IDB4MDAwMDAwODQNClNlcCAxMSAxMDozMTo0NCBsb2NhbGhvc3Qga2VybmVsOiBm ZmZmODgwZGQzMjQ3ZDkwIDAwMDAwMDAwMDAwMDAwODYgZmZmZjg4MDZmNzMwZGIwMCBmZmZmODgw ZGQzMjQ3ZmQ4DQpTZXAgMTEgMTA6MzE6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4MGRkMzI0 N2ZkOCBmZmZmODgwZGQzMjQ3ZmQ4IGZmZmY4ODA2ZjczMGRiMDAgZmZmZjg4MDZlN2NlYWU4MA0K U2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IGZmZmY4ODA2Y2I4ODhiNDggZmZmZjg4 MDZlN2NlYWVjMCBmZmZmODgwNmU3Y2VhZWU4IGZmZmY4ODA2ZTdjZWFlOTANClNlcCAxMSAxMDoz MTo0NCBsb2NhbGhvc3Qga2VybmVsOiBDYWxsIFRyYWNlOg0KU2VwIDExIDEwOjMxOjQ0IGxvY2Fs aG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTYwOTI1OT5dIHNjaGVkdWxlKzB4MjkvMHg3MA0KU2Vw IDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmZhMDJmMWFjMT5dIHhmc19h aWxfcHVzaF9hbGxfc3luYysweGMxLzB4MTEwIFt4ZnNdDQpTZXAgMTEgMTA6MzE6NDQgbG9jYWxo b3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMDk4MjMwPl0gPyB3YWtlX3VwX2JpdCsweDMwLzB4MzAN ClNlcCAxMSAxMDozMTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmYTAyYTFjNDg+XSB4 ZnNfdW5tb3VudGZzKzB4NjgvMHgxNjAgW3hmc10NClNlcCAxMSAxMDozMTo0NCBsb2NhbGhvc3Qg a2VybmVsOiBbPGZmZmZmZmZmYTAyYTI0ZWI+XSA/IHhmc19tcnVfY2FjaGVfZGVzdHJveSsweDZi LzB4OTAgW3hmc10NClNlcCAxMSAxMDozMTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZm YTAyYTM3MDE+XSB4ZnNfZnNfcHV0X3N1cGVyKzB4MjEvMHg2MCBbeGZzXQ0KU2VwIDExIDEwOjMx OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFjODkzNj5dIGdlbmVyaWNfc2h1dGRv d25fc3VwZXIrMHg1Ni8weGUwDQpTZXAgMTEgMTA6MzE6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxm ZmZmZmZmZjgxMWM4YzE3Pl0ga2lsbF9ibG9ja19zdXBlcisweDI3LzB4NzANClNlcCAxMSAxMDoz MTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExYzhmNGQ+XSBkZWFjdGl2YXRlX2xv Y2tlZF9zdXBlcisweDNkLzB4NjANClNlcCAxMSAxMDozMTo0NCBsb2NhbGhvc3Qga2VybmVsOiBb PGZmZmZmZmZmODExYzk1NTY+XSBkZWFjdGl2YXRlX3N1cGVyKzB4NDYvMHg2MA0KU2VwIDExIDEw OjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFlNjI2NT5dIG1udHB1dF9ub19l eHBpcmUrMHhjNS8weDEyMA0KU2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZm ZmZmZmY4MTFlNzM5Zj5dIFN5U191bW91bnQrMHg5Zi8weDNjMA0KU2VwIDExIDEwOjMxOjQ0IGxv Y2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTYxM2RhOT5dIHN5c3RlbV9jYWxsX2Zhc3RwYXRo KzB4MTYvMHgxYg0KU2VwIDExIDEwOjMyOjEwIGxvY2FsaG9zdCBrZXJuZWw6IFhGUyAoZG0tMik6 IHhmc19sb2dfZm9yY2U6IGVycm9yIDUgcmV0dXJuZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQqx vtPKvP68sMbkuL28/rqs09C6vNbdu6rI/c2o0MW8vMr109DP3rmry761xLGjw9zQxc+io6y99s/e 09q3osvNuPjJz8PmtdjWt9bQwdCz9g0KtcS49sjLu/LIutfpoaO9+9a5yM66zsbky/vIy9LUyM66 ztDOyr3KudPDo6iw/MCotauyu8/e09rIq7K/u/Kyv7fWtdjQucK2oaK4tNbGoaINCrvyyaK3oqOp sb7Tyrz+1tC1xNDFz6Kho8jnufvE+rTtytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+zajW qreivP7Iy7Kiyb6z/bG+DQrTyrz+o6ENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMg Y29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIM0MsIHdoaWNoIGlzDQppbnRl bmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3Rl ZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4g YW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwN CmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBv dGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlv dSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIN CmJ5IHBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQo= --_000_1CB94550540AE44E9CAAE8CD5AF40BF846CEDB68H3CMLB12EXsrvhu_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi= ,everyone

 

 I have some question abou= t XFS FILEsystem=A3=ACcan someone help me sovle my problem =A3=BF

 

 I built a Oracle database= on a rbd block which had been created xfs filesystem =A3=ACthen I removed the rbd block =A3=ACthen the file directory of the oracle was broken and couldn=A1=AFt b= e used=A3=ACnext=A3=ACI recover the rbd block

 

and umount the file directory o= f the oracle =A3=ACwhat happed next is the question which I was confused =A3=ACthe process of the umount is hunging there and couldn=A1=AFt be kill= ed=A3=AChow to solve the problem =A3=BF=A3=BF

 

thanks=A3=A1

 

 

 

 

part of the log is as follow= s=A3=BA

 

Sep 11 10:22:29 localhost syste= md: Started Fingerprint Authentication Daemon.

Sep 11 10:22:29 localhost fprin= td: Launching FprintObject

Sep 11 10:22:29 localhost fprin= td: ** Message: D-Bus service launched with name: net.reactivated.Fprint

Sep 11 10:22:29 localhost fprin= td: ** Message: entering main loop

Sep 11 10:22:39 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:22:47 localhost syste= md-logind: Removed session 1.

Sep 11 10:22:59 localhost fprin= td: ** Message: No devices in use, exit

Sep 11 10:23:09 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:23:19 localhost syste= md-logind: Removed session 136.

Sep 11 10:23:39 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:23:44 localhost kerne= l: INFO: task umount:27950 blocked for more than 120 seconds.

Sep 11 10:23:44 localhost kerne= l: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables= this message.

Sep 11 10:23:44 localhost kerne= l: umount          D ffff880e1= faf3680     0 27950  27775 0x00000084

Sep 11 10:23:44 localhost kerne= l: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8

Sep 11 10:23:44 localhost kerne= l: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80

Sep 11 10:23:44 localhost kerne= l: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90

Sep 11 10:23:44 localhost kerne= l: Call Trace:

Sep 11 10:23:44 localhost kerne= l: [<ffffffff81609259>] schedule+0x29/0x70

Sep 11 10:23:44 localhost kerne= l: [<ffffffffa02f1ac1>] xfs_ail_push_all_sync+0xc1/0x110 [xfs]

Sep 11 10:23:44 localhost kerne= l: [<ffffffff81098230>] ? wake_up_bit+0x30/0x30

Sep 11 10:23:44 localhost kerne= l: [<ffffffffa02a1c48>] xfs_unmountfs+0x68/0x160 [xfs]

Sep 11 10:23:44 localhost kerne= l: [<ffffffffa02a24eb>] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs]

Sep 11 10:23:44 localhost kerne= l: [<ffffffffa02a3701>] xfs_fs_put_super+0x21/0x60 [xfs]

Sep 11 10:23:44 localhost kerne= l: [<ffffffff811c8936>] generic_shutdown_super+0x56/0xe0

Sep 11 10:23:44 localhost kerne= l: [<ffffffff811c8c17>] kill_block_super+0x27/0x70

Sep 11 10:23:44 localhost kerne= l: [<ffffffff811c8f4d>] deactivate_locked_super+0x3d/0x60<= /p>

Sep 11 10:23:44 localhost kerne= l: [<ffffffff811c9556>] deactivate_super+0x46/0x60

Sep 11 10:23:44 localhost kerne= l: [<ffffffff811e6265>] mntput_no_expire+0xc5/0x120

Sep 11 10:23:44 localhost kerne= l: [<ffffffff811e739f>] SyS_umount+0x9f/0x3c0

Sep 11 10:23:44 localhost kerne= l: [<ffffffff81613da9>] system_call_fastpath+0x16/0x1b

Sep 11 10:23:57 localhost syste= md-logind: Removed session 133.

Sep 11 10:24:09 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:24:39 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:25:09 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:25:39 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:25:44 localhost kerne= l: INFO: task umount:27950 blocked for more than 120 seconds.

Sep 11 10:25:44 localhost kerne= l: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables= this message.

Sep 11 10:25:44 localhost kerne= l: umount          D ffff880e1= faf3680     0 27950  27775 0x00000084

Sep 11 10:25:44 localhost kerne= l: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8

Sep 11 10:25:44 localhost kerne= l: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80

Sep 11 10:25:44 localhost kerne= l: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90

Sep 11 10:25:44 localhost kerne= l: Call Trace:

Sep 11 10:25:44 localhost kerne= l: [<ffffffff81609259>] schedule+0x29/0x70

Sep 11 10:25:44 localhost kerne= l: [<ffffffffa02f1ac1>] xfs_ail_push_all_sync+0xc1/0x110 [xfs]

Sep 11 10:25:44 localhost kerne= l: [<ffffffff81098230>] ? wake_up_bit+0x30/0x30

Sep 11 10:25:44 localhost kerne= l: [<ffffffffa02a1c48>] xfs_unmountfs+0x68/0x160 [xfs]

Sep 11 10:25:44 localhost kerne= l: [<ffffffffa02a24eb>] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs]

Sep 11 10:25:44 localhost kerne= l: [<ffffffffa02a3701>] xfs_fs_put_super+0x21/0x60 [xfs]

Sep 11 10:25:44 localhost kerne= l: [<ffffffff811c8936>] generic_shutdown_super+0x56/0xe0

Sep 11 10:25:44 localhost kerne= l: [<ffffffff811c8c17>] kill_block_super+0x27/0x70

Sep 11 10:25:44 localhost kerne= l: [<ffffffff811c8f4d>] deactivate_locked_super+0x3d/0x60<= /p>

Sep 11 10:25:44 localhost kerne= l: [<ffffffff811c9556>] deactivate_super+0x46/0x60

Sep 11 10:25:44 localhost kerne= l: [<ffffffff811e6265>] mntput_no_expire+0xc5/0x120

Sep 11 10:25:44 localhost kerne= l: [<ffffffff811e739f>] SyS_umount+0x9f/0x3c0

Sep 11 10:25:44 localhost kerne= l: [<ffffffff81613da9>] system_call_fastpath+0x16/0x1b

Sep 11 10:26:05 localhost syste= md-logind: New session 138 of user root.

Sep 11 10:26:05 localhost syste= md: Starting Session 138 of user root.

Sep 11 10:26:05 localhost syste= md: Started Session 138 of user root.

Sep 11 10:26:09 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:26:29 localhost syste= md-logind: New session 139 of user root.

Sep 11 10:26:29 localhost syste= md: Starting Session 139 of user root.

Sep 11 10:26:29 localhost syste= md: Started Session 139 of user root.

Sep 11 10:26:32 localhost syste= md-logind: Removed session 139.

Sep 11 10:26:39 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:27:09 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:27:38 localhost goa[2= 8775]: goa-daemon version 3.8.5 starting [main.c:113, main()]

Sep 11 10:27:38 localhost goa[2= 8782]: GoaKerberosIdentityManager: Using polling for change notification fo= r credential cache type 'KEYRING' [goakerberosidentitymanager.c:1394, monit= or_credentials_cache()]

Sep 11 10:27:40 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:27:44 localhost kerne= l: INFO: task umount:27950 blocked for more than 120 seconds.

Sep 11 10:27:44 localhost kerne= l: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables= this message.

Sep 11 10:27:44 localhost kerne= l: umount          D ffff880e1= faf3680     0 27950  27775 0x00000084

Sep 11 10:27:44 localhost kerne= l: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8

Sep 11 10:27:44 localhost kerne= l: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80

Sep 11 10:27:44 localhost kerne= l: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90

Sep 11 10:27:44 localhost kerne= l: Call Trace:

Sep 11 10:27:44 localhost kerne= l: [<ffffffff81609259>] schedule+0x29/0x70

Sep 11 10:27:44 localhost kerne= l: [<ffffffffa02f1ac1>] xfs_ail_push_all_sync+0xc1/0x110 [xfs]

Sep 11 10:27:44 localhost kerne= l: [<ffffffff81098230>] ? wake_up_bit+0x30/0x30

Sep 11 10:27:44 localhost kerne= l: [<ffffffffa02a1c48>] xfs_unmountfs+0x68/0x160 [xfs]

Sep 11 10:27:44 localhost kerne= l: [<ffffffffa02a24eb>] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs]

Sep 11 10:27:44 localhost kerne= l: [<ffffffffa02a3701>] xfs_fs_put_super+0x21/0x60 [xfs]

Sep 11 10:27:44 localhost kerne= l: [<ffffffff811c8936>] generic_shutdown_super+0x56/0xe0

Sep 11 10:27:44 localhost kerne= l: [<ffffffff811c8c17>] kill_block_super+0x27/0x70

Sep 11 10:27:44 localhost kerne= l: [<ffffffff811c8f4d>] deactivate_locked_super+0x3d/0x60<= /p>

Sep 11 10:27:44 localhost kerne= l: [<ffffffff811c9556>] deactivate_super+0x46/0x60

Sep 11 10:27:44 localhost kerne= l: [<ffffffff811e6265>] mntput_no_expire+0xc5/0x120

Sep 11 10:27:44 localhost kerne= l: [<ffffffff811e739f>] SyS_umount+0x9f/0x3c0

Sep 11 10:27:44 localhost kerne= l: [<ffffffff81613da9>] system_call_fastpath+0x16/0x1b

Sep 11 10:28:10 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:28:40 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:29:10 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:29:40 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:29:44 localhost kerne= l: INFO: task umount:27950 blocked for more than 120 seconds.

Sep 11 10:29:44 localhost kerne= l: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables= this message.

Sep 11 10:29:44 localhost kerne= l: umount          D ffff880e1= faf3680     0 27950  27775 0x00000084

Sep 11 10:29:44 localhost kerne= l: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8

Sep 11 10:29:44 localhost kerne= l: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80

Sep 11 10:29:44 localhost kerne= l: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90

Sep 11 10:29:44 localhost kerne= l: Call Trace:

Sep 11 10:29:44 localhost kerne= l: [<ffffffff81609259>] schedule+0x29/0x70

Sep 11 10:29:44 localhost kerne= l: [<ffffffffa02f1ac1>] xfs_ail_push_all_sync+0xc1/0x110 [xfs]

Sep 11 10:29:44 localhost kerne= l: [<ffffffff81098230>] ? wake_up_bit+0x30/0x30

Sep 11 10:29:44 localhost kerne= l: [<ffffffffa02a1c48>] xfs_unmountfs+0x68/0x160 [xfs]

Sep 11 10:29:44 localhost kerne= l: [<ffffffffa02a24eb>] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs]

Sep 11 10:29:44 localhost kerne= l: [<ffffffffa02a3701>] xfs_fs_put_super+0x21/0x60 [xfs]

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811c8936>] generic_shutdown_super+0x56/0xe0

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811c8c17>] kill_block_super+0x27/0x70

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811c8f4d>] deactivate_locked_super+0x3d/0x60<= /p>

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811c9556>] deactivate_super+0x46/0x60

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811e6265>] mntput_no_expire+0xc5/0x120

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811e739f>] SyS_umount+0x9f/0x3c0

Sep 11 10:29:44 localhost kerne= l: [<ffffffff81613da9>] system_call_fastpath+0x16/0x1b

Sep 11 10:29:44 localhost kerne= l: INFO: task mount:28669 blocked for more than 120 seconds.

Sep 11 10:29:44 localhost kerne= l: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables= this message.

Sep 11 10:29:44 localhost kerne= l: mount           D ffff= 880703cf3680     0 28669  27990 0x00000084<= /p>

Sep 11 10:29:44 localhost kerne= l: ffff8806ca59fc48 0000000000000082 ffff880dea8771c0 ffff8806ca59ffd8

Sep 11 10:29:44 localhost kerne= l: ffff8806ca59ffd8 ffff8806ca59ffd8 ffff880dea8771c0 ffff880dea8771c0

Sep 11 10:29:44 localhost kerne= l: ffff880dec81f068 ffff880dec81f070 ffffffff00000000 ffff880dec81f078

Sep 11 10:29:44 localhost kerne= l: Call Trace:

Sep 11 10:29:44 localhost kerne= l: [<ffffffff81609259>] schedule+0x29/0x70

Sep 11 10:29:44 localhost kerne= l: [<ffffffff8160ab35>] rwsem_down_write_failed+0x115/0x220

Sep 11 10:29:44 localhost kerne= l: [<ffffffff81201481>] ? __blkdev_get+0x221/0x4d0

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811c8830>] ? set_bdev_super+0x40/0x40

Sep 11 10:29:44 localhost kerne= l: [<ffffffff812e29a3>] call_rwsem_down_write_failed+0x13/0x20

Sep 11 10:29:44 localhost kerne= l: [<ffffffff8160864d>] ? down_write+0x2d/0x30

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811c917e>] grab_super+0x2e/0xa0

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811c9810>] sget+0x2a0/0x3d0

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811c87f0>] ? ns_test_super+0x20/0x20

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811c9b92>] mount_bdev+0xe2/0x1f0

Sep 11 10:29:44 localhost kerne= l: [<ffffffffa02a4580>] ? xfs_parseargs+0xbf0/0xbf0 [xfs]<= /p>

Sep 11 10:29:44 localhost kerne= l: [<ffffffff812d6230>] ? ida_get_new_above+0x230/0x2a0

Sep 11 10:29:44 localhost kerne= l: [<ffffffffa02a2775>] xfs_fs_mount+0x15/0x20 [xfs]

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811ca599>] mount_fs+0x39/0x1b0

Sep 11 10:29:44 localhost kerne= l: [<ffffffff81178420>] ? __alloc_percpu+0x10/0x20

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811e5a6f>] vfs_kern_mount+0x5f/0xf0

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811e7fbe>] do_mount+0x24e/0xa40

Sep 11 10:29:44 localhost kerne= l: [<ffffffff8117317b>] ? strndup_user+0x4b/0xf0

Sep 11 10:29:44 localhost kerne= l: [<ffffffff811e8846>] SyS_mount+0x96/0xf0

Sep 11 10:29:44 localhost kerne= l: [<ffffffff81613da9>] system_call_fastpath+0x16/0x1b

Sep 11 10:30:01 localhost syste= md: Starting Session 140 of user root.

Sep 11 10:30:01 localhost syste= md: Started Session 140 of user root.

Sep 11 10:30:10 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:30:40 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:31:10 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:31:40 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

Sep 11 10:31:44 localhost kerne= l: INFO: task umount:27950 blocked for more than 120 seconds.

Sep 11 10:31:44 localhost kerne= l: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables= this message.

Sep 11 10:31:44 localhost kerne= l: umount          D ffff880e1= faf3680     0 27950  27775 0x00000084

Sep 11 10:31:44 localhost kerne= l: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8

Sep 11 10:31:44 localhost kerne= l: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80

Sep 11 10:31:44 localhost kerne= l: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90

Sep 11 10:31:44 localhost kerne= l: Call Trace:

Sep 11 10:31:44 localhost kerne= l: [<ffffffff81609259>] schedule+0x29/0x70

Sep 11 10:31:44 localhost kerne= l: [<ffffffffa02f1ac1>] xfs_ail_push_all_sync+0xc1/0x110 [xfs]

Sep 11 10:31:44 localhost kerne= l: [<ffffffff81098230>] ? wake_up_bit+0x30/0x30

Sep 11 10:31:44 localhost kerne= l: [<ffffffffa02a1c48>] xfs_unmountfs+0x68/0x160 [xfs]

Sep 11 10:31:44 localhost kerne= l: [<ffffffffa02a24eb>] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs]

Sep 11 10:31:44 localhost kerne= l: [<ffffffffa02a3701>] xfs_fs_put_super+0x21/0x60 [xfs]

Sep 11 10:31:44 localhost kerne= l: [<ffffffff811c8936>] generic_shutdown_super+0x56/0xe0

Sep 11 10:31:44 localhost kerne= l: [<ffffffff811c8c17>] kill_block_super+0x27/0x70

Sep 11 10:31:44 localhost kerne= l: [<ffffffff811c8f4d>] deactivate_locked_super+0x3d/0x60<= /p>

Sep 11 10:31:44 localhost kerne= l: [<ffffffff811c9556>] deactivate_super+0x46/0x60

Sep 11 10:31:44 localhost kerne= l: [<ffffffff811e6265>] mntput_no_expire+0xc5/0x120

Sep 11 10:31:44 localhost kerne= l: [<ffffffff811e739f>] SyS_umount+0x9f/0x3c0

Sep 11 10:31:44 localhost kerne= l: [<ffffffff81613da9>] system_call_fastpath+0x16/0x1b

Sep 11 10:32:10 localhost kerne= l: XFS (dm-2): xfs_log_force: error 5 returned.

-----------------------------------------------= ---------------------------------------------------------------------------= -----------
=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BA=BC=D6=DD= =BB=AA=C8=FD=CD=A8=D0=C5=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE=B5=C4=B1=A3=C3= =DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8= =D6=B7=D6=D0=C1=D0=B3=F6
=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE= =C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0= =A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6= =A1=A2=B8=B4=D6=C6=A1=A2
=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2= =A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4= =FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB= =B2=A2=C9=BE=B3=FD=B1=BE
=D3=CA=BC=FE=A3=A1
This e-mail and its att= achments contain confidential information from H3C, which is
intended only for the person or entity whose address is listed above. Any u= se of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender
by phone or email immediately and delete it! --_000_1CB94550540AE44E9CAAE8CD5AF40BF846CEDB68H3CMLB12EXsrvhu_-- From 2kx_dhh.h57.1db@audienceoneline.com Mon Sep 14 22:18:03 2015 Return-Path: <2kx_dhh.h57.1db@audienceoneline.com> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=5.0 tests=HTML_IMAGE_RATIO_02, HTML_MESSAGE,T_DKIM_INVALID,T_REMOTE_IMAGE autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id C1CB57F37 for ; Mon, 14 Sep 2015 22:18:03 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id B38A38F8040 for ; Mon, 14 Sep 2015 20:18:00 -0700 (PDT) X-ASG-Debug-ID: 1442287075-04cbb005ea105bf0001-NocioJ Received: from smtp-a3.wesszing.com (smtp-a3.wesszing.com [82.97.40.196]) by cuda.sgi.com with ESMTP id yAfi78rCVdxQKhNt for ; Mon, 14 Sep 2015 20:17:55 -0700 (PDT) X-Barracuda-Envelope-From: 2kx_dhh.h57.1db@audienceoneline.com X-Barracuda-Apparent-Source-IP: 82.97.40.196 DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=audienceoneline.com; h=to :subject:date:from:reply-to:list-unsubscribe:message-id :mime-version:content-type; s=smtp; bh=oUsvyxPJqsqbFDdJA6W4JcOcB KE=; b=YwaQv+hI7hRAJn4YZBNUgtyD3elYfdQwzJLSOOda+1TmvWosbXywGppmE Yu50kIlngzz/5Hd9Qi4wEQ2A2GStE2LYPtfFzti+qZMfT35Ez3w7Xw8quTEt6Ntb YqaqyzQP6yctTlrAmmh1tPgcmAT7h57THaGcOr7GteTfedbC6U= DomainKey-Signature: a=rsa-sha1; c=simple; d=audienceoneline.com; h=to :subject:date:from:reply-to:list-unsubscribe:message-id :mime-version:content-type; q=dns; s=smtp; b=TPvtBihBYI4yqlrYOlY Ki9oBvZwkT5tmGqqtRqJktlMp7NLJYovJLRloHNU9f5bIoEzq+KPnJMa2WaJSzSP OjkE5bdmHfcsYWsRnowHmnFhjpOc3bM67lLYjiFjHHyRc/taYP5XmPiz9/2/CbOw ntaUU+OPz/J/f3pcymEwqx6U= To: xfs Subject: =?utf-8?Q?R=C3=A9duisez_vos_mensualit=C3=A9s_en_regroupant_tous_vos_cr?= =?utf-8?Q?=C3=A9dits_!?= Date: Tue, 15 Sep 2015 05:16:33 +0200 X-ASG-Orig-Subj: =?utf-8?Q?R=C3=A9duisez_vos_mensualit=C3=A9s_en_regroupant_tous_vos_cr?= =?utf-8?Q?=C3=A9dits_!?= From: =?utf-8?Q?Rachat_de_cr=C3=A9dits?= Reply-to: =?utf-8?Q?Rachat_de_cr=C3=A9dits?= <2kx_dhh.h57.1db@audienceoneline.com> X-campaign_id: 964678594471_3 X-uid_id_m: eGZzQG9zcy5zZ2kuY29t=510 List-Unsubscribe: Message-ID: <5e66ba30d70e4ba7b178efcc8006a786@audienceoneline.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Part1_5e66ba30d70e4ba7b178efcc8006a786" X-Barracuda-Connect: smtp-a3.wesszing.com[82.97.40.196] X-Barracuda-Start-Time: 1442287075 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.55 X-Barracuda-Spam-Status: No, SCORE=0.55 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_IMAGE_RATIO_02, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22550 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.55 HTML_IMAGE_RATIO_02 BODY: HTML has a low ratio of text to image area 0.00 HTML_MESSAGE BODY: HTML included in message --Part1_5e66ba30d70e4ba7b178efcc8006a786 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: quoted-printable Pour visualiser et se d=C3=A9sabonner ce message, =20 Veuillez, copier puis coller, l'adresse URL compl=C3=A8te ci-dessous dans= la barre d'adresse de votre navigateur et appuyer sur la touche "Entr=C3=A9e= " de votre clavier. - - - - - - - - - - - - - - - - -=20 http://app.audienceoneline.com/v/?camp=3D964678594471_3&ms=3DeGZzQG9zcy5z= Z2kuY29t - - - - - - - - - - - - - - - - -=20 --Part1_5e66ba30d70e4ba7b178efcc8006a786 Content-Type: text/html; charset = "utf-8" Content-Transfer-Encoding: quoted-printable R=C3=A9duisez vos mensualit=C3=A9s en regroupant tous vos cr=C3=A9= dits !

Si cet email ne s&rsquo= ;affiche pas correctement, suivez ce lien.

=
Obtenez gratuitement une= étude personnalisée =
<= tr> =09 =
3D"Rachat
3D"Rachat
= 3D"Rachat
= =20 3D"Rachat
= 3D"Rachat
<= a href=3D"http://app.audienceoneline.com/r/?m=3DeGZzQG9zcy5zZ2kuY29t&c=3D= 964678594471_3&rc=3DaHR0cDovL2FmZmlsaWF0aW9uLm5lby1kZXZpcy5jb20vYWYvY2xjL= 05qVXhYM3hmTVRZM lgzeGZNamRmZkY4d1gzeGZNQSUzRCUzRC9hSFIwY0RvdkwzSmhZMmhoZEMxamNtVmthWFF1Y= 21WaFkzUnBiMjR0Wm1sdVlXNWpaUzVqYjIwdg=3D=3D" target=3D"_blank"> <= img src=3D"http://app.audienceoneline.com/r/?rc=3DaHR0cDovL3JlYWN0aW9uLWZ= pbmFuY2UuY29tL21haWxpbmcvcmFjaGF0LWNyZWRpdC9pbWFnZXMvcmFjaGF0LWNyZWRpdC0w= Ni5qcGc=3D" alt=3D"Rachat de crédit" height=3D"98" border=3D"0" wi= dth=3D"650">
= 3D"Rachat
= =20 3D"_pspacer4"

Pour se désabonner : Suivez ce = lien.
Si ce message vous a causé un quelconque dér= angement, nous vous prions de nous en excuser.

--Part1_5e66ba30d70e4ba7b178efcc8006a786-- From 3iZ33VQYOA1gC9666VOOJ.8OO677.2ECN5IEII.I68.2EC@photos-server.bounces.google.com Mon Sep 14 23:24:45 2015 Return-Path: <3iZ33VQYOA1gC9666VOOJ.8OO677.2ECN5IEII.I68.2EC@photos-server.bounces.google.com> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=4.0 required=5.0 tests=DEAR_SOMETHING,HK_RANDOM_FROM, HK_RANDOM_REPLYTO,HTML_MESSAGE autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 14F1C7F37 for ; Mon, 14 Sep 2015 23:24:45 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id B8E688F8035 for ; Mon, 14 Sep 2015 21:24:44 -0700 (PDT) X-ASG-Debug-ID: 1442291081-04bdf04db4102300001-NocioJ Received: from mail-ob0-f202.google.com (mail-ob0-f202.google.com [209.85.214.202]) by cuda.sgi.com with ESMTP id Rzjg2OVsLRPW4n7p (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 14 Sep 2015 21:24:42 -0700 (PDT) X-Barracuda-Envelope-From: 3iZ33VQYOA1gC9666VOOJ.8OO677.2ECN5IEII.I68.2EC@photos-server.bounces.google.com X-Barracuda-RBL-Trusted-Forwarder: 209.85.214.202 Received: by obczc1 with SMTP id zc1so12806839obc.0 for ; Mon, 14 Sep 2015 21:24:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:reply-to:message-id:date:subject:from:to:content-type; bh=gJlDYysrwcSRmgZf2hW9IaqR2MCy26wt7NFcaypYHmg=; b=PPTVpDKz5XXpZSYAsMlqTGIOgNu4eu3r+IyGqdi1SuMJPuIiK420SswlLQlXydUaGi 1INBt4dreMrghywFLnuwDuYsoSDf/idIhaYTl4mxCJg3EEpZ8Umt3tocH37EO1v5rW9f /1f3DV2aqnaghVy1Kp6GwiD7A82AkfOhaFR8t+r4yOf/gd1orpalJlF3N1lTdDULkYVC 2u0YYxnNQ/TsvBsNewwDQ1Rf7RmmwU4SD3GS8JYWhzmAoKUeY4lLErr/bfIcXLN4a08v MyRdW/8dp2EJBMcDN4toZkHVKEuACLxA5soWMsz+RWT8LrU9f+DcflNF4RGJbnWQD6nn 2xTw== MIME-Version: 1.0 X-Received: by 10.182.241.72 with SMTP id wg8mr16780835obc.2.1442291081242; Mon, 14 Sep 2015 21:24:41 -0700 (PDT) Reply-To: "Castings casting&lost-wax casting for steel parts" Message-ID: <001a11c2ffb88f69c7051fc18f21@google.com> Date: Tue, 15 Sep 2015 04:24:41 +0000 Subject: =?GB2312?B?Q2FzdGluZ3MgY2FzdGluZyZsb3N0LXdheCBjYXN0aW5nIGZvciBzdGVlbCBwYXJ0c9Pr?= =?GB2312?B?xPq5ss/twcvP4LLhoaM=?= From: "Castings casting&lost-wax casting for steel parts" X-ASG-Orig-Subj: =?GB2312?B?Q2FzdGluZ3MgY2FzdGluZyZsb3N0LXdheCBjYXN0aW5nIGZvciBzdGVlbCBwYXJ0c9Pr?= =?GB2312?B?xPq5ss/twcvP4LLhoaM=?= To: xfs@oss.sgi.com Content-Type: multipart/related; boundary=001a11c2ffb88f69ad051fc18f1f X-Barracuda-Connect: mail-ob0-f202.google.com[209.85.214.202] X-Barracuda-Start-Time: 1442291082 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22552 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --001a11c2ffb88f69ad051fc18f1f Content-Type: multipart/alternative; boundary=001a11c2ffb88f69a9051fc18f1e --001a11c2ffb88f69a9051fc18f1e Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Dear Sir, Nice to know you through website. We know you purchasing castings from China,so our factory hope to have a chance on our cooperation. We mainly produce lost-wax casting for steel parts. We have own CNC machining shop. We specialize in this field for several years, with good quality and pretty competitive price. Any questions and enquiries will be highly regarded. Just email us the drawing and detailed requirement, you will get a complete quotation with technical analysis within 24 hours. FREE SAMPLES can be sent on request. Reply me, let"s talk more! Thanks and best regards, Yang Shengwu General Manager -------------------------------------------------------------------------------- Add: Linqing,Shandong, China https://picasaweb.google.com/lh/sredir?uname=117938483580819955015&target=ALBUM&id=6128199190709823009&authkey=Gv1sRgCKyAi9_O_YjXIA&invite=CLqSsKcJ&feat=email --001a11c2ffb88f69a9051fc18f1e Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
=D1=FB=C7=EB=C4=FA=B9=DB=BF=B4 Castings casting&lost-wax cas= ting for steel parts =B5=C4=CF=E0=B2=E1=A3=BA Castings casting&lost-wax casting for steel parts
Castings casting&lost-wax casting for steel parts
2015=C4=EA3=D4=C219=C8=D5
=CC=E1=B9=A9=D5=DF=A3=BACastings casting&lost-wax casting for steel = parts
=B2=E9=BF=B4=CF=E0=B2=E1
=C0=B4= =D7=D4 Castings casting&lost-wax casting for steel parts =B5=C4=CF=FB=CF=A2= =A3=BA
Dear Sir,

Nice to know you through website.

We know = you purchasing castings from China,so our factory hope to have a chance on = our cooperation.

We mainly produce lost-wax casting for steel parts.= We have own CNC machining shop. We specialize in this field for several ye= ars, with good quality and pretty competitive price.

Any questions = and enquiries will be highly regarded. Just email us the drawing and detail= ed requirement, you will get a complete quotation with technical analysis w= ithin 24 hours. FREE SAMPLES can be sent on request.

Reply me, let= =A1=B0s talk more!

Thanks and best regards,

Yang Shengwu
= General Manager
--------------------------------------------------------= ------------------------

Add: Linqing,Shandong, China
=D2=AA=B7=D6=CF=ED=C4=FA=B5=C4=D5=D5=C6=AC=BB=F2=D4=DA=C5=F3=D3=D1= =D3=EB=C4=FA=B7=D6=CF=ED=D5=D5=C6=AC=CA=B1=CA=D5=B5=BD=CD=A8=D6=AA=A3=AC=C7= =EB=BB=F1=C8=A1=CA=F4=D3=DA=C4=FA= =D7=D4=BC=BA=B5=C4=C3=E2=B7=D1 Picasa =CD=F8=C2=E7=CF=E0=B2=E1=D5=CA=BB=A7<= /a>=A1=A3
--001a11c2ffb88f69a9051fc18f1e-- --001a11c2ffb88f69ad051fc18f1f Content-Type: image/gif; name="picasaweblogo-zh_CN.gif" Content-Disposition: attachment; filename="picasaweblogo-zh_CN.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhzQAfAOYAALu9v93e37C7wQClUJ99rtjd4OySN4mZovb3+Jmcn/f392uAi+ZXVcTM0eLm 6Kqtr9XW1+7v7wB6tObn53WIk+zu8LrEyaazubO1t3+RmsTGx/bJm87V2ZOiqpyqspGUl8De7MzO z9vP4fOrqkC8fKWFs+ff62Cs0P719aKkp4DSqO3n8OhiYPn3+vvr2sOuzLDjyet3dfPv9bGVvaDd vvbAwPnV1dXG3CCwZvrg4PGhoP758+yBgNDu34C92vCnXZDF3reewsDp1P3y5xCCufD69fD3+/TC j+6gUHd7f/O7gjCTwu2ZRJDYs4iMj72mxxCrW6uNuPS2tffQqICDh9Dm8eTn8OD06vGtaWF3g/// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5 BAAAAAAALAAAAADNAB8AAAf/gFqCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6iKKDo8DK4sPFIoqbS1tpcyTyI6rr2uIy47t8PExYQiJQQEIjW+vxs/LocVAtXWAg0VxtvclSLK 4DfNviMbBkzShQVZ7O3tHghaDgcc3fb3hSvg+y82LL3lDBj4IYzQuiwHEibMwK6DFgFZBOCbaC/K PnAzWuT4xyCgwCPq2BlqwM4BggbxihWg0GCBFpcUt327SCBIC0E5YnQ0J9DAEIMiDTG0MK8AoQYe DnSwkHJQBQsJLxi10CHl0w5Kmaq7kJBphQ4NBB3QQqFDhpjbZtB8UQhFDI8C/6cAzXLoQESIEuUx dLegnqCW7rJcWJDFqAPCfB0IQmDXHQULCMVqGZwX7bAWaw+hsMFTIJa5hyhkaYBXCwLCCy5wECC6 sBYO7Chg8+DOKGGWBSwQPqtlr4cGFlpHlqelgvFJCghNSG5oQoRFzLUoiB69mImLNxR1FgiaEALa WahF1EJ7geLFDA+czlJ10GF2BQ42dVCS5GhC4Mcm0gCgv///CQQwyAfRPRDCIf1JB0AADAaQwHNa aABBABqkEAAGDH4wwTbXgSPCItsZMJdCB+w1Hl4IsBMWIRUcgE0WCzQlCESF0ReRNoJcUBVDHhSC gGj6IbJgIgkMMuEgCnzQX/8CEBAypBZFDjgIAII0SKUWVxrTYQki+ACCdj1xN8hBgWXx2IwRHZQI RA75CJ8WjbFzgFSCvFnIBcMJKaAWATwwyAMODnIgBE1ioIEgfgoy4QMaBBilII9eaaUgWVpHQAkr nCDBl4mEOFd8oOKIpgDr8HZIaYa8iQBrgfUYVCEQBYkgBMmFAMGGWvgZpXO5KsBgBCEAgKsWEwSQ hAYBRPBBg4FSWiWDV1ZKjAyYaropmD0h0R0ieKnJLXuGVAAfAgXEQ24DjcHm2p15zqpBBA9Mp4EC GEApyAcYYKhAk1hKOwEVVy7bYKTPBhBtdcRYsYQEDHOKyHZKbHvqeIRZUMj/YaqxIyqahUF0QSF2 CcCjj4TJasiQ+QqiQID2SqfAgUaGgEGlGDwAQb2P2jsBAAn098DPPfOM7zZAMNwwJd5+KxGeCxiF HriiZdCUfYVBZt4gP2ZhgX0rmtaYyYUMGcIHEP7cshYHKhBBBE8G8EGTCvRncLOQTllwtN0YQYTR IJAwwN+ABw44CSHRteZ4COzVgQAeoKaYuqkJEGdh60XO6gLafC3ABaKVrMiCccPLJwQLRqnBAwDc urN/GPA775NOAGg3n9A6203RDfst+O4D9BASTEovNrmZ572GWDuAGSYcOwus+F1gGZAEtpMQHMrn ztI1qvIgG2Y5ZATd75kzy8G0G2x7N9b2zbvgNBiyql+IOCBA8fJYAz/WpAlggTYcWDzIatVAycWs EZb3fY5fgrBe3VTGn+R4b0+UEh8hyDcpLOFDU+pb39/aZxlKPOkQUUrBAyBkwQg6SYKDoGDtSngP H1RBd7zDAQw6WIkPIulmKRAECQWBIQYB6oT3YtajchiCABlsAjWLiQqgsDscNKEINKxEBBA2iB0W goRWDABzhkUs7ulQOs+ZjmV6AAMVqEAIV4iiGtfIxja68Y1wjKMc50jHOtpRFIEAADs= --001a11c2ffb88f69ad051fc18f1f Content-Type: image/jpeg; name="email.jpg" Content-Disposition: attachment; filename="email.jpg" Content-Transfer-Encoding: base64 Content-ID: <6128199190709823009> /9j/4AAQSkZJRgABAQAAAQABAAD/4QBgRXhpZgAASUkqAAgAAAACADEBAgAHAAAAJgAAAGmHBAAB AAAALgAAAAAAAABHb29nbGUAAAIAAJAHAAQAAAAwMjIwCZAHAAsAAABMAAAAAAAAAAoJkAEBqAEB wAEBAP/bAIQAAwICCgoICAgICAgICAsICgkICgoICggICgoICAgKCggKCggICAgICAoICggICgoK CA0KCgsKCAsNCggNCAgKCAEDBAQGBQYKBgYKDA0MDQ0NDA0MDQwMDQ0MDQ0NDQwMDAwMDAwMDAwM DQwMDAwMDQwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAkACCAwERAAIRAQMRAf/EAB0AAAICAgMBAAAA AAAAAAAAAAcIAAYDBQECBAn/xABKEAACAQIEAwUFAgoIAgsAAAABAgMEEQAFEiEGEzEHCCJBURQy YXGBkdEjJUJSYnShs7TwFSQzVHKCkuGxwRcYQ0RVZJOio7LT/8QAGQEAAwEBAQAAAAAAAAAAAAAA AAECAwQF/8QAJhEAAgICAgEEAgMBAAAAAAAAAAECEQMhEjFBBBNRYSIycYGRQv/aAAwDAQACEQMR AD8Ae3t04ilgip2hleItMVYqbEjlk2+VxfFRa8lJWBuTtcqV61k3+sYp8TTgVjPO8xPFsKmdztbx 2B+xSzemy4yc0NRKdnHezzVDHoErhpCr2ZQY11H8K2txqUdNhe25A2xjLI11RXA4zPvk1sGgyy8/ U4RVSbRISettWpRYeu3QbXxKzfQ/bL9kPebMxVDWzQSsLokrqpb1CnobHr0ONo5UyXAtMvaFWf3u b/V/tjS0LijXz9plb/fJ/wDUPuwhqIwnZJmby5fTyzO0kjCTU7bsbTyqL9OigD5AYRlJUy4YkRMA yYAJgAmACYAJgAmAAEd7Ss0UtGf/ADRH/wAL4sqAsQpJZoZXjaMPZlh1klNdtiwXxFb7bfHY4xbs 0ZR0p6mK0cqxy1znSTHGQCGNkNugY77bKepvY4xcn0i0kzrxBwGqKZKufWbXkIYJChP5PMkvrI6e FAvoW64hxKTA5xBFQyyrFFVCG52lEmsJuCTuoU7gC4II6gjCodhRo+EfwdPKzpmAivonYIZASPEV KXAv06tsN/XCoYQ+DuN2jAVizwdLHd4v8JPVf0SbelthjWM60Z0EZpgw1KQQQCCOhB8xjrsQzvYs /wCLKX5S/wATNhLoxydl35nw/wCH34Hogmv+dvvwrA4M383H34AOeZ8D+z78AE5n87ffiqAhk/nb 78FCIsmEM74mxi8984/1Kk/Wm/cPjRlQFUiqHAQoSvhFtzbp9nrjkkb0ezgHN3NVUrJHcWitJrJL DS1002BGkm4N7G9rbXxEewfQEu3WuaqrZIiT7NC5jijBspK7NIQNi5a43vYAAedyT2OCK9xnw9T+ zAQ2JKgKo6g2A6bEW3ucFqjagacM8Z1mXTh4Ji0YPjjcl0YDyYXuQfd1e8uxDLvgMnoaOk48p5aJ Myi1iKRSs8abyRSCwdfIXVyGDdOjdGOBryIIvZFUsKaONppKhGUvFLIFEnUkxtp2uBtfzIPrjbG7 JY7fYyPxZS/KX+JmxsjGfZcKupCqWYgKASxPQAC5J+AHXEyeiAQcT9szeIw6YYgCeZIRcgC+rxHR Gtt972G5IsccLyvwaqHlglyvvSwzT8uLNdUmqw99Y2PojuixNc7A3sfK9wcZvLkGnAM/CPas+oJV dCba7WZT+kF2K+pHT44rHmbeypw8oKqP/N8eipas5zth2FHKdfp92Bdj8GXE0Au/fRktRUe1/wCt N+4fGpUBOtc80CLTypHIkrpNcAuVT3FGq6LqUo7Eg3BsNycckls3RbOFqYpNHzLapY1SQgWUSoLh gDuA3iUX/RHyxQwP9vGWNS1hkZCYZ7ujjpr/AO0iNxswI1j1Vh6GwNAxn4nQjz+zENGyYOOMKgNf T1+zGkUZTGL7nvCTVOV5u0qkwxyIb9F1mnfmj0F0ERPzU4242jG6Yz3DfDsMCxUiMiSrAJBDrBm0 G5MhUnWQWvdt9wfTFwVAxsuxg/iyl+Uv8TNi0Zz7N3xlRF6WdF94xPYep0kgfUi318sRNfiyV2LR n2SpV0ssDE8maIozKbMt+hA9VYbqfNSp88eWnRu5Hz24lra6jzdaPNqdEIpY6eKWGAx09RyiypUo wGmR5oinMudYZSGUMDfrkk42jCUKdjy9h9dUPl8Zq0cOGZImcESSRKF0SOG3uDeMEi7Kit+Vc8rS o2i35CRwR20CHMjl8rlkKIwu2oxliV1DrpUONDr5XB26YrHncWoy6CcfgYtMentbfXgxO6dfp92G uwfRlwALv30l/qVH+tt+4fFlY2JZTZl7POZT/YyWSf8AQKnwT/Jb6JD+bpbflnGU4nQFGhTUNQtb bSbdbbjptb0PyOORjRuKvK4KqFqStiDxta+rbcdHDLvHIp6OD1tvvuhgM427i9RctltZFLGd1jqb xSD4CWNXjkFuhKJ9fNhZVeH+4Bmk8oWqnoqSG41ssjVMtr76I0RFLWBsWlAG1wcCZLY8PAXZ3R5f l0WTUgLQK4epZiDLK2pWcysosZJWVVZQLLGNACi1umD1Ri15NjxjwDSNIuZPCpqoIpFikuUYCUFS pAIWRbsdIYHSSbWxtSEmGLsXX8V0nraX+JmxLFPsp0vbwwqWTkp7OGK3BZpCAxBbyCnYkCxDAEXB Fjx++roOJWu0jIzSF8xpmSWgnPMki1hWjke15YOpeOQm7oFLI1zYC5TnyRrfguO9FDftihKahHM4 PuhTGw2A6MJdIP0B+G+OeUzVQK1V9rLzSJT0yxU7ySBBJI4d11bA2UFFPTSTqN7WW5xzyk0rNVFC lZn2kT5bxnzqhpZKeMxRusi6S1M91lbTdrku0kwLHUX0k22GPQxJTwqXkwknZ9gODM9SWG8bq4U6 Lg3uAqlT/mQg/fvbtxT5x/g52ixJ1+h/5Y3XYmZcBVi998pL0dH+tN+5fFjgJNxWumKRvRHP2If5 /k4hnQDTsa7xT0qpTVgZ4NtEgF3jHpva6j0vt1B8scs0vBSC1x1PmFdJl83D9bTGBWb20c3ltuyl Xa6szIq3DQkAk+TBgVlfYnYxtDUaSLM3W3hJC9BckA7efy6YQHtFSzdXcjYkazb5bWuD/t5YCWVH s+zbMFr8wjrooBl62aimQBLEyleQbEvIwis7FlBDbX8Vl0jZLLNxLxEZF5YP4MG/TdiL2J87C+32 46kJdjAdiz/iqk+Uvw/7zNhNaM5/sLhxpl602aGmEnLqJXmmgRidE6podgL+EPoYaQCDfVswR8eP lhTs1jsqnbjk9RE9JXUYM1NMnKZXYslPKLsskYJKR6xrVttnQEC7nESncaLjGwWrwNG+YPIVjtKu tyqAokhF3AB206wSPgelgMY2UtOjLm+RmJmCeFo3R13AsVAtbSNIHQ9PrjCTbdGj0BftSyYvXSTV iye0SQXj1xshZWfwSjWqkoWRgrC6mzWO2PWwpqFGDlsd/uEcWyPzqeUswNJE4ub2aF+Wd9uqsvQe WKwSqbiZTXkcdOv0+7HorsxZlxNlAB74SXo6T9ab9y+LY4CXcXURMEwHXluB/pOIZ0C2Jw9eJGt1 UH7RjkZukV7MBNA6NSyyQylrI0bsjXv6qQbdSfhhpWS1oYbs67Qc5OiMZgsmwB9opo5L/wCZQkn2 knEthoOGXpm7IZXq6NEVSSIaULK1h1VpTKqm3nb19cCTM3Rt+HoGLCSR3kex8TtqI8726KCR+SAP ljeBLLBWG2OglDMdiZ/FVJ8pv4qfCM5dg570PZtFMKPMHEgajlLhoheQXGwsN2U7oQNyCBve2OXP C1Y4PYv2b53MIPZJFaSGSUqbdQyyI6G5IC6lKEb2F3v5nHkUdMfkIeUd2fMdGyUEN/yZJmlexFiG McLJe3UBj6fHGy9HOSsl5EmELs27siwzLUV8kdVItjFGiWgRgbh21Ac1l20goFGxIcgW68XpVHbM 5ZL6Mneg7rkWdwwssvsuYU9/ZqjRrXQ5BemmUEM0LEB1KnVG41C4Lq/XONoxT+TN3dO702VRappU lqWj5bcsERqC+trM1mY3Ci5UDbpvtjiw8JNmkpJqkHFOv0+7HWYsy4RQB+9ul6Sk/WW/cvixxFPz PLNSlSNiCPtFvt3wmrNbF+zzhidKj2aJYpCqqzan0eB76fI2fY7W6W9RjikqZvFnT/ohqWmErNAA q6UBdja/vMbJa/kPQX33wlKgYSuF+GpYQpvCSP0m8v8AJ/yxABr4b41dVKvChUruVmJv8LGIXv8A PGilRNGHL3GvcgqCx03sCQQUu1r6RuStrEgdRsajKhNG+qZ7oH23JFutiLfLyIOOlSszGd7DHvlV J8pv4qfDozl2W7O8qWWKSJxdXUqfXcbMPip8Q9CBiZK1RIoXH3AskbywyAvLzleIKD4xy9AKgAlt SqGPobg9MeNPE0ztUlxHAyu/LTV72lb/AD0i/wC2+PWxv8aONs9eNBEwAc3wAROv0+7AuxMy4Cyk dqfZkMwjijaYwiOQyXCB73QraxdLdb3viyE6B5/1TYv76/8A6A//AFwNj5WV6PuJ0gkmm9qkM0ra mdob28lULzwmlBsAQb73+GbimWptHQdxyP8A8UnH+Gjph/8AYPiPbRXuMidxaHzzjMT/AIY6ZB/7 YAf24ftxE8jPfTdySmFr5lmT/OodQfpFJHilCIubLFD3XYVUKtS1gLeKLWfqzylm+pJxSUfgXJmO TuupawrGUfCnUf8ACUYaFzCfwHweKSkipRIZRHrs5UITzJZJPdBa1tenrva/ngJbs3/KGEBjakF7 2F/I2F9/j1F8S0mB2WD+bfdgSoDvoxQE0YLETRgsCBMIZ2wFWTDJomACYQzXZ7xHDTpzKiaOFPIu wW59FHV2+Cgn4YABpmXeiy5CQprJgNrx0cun6GRYr4LI5I8lJ3tcsNtft0Sn8p6CZk+ZMKzWGFY+ SYRuDu0GkrUMlDVwVSj3+XIGZD6Om0kZ+DqDhrYyw4YUTCAmAZMAEwATABMAEwATABMAEwATABrs 9rXSNmjUFwNr+79dx5fHAJsRvt6lq5ZtczMWMhudgDGBtFHa2lVO7RqASd2BN7yYu2iuVVZTrTaZ ZUBI8IZ7OWttpUHU2+1rb9PTFNpLZzU7BbL2xpTMIkgqlsb6jE6hjcX0ggEi1jYi/wAPPGXNM61B 0W2r7YChp62k5kFbES5mC8timkfgpRYGVWbYrIp2BH5WBsaPprQSkojMAGKKWA6BioJAvva97Y2K R6MIomACYAJgAmACYAJgAmACYAJgAqfGHFTRzUtLELzTuxva4SKIoHb5lnRVv+l6YL3RLZYczqFW N2dlRAtyzMFUD1JOwGKQpdCm9qnbHQKxjlKSsT4Dq0lwPJQ5HMtuL6CelztjKRmmByry5JnLwpqj J2DrpZfVfBpHwvttYW23kdljynswRoieTDq9W1Pv6eORh+zGiijnlNplJz3hJnligsp1zxxhY4wq +J1BIVAB6kn0Fz0xLRtFn0zYdcWb0TAMmADw55nCQQzVElxHFG8shAuQsalmsPM2BsMKT4q2I01B 2kU0kKzRSNIjLqGiN5NrHYlFIBuCNz1BHkbYrNBq0xpN9Go7Pe16Grpo5nKwuw8SnVoUgkFS5UKC GDCzEHa9hcYWPMpLYdq0WbhniuKpR3gbWiyvGWtsTGxUlfzkJB0t5jcbEY1jNS6/gDcYsCYAJgAm AAc1L6s6Zmtoho0A9QWaZ287b3iAsATbz2sktmcnWxTe9V3sZTW0eXUkaLBJVCKqnks+hVcKYoFP gWS58c7BitmVNNw4bl4RhFc9v/DbdlXZNSS5lSyVcdLNvIrK5vcNDKLOGHvhjrB1AqwBBBG6cU+x wk7C3xdwTkdLLTQNVPSmeRkQR1UTxxmOMuWlacSvDGbBAS1tRUbXxLikbOmafs24p4fnSZmrpKcx ymNo66rp6VnAAIlj5bjmQtuAyydQbhdr2pIn24sruR5HE+d82m0NRyVkQpGSTmxPHG8YZ431uGVn ViSGO5OEiZKmkODhnQTABpOMc25VPKysVlKMIbKGPM0HSdLeEhT4mvtYHETlxVkt0KfS942SW9Ln UawllMazoxNHqYEAyIwHKuT/AGjAqPMxC5x5cskpaZjDKpaejXcA8RjL62WhZ/wEiu3KBJ5bpGXJ QeSSRKx022kWO20hGJcdE4cjhJwfwze9lHG9OklTomAhacmO+12kWLUN7b3VnPxc+owpK+i/T5VB VLqy0dmOcvSUrzJIQiiWUqd42TXLKAVvsTC0dmUhhcbkDSaxZZQdHQknGwx9k/FclTSmWdo+dzWE iILcq4VhCR1OkGwY+8Be53t6eKTlG2SXTGoyYAJgAAXbVxDyDWyIxWWbl08Z8xoiuSPjbUR6NGMO K8nHnfgQ7tS4W8VHJYhY6pGYj8leYrFr722XqR1xlP5Kxy0FziHLJJqWaFQH1INB2AbxqdRN9FiB fy+lxjQjyDPOOD6mnReTLBBOQQgILgm3vMkbRkhf8drm298SnRbXLsr/AAPwJUSNMKyuirBrILrE YaeMxMVZVJBbVq8N7AGykBgQxT2Vyrob7u3cDSpU0uhZJKSKUnmaTyo2WJiRq90sTyh620XGKiqH fJpjgYZucHAISzt8z3NBmVQ9BXP7MHKxxNDFJoKALIq6oyWQyK2kdbWuTsR5Wfcns5XlalQAoe05 8xrY8jraURVkzMlPVU0ZVVZUZ/61TM7Dk6VbXLC66OphdQ1ktKyvajk30M5wp2U0tJDSSVTJUVNN AI/apSUUKNWnws/LCojcmMvdxGqLq8K2ylI6lFLbOargDLamFUijh5KymRTSSKg1kKGu0JKnUqqC GFwALabXxKYOMWD3MuK5qJ5aSqkikeomvSRpcgx8waXcWtDTx2RBGSWkKcsXQu+NY/l0cmRyx229 eEE3KOJzTT00cFUImlKU80pAkDF5EsoUqQzxuxeSTpCHdT4pfBWFyUuK8nQ2lQ1AGPWHZzgGTDAU XvG5wjVNPGs0TuMwkjeNZFaRCyVSqXQEsvl1H5S9LjD8f2cOXtnn4Y7TMkyukmqa+SOqzFLkUiR8 +pXa8aLGV5cbSAh+bKyoqsDqUBry3RriSasonZ52uHPWr6uSmp6FY5o4oookuVQIzgyPsJZyT4pA iiyqoTw7kfyM874tA74dyMrU0zKRYVAuTZR4WawJ+J2Bt1sMR5LvRdcp7LjSQNDzHdZq7nsZCDpe Zgzfm2Qlddidt9wLWujJyDt2ecdSUsHMp5UraZmZysRiaJ7bNyZI9RWbw6btM8ZKhSkdzIlVq0KG bi6YwXC/E0VVTw1VM4kglQPGw9D1BHVXVrqyndWBB3BxJ3noziF2ilWKTlSGNhG+nXoYqdL6brq0 ne2oX6XHXCfTA+ZPE1HndSksjZlUogGrVFUf0fTJqsdTNG0EcY33Mkt7+bY8FvdGMcjb6N93RZKx autSsz2HM9NKhhpxWSV0sRaYBpubLGVVNP4M8modTrGobIcNvXR2WMTS8Gf0hWCF5mgCgct1SOR0 8DM0kSzxywCokNo1kkiflpHLoUNIWxeKCnKmS3Ro67s1mocxnhNS9ZGsNNPDUSRRR1RjqJ54ZaKp NNFBDUBOWKink5QkXdSTa71nxKDpB+wOu8nNMsVJPR0MdZVLOUDNE0zQpIhJdY1dFkJdEH4RXRTv oubicW3T0ZZVa0rNBQVUcNOZ8yqCKxom/tHCyILH3IY9UpKblI4YNAI3MdyQcmp1E51H/qf9H0H4 aeYwIaoxmcjU/LUogvuAAzORYdbsfmep9mN1vs6UbTFDOMMQg/btSmLNpHIUhM05mygMRKOYAxAB PhZQLk/stiYvZyZV8Ai7XMpWWvaqhVwrpGrhtN9SRJG1gpfYACxvc9bLuMVLbJhpUXDsCo0oIasr GWWeRZSNejSY1K2sUbYi3QjDhojL+VFa4j4mWKB9TcuRlfdgVW7HdUILqeptqYMR0UgEiGzWA3Pb JUQyFJH5chkigkaNwXSRWpiND20jltfS3jBsdr9Mbaown+1opEXH8dFRCKGlpIQqnSkSMIgT52aV mJJtcliT64nlSoVcpWWXuD5q5oq+BixijqkeK/5POjOtR6C8atb1LHqTfOPk9CHQ0Mt7G1r2Nr9L 22v8L9cPwWfMTtR7N6+orqilrpI4o6Z3WGJZGFFAqpzBNdgha8RWVp5F1BTYcsALjwcicJUzO3dI 0XZDncNFXQf0dAKkPeGurJmaJzT31yyxIXWKlpogntDGYNK6IAzIzCNRpsuMxseHOJ45VSqpJo54 m9yWJw6HSTtdTsVa/oym/S5xMbWzWzaZtnpYM8rKqDxO7NYbband26AerWGG25PYkxFO9f2h0eY5 kuWTNW0hoJnRZfZ0qaaV5ViLu9PzIalAFAWCojMgkRnYRaWRn7cScE5adkT3pMv3ZpwRQy+z5fSy xTVU1441CVETMxV2YkPSeACNXYlyoABN9sc8VNytIw9tPt2fTrLpXKKZUWOQjxora1U/mhrLqA9b Y9pX5Nz04BkwxCa96jJT/SUmlC5kNHKqiw1FiKfSD1DMYwAbYwk62ZSjZZM07plTJTXWooqeoCeG A03Nj1W9x6nVzwSdmZVe3kXG5Km92l9CWNAQzPhmemc01VA9JOB7jsoRxf3oZr8mdL2919d9ilwc NT8S0yXjaKZxhwXJIhieJ0DDZmRtv0luLE9De+L7EtMJmdZrNMlJyleWSOjghk0I7HVCgVtgLkGw 8iLYtswo1UPAtXVSiCOJnk8o1IMo+Lj3KZB5vOVA/JWQ+HENm8YjodiHZSuWUK04KtMzmWodb6TI yqNKX8XLRVVFJ3YhnIBkYYaVHQlQQcMoW/vb9i1TWx82iSMAoi19mb2iaGGTUsSIFIcAku/iDOiC MB7quOHPibfJLoykn4E/414e5MKUtOg1VItM19/Z6coWW/lz52TUPP2dRbc48tSfbBfRUKqrqKJs uWmqJ6WKHVW1CRSMkcplrmMiyKtlktRQRQ2YGw1W9440tGifyeXiOtq6qozTKswrJZkkqpBTc57Q QVNNUyNSKRYItJURsaV7gqjNSykWR2Glr4DRm4ZyZoBGmZUYm5C6IWJAq6VFP9gspuJaZGvop5tQ h3WJ4F8GFKfLSMm11JDv91Hsa5cq5vJTMiy0xFJzQIp4xIfHI0IaXxSxhAjFwVjL7fhSB3enxyj+ xUYpbQ0mO00JgAmGIGPaF2Me2ZjQV3PEa07RmWPlljKIJ+cg1B1C+K43U2Bvv0xk4W7FQTsaFHiz fJYpozFPFHPEeqSIsiH/ACuCP2YNPsAeVXdty0ktHDNTEm59nqZYl39F1lFHwCgfDE8I/ZNIzUfd 5oB76VFR8JquaRfqodVP1FsJQSFxRe8myGKBBHTwxQR/mxosa/MhQLn4nfF68FJHvwDJgAmAAJ9p 3dfgraiSrSdqedkVQojRqe4Z2Ziq6JNcjMCzB+ouQ19uPL6VZHadE0L/AMcd2zMxIYko/ax7PpLQ SRiP+0mC71T05JMbIGVQSpVrmxQtwS9NkT1sK0aZ+7Nm1THBFLQCCoZdDNPPHyhyUVVmd6Y1dhJE ArIRrMiFrMJbrS9PkveiXG+w+9mHdIWAU0mZVKZhURPqI5NqcqFtHEwdi05iIUpLKCdlARQAMdsP TKLTfZSVDEY7CiYAJgA//9k= --001a11c2ffb88f69ad051fc18f1f-- From ghdwcnri@jfvm.com Tue Sep 15 00:23:16 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.8 required=5.0 tests=FREEMAIL_FROM, HK_RANDOM_ENVFROM,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 794057F37 for ; Tue, 15 Sep 2015 00:23:16 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 6820A8F8037 for ; Mon, 14 Sep 2015 22:23:13 -0700 (PDT) X-ASG-Debug-ID: 1442294589-04cb6c355df14d0001-NocioJ Received: from jfvm.com ([60.168.244.72]) by cuda.sgi.com with ESMTP id PsfU8CZFQ57yNCtf for ; Mon, 14 Sep 2015 22:23:10 -0700 (PDT) X-Barracuda-Envelope-From: ghdwcnri@jfvm.com X-Barracuda-Apparent-Source-IP: 60.168.244.72 Received: from SKY-20150201SFT ([127.0.0.1]) by localhost via TCP with ESMTPA; Tue, 15 Sep 2015 13:22:51 +0800 MIME-Version: 1.0 From: "Mr. Hua" Sender: "Mr. Hua" To: xfs@oss.sgi.com Reply-To: "Mr. Hua" Date: 15 Sep 2015 13:22:51 +0800 Subject: =?utf-8?B?TGFzdCB0ZWNobm9sb2d5IG9mIHNldCB0b3AgYm94IChpcHR2K3NhdCktTmV3c2xldHRlcg==?= Content-Type: text/html; charset=utf-8 X-ASG-Orig-Subj: =?utf-8?B?TGFzdCB0ZWNobm9sb2d5IG9mIHNldCB0b3AgYm94IChpcHR2K3NhdCktTmV3c2xldHRlcg==?= Content-Transfer-Encoding: base64 X-Barracuda-Connect: UNKNOWN[60.168.244.72] X-Barracuda-Start-Time: 1442294589 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.74 X-Barracuda-Spam-Status: No, SCORE=0.74 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC5_MJ1963, HTML_MESSAGE, MIME_HTML_ONLY, MISSING_MID, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22553 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 MISSING_MID Missing Message-Id: header 0.00 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 Message-Id: <20150915052313.23F331296080@cuda.sgi.com> PGh0bWw+PGJvZHk+PFA+PEJSPkhlbGxvLDxCUj5Hb29kIGRheSB0byB5b3UhPC9QPg0KPFA+ SGVyZSBhcmUgc2FsZXMgTXIuIGh1YSBhbmQgY29sbGVnIE1yLiBBbmR5IEZyb20gU2F0eHRy ZW0gdGVjaG5vbG9neSBmcm9tIHNoZW56aGVuLENoaW5hLiBPdXIgY29tcGFueSBpcyBhIHBy b2Zlc3Npb25hbCBTYXRlbGxpdGUgcmVjZWl2ZXIgbWFudWZhY3R1cmVyIHdpdGggbW9yZSB0 aGFuIDEyIHllYXIncyBleHBlcmllbmNlLiBXZWxsLWtub3duIFNhdHh0cmVtIFMxOCBpcyBv bmUgb2Ygb3VyIHByb2R1Y3QuIDwvUD4NCjxQPk91ciBtYWluIHByb2R1Y3RzIGluY2x1ZGVk IElQVFYgUzIgcmVjZWl2ZXLvvIxGVEEgU2F0IHJlY2VpdmVyICxhbmRyb2lkIFRWIEJPWCsg UGFpZCBJUFRWIGFuZCBJUFRWIEFjY291bnRzKG91ciBvd24gQVBLKyBzdHJlYW0pLCBTYXQg VFYgQ0NjYW0gYWNjb3VudCBlY3QuPC9QPg0KPFA+V2UgYWx3YXlzIG9mZmVyIHRoZSBnb29k IHF1YWxpdHkgcHJvZHVjdHMgd2l0aCB0aGUgbW9zdCByZWFzb25hYmxlIGFuZCBjb21wZXRp dGl2ZSBwcmljZSEgPC9QPg0KPFA+V2UgaGF2ZSBvdXIgb3duIHNvZnR3YXJlIGRlc2lnbmVy LCBCZXN0IEhENFUgaXMgb3VyIG93biBzb2Z0d2FyZSBpbnNpZGUsIHRoYXQgaXMgd2h5IHdl IGFibGUgZnVsbC1zaWRlcyB0byBvZmZlciBPRU0gb3JkZXIgYW5kIG1vZGlmeSB0aGUgUy9X IHdpbGwgYmUgbm8gcHJvYmxlbSAsIGV2ZW4gZnJvbSBTREsgbGV2ZWwuPC9QPg0KPFA+Rm9y IG1vcmUgaW5mb3JtYXRpb24sJm5ic3A7IHBsZWFzZSBmZWVsIGZyZWUgdG8gY29udGFjdCB1 cyBhbnkgdGltZSE8L1A+DQo8UD5XZSBhcmUgcmVhZHkgdG8gc2VydmUgZm9yIHlvdSB3aXRo IHN1cGVyIHByb2R1Y3QgYW5kIGZ1bGwgZWZmb3J0cyE8L1A+DQo8UD5Mb29raW5nIGZvcndh cmQgdG8geW91ciBwb3NpdGl2ZSByZXBseS48L1A+DQo8UD5UaGFuayB5b3UgYW5kIGJlc3Qg cmVnYXJkcywmbmJzcDsmbmJzcDsmbmJzcDsgPC9QPg0KPFA+TXIuIEh1YSZuYnNwOyA8QlI+ VGVsOiAwMDg2IDE4ODIzNzE4MDE4PEJSPlEgUTogMzk3NTk1NjQzPEJSPldlY2hhdDogZ3Bo dWE2NjwvUD4NCjxQPk1yLiBBbmR5IChBc3Npc3RhbnQgc2FsZXMpPEJSPlRlbDogMDA4NiAx NTgxODcwMjMwNzwvUD4NCjxQPjxCUj5BZGRyZXNzOiBSTTgyMSxIdWFmZW5nIHRlY2hub2xv Z3kgYW5kIHRyYWRlIEJ1aWxkaW5nLCBYaW4nYW4gNlJkLEJhb2FuLCBTaGVuemhlbiwgQ2hp bmEgNCBmbG9vcu+8jGJhb3RpYW4gaW5kdXN0cmlhbCBwYXJrLCBiYW90aWFuLGJhb2FuLCBz aGVuemhlbiAoZmFjdG9yeSk8L1A+DQo8UD48QlI+Jm5ic3A7PC9QPjwvYm9keT48L2h0bWw+ From pngfgnt@yyft.com Tue Sep 15 01:24:56 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.8 required=5.0 tests=FREEMAIL_FROM, HK_RANDOM_ENVFROM,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A712E7F37 for ; Tue, 15 Sep 2015 01:24:56 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 1E645AC002 for ; Mon, 14 Sep 2015 23:24:52 -0700 (PDT) X-ASG-Debug-ID: 1442298288-04cbb005ec10bb30001-NocioJ Received: from yyft.com ([114.97.98.103]) by cuda.sgi.com with ESMTP id cQ0eGl25BuZH6J9n for ; Mon, 14 Sep 2015 23:24:49 -0700 (PDT) X-Barracuda-Envelope-From: pngfgnt@yyft.com X-Barracuda-Apparent-Source-IP: 114.97.98.103 Received: from SKY-20150201SFT ([127.0.0.1]) by localhost via TCP with ESMTPA; Tue, 15 Sep 2015 14:24:40 +0800 MIME-Version: 1.0 From: "KT Team" Sender: "KT Team" To: xfs@oss.sgi.com Reply-To: "KT Team" Date: 15 Sep 2015 14:24:40 +0800 Subject: =?utf-8?B?UHJvZmVzc2lvbmFsIGluamVjdGlvbiBtb3VsZCBmYWN0b3J5IGluIENoaW5h?= Content-Type: text/html; charset=utf-8 X-ASG-Orig-Subj: =?utf-8?B?UHJvZmVzc2lvbmFsIGluamVjdGlvbiBtb3VsZCBmYWN0b3J5IGluIENoaW5h?= Content-Transfer-Encoding: base64 X-Barracuda-Connect: UNKNOWN[114.97.98.103] X-Barracuda-Start-Time: 1442298289 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.74 X-Barracuda-Spam-Status: No, SCORE=0.74 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC5_MJ1963, HTML_MESSAGE, MIME_HTML_ONLY, MISSING_MID, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22554 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 MISSING_MID Missing Message-Id: header 0.00 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 Message-Id: <20150915062452.3D09D106C09D@cuda.sgi.com> PGh0bWw+PGJvZHk+PFAgc3R5bGU9IlRFWFQtVFJBTlNGT1JNOiBub25lOyBCQUNLR1JPVU5E LUNPTE9SOiByZ2IoMjU1LDI1NSwyNTUpOyBURVhULUlOREVOVDogMHB4OyBNQVJHSU46IDBp biAwaW4gMHB0OyBGT05UOiAxMXB0IENhbGlicmksIHNhbnMtc2VyaWY7IFdISVRFLVNQQUNF OiBub3JtYWw7IExFVFRFUi1TUEFDSU5HOiBub3JtYWw7IENPTE9SOiByZ2IoMCwwLDApOyBX T1JELVNQQUNJTkc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4IiBjbGFz cz1Nc29QbGFpblRleHQ+SGVsbG8sPD94bWw6bmFtZXNwYWNlIHByZWZpeCA9IG8gLz48bzpw PjwvbzpwPjwvUD4NCjxQIHN0eWxlPSJURVhULVRSQU5TRk9STTogbm9uZTsgQkFDS0dST1VO RC1DT0xPUjogcmdiKDI1NSwyNTUsMjU1KTsgVEVYVC1JTkRFTlQ6IDBweDsgTUFSR0lOOiAw aW4gMGluIDBwdDsgRk9OVDogMTFwdCBDYWxpYnJpLCBzYW5zLXNlcmlmOyBXSElURS1TUEFD RTogbm9ybWFsOyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsg V09SRC1TUEFDSU5HOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCIgY2xh c3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KPFAgc3R5bGU9IlRFWFQt VFJBTlNGT1JNOiBub25lOyBCQUNLR1JPVU5ELUNPTE9SOiByZ2IoMjU1LDI1NSwyNTUpOyBU RVhULUlOREVOVDogMHB4OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05UOiAxMXB0IENhbGli cmksIHNhbnMtc2VyaWY7IFdISVRFLVNQQUNFOiBub3JtYWw7IExFVFRFUi1TUEFDSU5HOiBu b3JtYWw7IENPTE9SOiByZ2IoMCwwLDApOyBXT1JELVNQQUNJTkc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4IiBjbGFzcz1Nc29QbGFpblRleHQ+SXQncyBnbGFkIHRv IHdyaXRlIHRvIHlvdSB3aXRoIGtlZW4gaG9wZSB0byBlc3RhYmxpc2ggYSBidXNpbmVzcyBy ZWxhdGlvbnNoaXAgd2l0aCB5b3UuPG86cD48L286cD48L1A+DQo8UCBzdHlsZT0iVEVYVC1U UkFOU0ZPUk06IG5vbmU7IEJBQ0tHUk9VTkQtQ09MT1I6IHJnYigyNTUsMjU1LDI1NSk7IFRF WFQtSU5ERU5UOiAwcHg7IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQ6IDExcHQgQ2FsaWJy aSwgc2Fucy1zZXJpZjsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgTEVUVEVSLVNQQUNJTkc6IG5v cm1hbDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQtU1BBQ0lORzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHgiIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwv bzpwPjwvUD4NCjxQIHN0eWxlPSJURVhULVRSQU5TRk9STTogbm9uZTsgQkFDS0dST1VORC1D T0xPUjogcmdiKDI1NSwyNTUsMjU1KTsgVEVYVC1JTkRFTlQ6IDBweDsgTUFSR0lOOiAwaW4g MGluIDBwdDsgRk9OVDogMTFwdCBDYWxpYnJpLCBzYW5zLXNlcmlmOyBXSElURS1TUEFDRTog bm9ybWFsOyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsgV09S RC1TUEFDSU5HOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCIgY2xhc3M9 TXNvUGxhaW5UZXh0PldlIGFyZSBmcm9tIENoaW5lc2UgS2luZyBUZWNoIE1vdWxkIENvLixM aW1pdGVkLiBXZSBhcmU/YSByZWd1bGFyIG1hbnVmYWN0dXJlcnMgYW5kIGV4cG9ydHMgb2Yg dmFyaW91cyBraW5kcyBvZiBQbGFzdGljIG1vdWxkIGFuZCBwYXJ0cy48bzpwPjwvbzpwPjwv UD4NCjxQIHN0eWxlPSJURVhULVRSQU5TRk9STTogbm9uZTsgQkFDS0dST1VORC1DT0xPUjog cmdiKDI1NSwyNTUsMjU1KTsgVEVYVC1JTkRFTlQ6IDBweDsgTUFSR0lOOiAwaW4gMGluIDBw dDsgRk9OVDogMTFwdCBDYWxpYnJpLCBzYW5zLXNlcmlmOyBXSElURS1TUEFDRTogbm9ybWFs OyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsgV09SRC1TUEFD SU5HOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCIgY2xhc3M9TXNvUGxh aW5UZXh0PjEuIENvbGQgJmFtcDsgSG90IFJ1bm5lciAvIFNpbmdsZSAmYW1wOyBNdWx0aS1D YXZpdHktSW5qZWN0aW9uIG1vdWxkaW5nIDIuIFNpbmdsZSAmYW1wOyBNdXRpLVNob3QgMy4g RGllIENhc3QtQWx1bWludW0gJmFtcDsgWmluYyA0LiBJbnNlcnQgTW9sZHMgNS4gUHJvdG90 eXBlIFRvb2xpbmcgNi4gT3Zlcm1vbGRpbmcgNy4gTWFzcyBwcm9kdWN0aW9uPG86cD48L286 cD48L1A+DQo8UCBzdHlsZT0iVEVYVC1UUkFOU0ZPUk06IG5vbmU7IEJBQ0tHUk9VTkQtQ09M T1I6IHJnYigyNTUsMjU1LDI1NSk7IFRFWFQtSU5ERU5UOiAwcHg7IE1BUkdJTjogMGluIDBp biAwcHQ7IEZPTlQ6IDExcHQgQ2FsaWJyaSwgc2Fucy1zZXJpZjsgV0hJVEUtU1BBQ0U6IG5v cm1hbDsgTEVUVEVSLVNQQUNJTkc6IG5vcm1hbDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQt U1BBQ0lORzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHgiIGNsYXNzPU1z b1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCjxQIHN0eWxlPSJURVhULVRSQU5T Rk9STTogbm9uZTsgQkFDS0dST1VORC1DT0xPUjogcmdiKDI1NSwyNTUsMjU1KTsgVEVYVC1J TkRFTlQ6IDBweDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVDogMTFwdCBDYWxpYnJpLCBz YW5zLXNlcmlmOyBXSElURS1TUEFDRTogbm9ybWFsOyBMRVRURVItU1BBQ0lORzogbm9ybWFs OyBDT0xPUjogcmdiKDAsMCwwKTsgV09SRC1TUEFDSU5HOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweCIgY2xhc3M9TXNvUGxhaW5UZXh0PlBsZWFzZSBzZW5kIDNELzJE IGRyYXdpbmcgb3Igc2FtcGxlcyB0byB1cyBpZiB5b3UgaGF2ZSBhbnkgbmVlZHMsIHdlIHdp bGwgcXVvdGUgZm9yIGZyZWUgd2l0aCBhIHNvdW5kIHByaWNlLjxvOnA+PC9vOnA+PC9QPg0K PFAgc3R5bGU9IlRFWFQtVFJBTlNGT1JNOiBub25lOyBCQUNLR1JPVU5ELUNPTE9SOiByZ2Io MjU1LDI1NSwyNTUpOyBURVhULUlOREVOVDogMHB4OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBG T05UOiAxMXB0IENhbGlicmksIHNhbnMtc2VyaWY7IFdISVRFLVNQQUNFOiBub3JtYWw7IExF VFRFUi1TUEFDSU5HOiBub3JtYWw7IENPTE9SOiByZ2IoMCwwLDApOyBXT1JELVNQQUNJTkc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4IiBjbGFzcz1Nc29QbGFpblRl eHQ+PG86cD4mbmJzcDs8L286cD48L1A+DQo8UCBzdHlsZT0iVEVYVC1UUkFOU0ZPUk06IG5v bmU7IEJBQ0tHUk9VTkQtQ09MT1I6IHJnYigyNTUsMjU1LDI1NSk7IFRFWFQtSU5ERU5UOiAw cHg7IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQ6IDExcHQgQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgTEVUVEVSLVNQQUNJTkc6IG5vcm1hbDsgQ09MT1I6 IHJnYigwLDAsMCk7IFdPUkQtU1BBQ0lORzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHgiIGNsYXNzPU1zb1BsYWluVGV4dD5CZXN0IHdpc2hlcy48bzpwPjwvbzpwPjwv UD4NCjxQIHN0eWxlPSJURVhULVRSQU5TRk9STTogbm9uZTsgQkFDS0dST1VORC1DT0xPUjog cmdiKDI1NSwyNTUsMjU1KTsgVEVYVC1JTkRFTlQ6IDBweDsgTUFSR0lOOiAwaW4gMGluIDBw dDsgRk9OVDogMTFwdCBDYWxpYnJpLCBzYW5zLXNlcmlmOyBXSElURS1TUEFDRTogbm9ybWFs OyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsgV09SRC1TUEFD SU5HOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCIgY2xhc3M9TXNvUGxh aW5UZXh0PktUIFRlYW08bzpwPjwvbzpwPjwvUD4NCjxQIHN0eWxlPSJURVhULVRSQU5TRk9S TTogbm9uZTsgQkFDS0dST1VORC1DT0xPUjogcmdiKDI1NSwyNTUsMjU1KTsgVEVYVC1JTkRF TlQ6IDBweDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVDogMTFwdCBDYWxpYnJpLCBzYW5z LXNlcmlmOyBXSElURS1TUEFDRTogbm9ybWFsOyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBD T0xPUjogcmdiKDAsMCwwKTsgV09SRC1TUEFDSU5HOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweCIgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9Q Pg0KPFAgc3R5bGU9IlRFWFQtVFJBTlNGT1JNOiBub25lOyBCQUNLR1JPVU5ELUNPTE9SOiBy Z2IoMjU1LDI1NSwyNTUpOyBURVhULUlOREVOVDogMHB4OyBNQVJHSU46IDBpbiAwaW4gMHB0 OyBGT05UOiAxMXB0IENhbGlicmksIHNhbnMtc2VyaWY7IFdISVRFLVNQQUNFOiBub3JtYWw7 IExFVFRFUi1TUEFDSU5HOiBub3JtYWw7IENPTE9SOiByZ2IoMCwwLDApOyBXT1JELVNQQUNJ Tkc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4IiBjbGFzcz1Nc29QbGFp blRleHQ+S2luZyBUZWNoIE1vdWxkIENvLixMaW1pdGVkJm5ic3A7PG86cD48L286cD48L1A+ DQo8UCBzdHlsZT0iVEVYVC1UUkFOU0ZPUk06IG5vbmU7IEJBQ0tHUk9VTkQtQ09MT1I6IHJn YigyNTUsMjU1LDI1NSk7IFRFWFQtSU5ERU5UOiAwcHg7IE1BUkdJTjogMGluIDBpbiAwcHQ7 IEZPTlQ6IDExcHQgQ2FsaWJyaSwgc2Fucy1zZXJpZjsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsg TEVUVEVSLVNQQUNJTkc6IG5vcm1hbDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQtU1BBQ0lO RzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHgiIGNsYXNzPU1zb1BsYWlu VGV4dD5Sb29tNzAyLCAxc3QgQmxkZy4sIEZhbnRhc2lhIE1pYyBQbGF6YSwgTmFuSGFpIFJv YWQsIFNoZWtvdSBTdHJlZXQsJm5ic3A7Jm5ic3A7Jm5ic3A7IE5hbnNoYW4gRGlzdHJpY3Qs IFNoZW56aGVuIENpdHksIEd1YW5nZG9uZyBQcm92aW5jZSwgQ2hpbmEmbmJzcDs8bzpwPjwv bzpwPjwvUD4NCjxQIHN0eWxlPSJURVhULVRSQU5TRk9STTogbm9uZTsgQkFDS0dST1VORC1D T0xPUjogcmdiKDI1NSwyNTUsMjU1KTsgVEVYVC1JTkRFTlQ6IDBweDsgTUFSR0lOOiAwaW4g MGluIDBwdDsgRk9OVDogMTFwdCBDYWxpYnJpLCBzYW5zLXNlcmlmOyBXSElURS1TUEFDRTog bm9ybWFsOyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsgV09S RC1TUEFDSU5HOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCIgY2xhc3M9 TXNvUGxhaW5UZXh0PlppcCBDb2RlOiA1MTgwNjc8bzpwPjwvbzpwPjwvUD4NCjxQIHN0eWxl PSJURVhULVRSQU5TRk9STTogbm9uZTsgQkFDS0dST1VORC1DT0xPUjogcmdiKDI1NSwyNTUs MjU1KTsgVEVYVC1JTkRFTlQ6IDBweDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVDogMTFw dCBDYWxpYnJpLCBzYW5zLXNlcmlmOyBXSElURS1TUEFDRTogbm9ybWFsOyBMRVRURVItU1BB Q0lORzogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsgV09SRC1TUEFDSU5HOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCIgY2xhc3M9TXNvUGxhaW5UZXh0PlRlbC46 ICs4NiA3NTUgODYxOCAyNDEwJm5ic3A7Jm5ic3A7PG86cD48L286cD48L1A+DQo8UCBzdHls ZT0iVEVYVC1UUkFOU0ZPUk06IG5vbmU7IEJBQ0tHUk9VTkQtQ09MT1I6IHJnYigyNTUsMjU1 LDI1NSk7IFRFWFQtSU5ERU5UOiAwcHg7IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQ6IDEx cHQgQ2FsaWJyaSwgc2Fucy1zZXJpZjsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgTEVUVEVSLVNQ QUNJTkc6IG5vcm1hbDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQtU1BBQ0lORzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHgiIGNsYXNzPU1zb1BsYWluVGV4dD5GYXg6 ICs4NiA3NTUgODYxOCAyNzQwPC9QPjwvYm9keT48L2h0bWw+ From iustin@k1024.org Tue Sep 15 04:37:01 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id DEA227F37 for ; Tue, 15 Sep 2015 04:37:01 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id C1FC930404E for ; Tue, 15 Sep 2015 02:36:58 -0700 (PDT) X-ASG-Debug-ID: 1442309815-04bdf04db6111060001-NocioJ Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by cuda.sgi.com with ESMTP id sSClbvHYPuFIRFFh (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 15 Sep 2015 02:36:56 -0700 (PDT) X-Barracuda-Envelope-From: iustin@k1024.org X-Barracuda-Apparent-Source-IP: 209.85.212.170 Received: by wicgb1 with SMTP id gb1so19897580wic.1 for ; Tue, 15 Sep 2015 02:36:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=6zdYafy+Ze8hAsGQzzBiYPLs6PMQnLrjvp+tNHHylIE=; b=J53v6hPg2KPN5r7f09lu4Pxl4LqtxWt9aKKOTxDGYIJTJGGafnLb6txIwh3RF69Klx O6ea1hh+Zf2i+CywKh1zYQz1K6KeKBRhrjATWAYXAt8YWGWl6UtiXtGBeaf1+m1nlIwk FuzRFNhne26lQfwUxXCoaWrFVN2UrcHe2qd1mydUs/Z87ginKxDnteVtGmRGDSE7i8/K 9zQnASNm8CFB/4g47X3BEuIiHJnsBzXq0872ncdUBnBHVX1odlWHe9Z0mjA3z+WH8QwO /F0k7+fVrlV78nhnKIIL1cf05gQxNa1JD1aeQkBh7SCx/iV0VyKDKt2lJ6kQlUQt9Ork VgnA== X-Gm-Message-State: ALoCoQnKbzEw5qhtd7mNFTPQB1+PjmuaFrtxHJbI/e3z4TSJHvveVZw/GkS95qfZauAEBGiizQId X-Received: by 10.194.110.37 with SMTP id hx5mr38044816wjb.149.1442309815398; Tue, 15 Sep 2015 02:36:55 -0700 (PDT) Received: from teal.hq.k1024.org (178-83-234-80.dynamic.hispeed.ch. [178.83.234.80]) by smtp.gmail.com with ESMTPSA id kb5sm20046970wjc.17.2015.09.15.02.36.53 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Sep 2015 02:36:53 -0700 (PDT) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 3914B46FFB0; Tue, 15 Sep 2015 11:36:53 +0200 (CEST) Date: Tue, 15 Sep 2015 11:36:53 +0200 From: Iustin Pop To: xfs@oss.sgi.com Subject: Re: xfsrestore and multi-tape backups Message-ID: <20150915093653.GA31370@teal.hq.k1024.org> X-ASG-Orig-Subj: Re: xfsrestore and multi-tape backups Mail-Followup-To: xfs@oss.sgi.com References: <20150908144806.GA22811@teal.hq.k1024.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150908144806.GA22811@teal.hq.k1024.org> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.23 (2014-03-12) X-Barracuda-Connect: mail-wi0-f170.google.com[209.85.212.170] X-Barracuda-Start-Time: 1442309816 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22557 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 2015-09-08 16:48:06, Iustin Pop wrote: > Hi all, > > Sorry for the long email. I don't understand how xfsrestore is supposed > to work when restoring a dump spanning multiple tapes, maybe someone can > explain things to me. Anyone? A TL;DR version is: - restoring from tape 1 doesn't ask for the 2nd, reads finishes with "failed; end of file" but restore is SUCCESS - restoring from tape 2 asks for more tapes, inserting tape 1 continues the restore but at the end asks for more tapes So what's the correct way to restore a multi-tape dump? (Man page says to start with tape 1, but that doesn't seem to be working). thanks in advance, iustin From jtulak@redhat.com Tue Sep 15 04:59:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id DCCEE7F3F for ; Tue, 15 Sep 2015 04:59:40 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id CB19F30404E for ; Tue, 15 Sep 2015 02:59:40 -0700 (PDT) X-ASG-Debug-ID: 1442311178-04cbb005ea118fd0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 7ZRDwwlaAQdCIR9K (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:39 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id C3A6E8EA21 for ; Tue, 15 Sep 2015 09:59:38 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbm0008327; Tue, 15 Sep 2015 05:59:38 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 00/14 v5] xfsprogs: Partial OSX support Date: Tue, 15 Sep 2015 11:59:10 +0200 X-ASG-Orig-Subj: [PATCH 00/14 v5] xfsprogs: Partial OSX support Message-Id: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311179 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi all, An updated version. This set is intended to put together the current versions of the individual patches with the exception of a new patch 14, and rebase it against the current master branch. Patch 4 contains renaming required by Dave, however I'm not sure if it is still needed with the changes in patches 2 and 3. Patch 10 (adding timer) was mentioned that it "doesn't look to work", but I didn't get a reasoning. The added code, when tested, really run. For testing it in xfs_repair, I don't have how to create a large enough FS where the timer would be noticable on OSX. (Not enough of empty space.) Cheers, Jan CHANGELOG: v5: - patch 2 was split into 3 patches, numbered 2, 3 and 4 - in patches 2-4, instead of just prefixing it all, a mixed approach was used. - patch 9 renames the function directly instead of using #define - patch 11 now adds a simple rename - patch 12 uses mntinfo instead of dummy code - in patch 13, make mremap build optional instead of dummy code - new patch 14 with lstat64 v4: - added #warning message (patch 1) - use dummy blkid_get_topology instead of #ifdefs (patch 1) - fix autoconf (wasn't passing -DENABLE_BLKID flag, lost during patch cleaning.) (patch 1) - remove dependency on linux XATTR_ constants (patch 2) - add autoconf detection for fsetxattr (patch 4) - use uuid_t instead of unsigned char (patch 5) - add a basic timer functionality (patch 8) - mremap replacement now returns MAP_FAILED (patch 11) Version 3: - better commit messages (patch 1) - formatting fixes (patch 2, 8) - autoconf updates (patch 6, 7) - changed default behaviour if BLKID is disabled such that mkfs -f is required (patch 11) Jan Tulak (14): xfsprogs: Add a way to compile without blkid xfsprogs: Add XATTR_LIST_MAX to OS X headers xfsprogs: avoid dependency on Linux XATTR_SIZE_MAX xfsprogs: prefix XATTR_LIST_MAX with XFS_ xfsprogs: Add includes required for OS X builds (delta) xfsprogs: Add autoconf check for fsetxattr call xfsprogs: uuid changes for OS X xfsprogs: Remove conflicting define for OS X xfsprogs: change nftw64 to nftw xfsprogs: Add a timer implementation for OS X xfsprogs: Add statvfs64 for osx xfsprogs: make fsr use mntinfo when there is no mntent xfsprogs: Make mremap conditional xfsprogs: rename lstat64 to lstat for OS X configure.ac | 12 +++++- estimate/xfs_estimate.c | 6 +-- fsr/Makefile | 8 ++++ fsr/xfs_fsr.c | 85 ++++++++++++++++++++++++++++++++----- include/builddefs.in | 12 +++++- include/darwin.h | 106 ++++++++++++++++++++++++++++++++++++++++------- include/xfs.h | 2 + io/mmap.c | 8 ++++ libhandle/handle.c | 4 +- libhandle/jdm.c | 4 +- libxfs/xfs_attr_remote.c | 2 +- libxfs/xfs_format.h | 10 ++++- m4/package_libcdev.m4 | 26 ++++++++++++ mkfs/xfs_mkfs.c | 37 ++++++++++++++++- repair/progress.c | 16 ++++++- 15 files changed, 298 insertions(+), 40 deletions(-) -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:42 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id F1B5F7F54 for ; Tue, 15 Sep 2015 04:59:42 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id C54188F8037 for ; Tue, 15 Sep 2015 02:59:42 -0700 (PDT) X-ASG-Debug-ID: 1442311179-04bdf04db6112c30001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id N1Ux3hYEYa6gyP2H (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:39 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id A8F7E8E3E9 for ; Tue, 15 Sep 2015 09:59:39 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbm1008327; Tue, 15 Sep 2015 05:59:39 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 01/14] xfsprogs: Add a way to compile without blkid Date: Tue, 15 Sep 2015 11:59:11 +0200 X-ASG-Orig-Subj: [PATCH 01/14] xfsprogs: Add a way to compile without blkid Message-Id: <1442311164-12921-2-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311179 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Because not all platforms have up-to-date blkid with required functions, allow at least partial functionality by adding --enable-blkid=yes/no optional configure argument. When blkid is disabled, signature detection and device geometry detection doesn't work. Signed-off-by: Jan Tulak Reviewed-by: Christoph Hellwig --- configure.ac | 10 +++++++++- include/builddefs.in | 5 +++++ mkfs/xfs_mkfs.c | 37 ++++++++++++++++++++++++++++++++++++- 3 files changed, 50 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 16f3f68..aa241cd 100644 --- a/configure.ac +++ b/configure.ac @@ -26,6 +26,11 @@ AC_ARG_ENABLE(gettext, enable_gettext=yes) AC_SUBST(enable_gettext) +AC_ARG_ENABLE(blkid, +[ --enable-blkid=[yes/no] Enable use of block device id library [default=yes]],, + enable_blkid=yes) +AC_SUBST(enable_blkid) + AC_ARG_ENABLE(readline, [ --enable-readline=[yes/no] Enable readline command editing [default=no]], test $enable_readline = yes && libreadline="-lreadline", @@ -117,9 +122,12 @@ AC_HAVE_PREADV AC_HAVE_SYNC_FILE_RANGE AC_HAVE_MNTENT AC_HAVE_FLS -AC_HAVE_BLKID_TOPO AC_HAVE_READDIR +if test "$enable_blkid" = yes; then +AC_HAVE_BLKID_TOPO +fi + AC_CHECK_SIZEOF([long]) AC_CHECK_SIZEOF([char *]) AC_TYPE_UMODE_T diff --git a/include/builddefs.in b/include/builddefs.in index 8851956..6c16a65 100644 --- a/include/builddefs.in +++ b/include/builddefs.in @@ -89,6 +89,7 @@ ENABLE_SHARED = @enable_shared@ ENABLE_GETTEXT = @enable_gettext@ ENABLE_EDITLINE = @enable_editline@ ENABLE_READLINE = @enable_readline@ +ENABLE_BLKID = @enable_blkid@ HAVE_ZIPPED_MANPAGES = @have_zipped_manpages@ @@ -138,6 +139,10 @@ endif ifeq ($(HAVE_MNTENT),yes) PCFLAGS+= -DHAVE_MNTENT endif +ifeq ($(ENABLE_BLKID),yes) +PCFLAGS+= -DENABLE_BLKID +endif + GCFLAGS = $(OPTIMIZER) $(DEBUG) \ -DVERSION=\"$(PKG_VERSION)\" -DLOCALEDIR=\"$(PKG_LOCALE_DIR)\" \ diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c index d993fc0..5964eaf 100644 --- a/mkfs/xfs_mkfs.c +++ b/mkfs/xfs_mkfs.c @@ -18,7 +18,9 @@ #include "libxfs.h" #include -#include +#ifdef ENABLE_BLKID +# include +#endif /* ENABLE_BLKID */ #include "xfs_mkfs.h" /* @@ -298,6 +300,7 @@ calc_stripe_factors( * 0 for nothing found * -1 for internal error */ +#ifdef ENABLE_BLKID static int check_overwrite( char *device) @@ -451,6 +454,38 @@ out_free_probe: _("warning: unable to probe device topology for device %s\n"), device); } +#else /* ifdef ENABLE_BLKID */ +/* + * Without blkid, we can't do a good check for signatures. + * So instead of some messy attempts, just disable any checks + * and always return 'nothing found'. + */ +# warning BLKID is disabled, so signature detection and block device\ + access are not working! +static int +check_overwrite( + char *device) +{ + return 1; +} + +static void blkid_get_topology( + const char *device, + int *sunit, + int *swidth, + int *lsectorsize, + int *psectorsize, + int force_overwrite) +{ + /* + * Shouldn't make any difference (no blkid = no block device access), + * but make sure this dummy replacement returns with at least some + * sanity. + */ + *lsectorsize = *psectorsize = 512; +} + +#endif /* ENABLE_BLKID */ static void get_topology( libxfs_init_t *xi, -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 985B27F54 for ; Tue, 15 Sep 2015 04:59:43 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 244FFAC002 for ; Tue, 15 Sep 2015 02:59:43 -0700 (PDT) X-ASG-Debug-ID: 1442311181-04cbb005e9118fe0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id xEDfYqBP8rMAyrQd (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:41 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 74EBB40C4D for ; Tue, 15 Sep 2015 09:59:41 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbm3008327; Tue, 15 Sep 2015 05:59:40 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 03/14] xfsprogs: avoid dependency on Linux XATTR_SIZE_MAX Date: Tue, 15 Sep 2015 11:59:13 +0200 X-ASG-Orig-Subj: [PATCH 03/14] xfsprogs: avoid dependency on Linux XATTR_SIZE_MAX Message-Id: <1442311164-12921-4-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311181 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Currently, we depends on Linux XATTR value for on disk definitions. Which causes trouble on other platforms and maybe also if this value was to change. Fix it by creating a custom definition independent from those in Linux (although with the same values), so it is OK with the be16 fields used for holding these attributes. Signed-off-by: Jan Tulak --- libxfs/xfs_attr_remote.c | 2 +- libxfs/xfs_format.h | 10 +++++++++- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/libxfs/xfs_attr_remote.c b/libxfs/xfs_attr_remote.c index 3b3c24b..39ab350 100644 --- a/libxfs/xfs_attr_remote.c +++ b/libxfs/xfs_attr_remote.c @@ -102,7 +102,7 @@ xfs_attr3_rmt_verify( if (be32_to_cpu(rmt->rm_bytes) > fsbsize - sizeof(*rmt)) return false; if (be32_to_cpu(rmt->rm_offset) + - be32_to_cpu(rmt->rm_bytes) > XATTR_SIZE_MAX) + be32_to_cpu(rmt->rm_bytes) > XFS_XATTR_SIZE_MAX) return false; if (rmt->rm_owner == 0) return false; diff --git a/libxfs/xfs_format.h b/libxfs/xfs_format.h index 3c98635..946bcd1 100644 --- a/libxfs/xfs_format.h +++ b/libxfs/xfs_format.h @@ -60,6 +60,14 @@ struct xfs_ifork; #define XFS_SB_VERSION_MOREBITSBIT 0x8000 /* + * The size of a single extended attribute on disk is limited by + * the size of index values within the attribute entries themselves. + * These are be16 fields, so we can only support attribute data + * sizes up to 2^16 bytes in length. + */ +#define XFS_XATTR_SIZE_MAX (1 << 16) + +/* * Supported feature bit list is just all bits in the versionnum field because * we've used them all up and understand them all. Except, of course, for the * shared superblock bit, which nobody knows what it does and so is unsupported. @@ -1483,7 +1491,7 @@ struct xfs_acl { */ #define XFS_ACL_MAX_ENTRIES(mp) \ (xfs_sb_version_hascrc(&mp->m_sb) \ - ? (XATTR_SIZE_MAX - sizeof(struct xfs_acl)) / \ + ? (XFS_XATTR_SIZE_MAX - sizeof(struct xfs_acl)) / \ sizeof(struct xfs_acl_entry) \ : 25) -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:44 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 86FA57F54 for ; Tue, 15 Sep 2015 04:59:44 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 1B7DEAC001 for ; Tue, 15 Sep 2015 02:59:43 -0700 (PDT) X-ASG-Debug-ID: 1442311182-04bdf04db5112c50001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id d2B5QSxHTDij3GOr (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:42 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 5AAE2C0B2007 for ; Tue, 15 Sep 2015 09:59:42 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbm4008327; Tue, 15 Sep 2015 05:59:41 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 04/14] xfsprogs: prefix XATTR_LIST_MAX with XFS_ Date: Tue, 15 Sep 2015 11:59:14 +0200 X-ASG-Orig-Subj: [PATCH 04/14] xfsprogs: prefix XATTR_LIST_MAX with XFS_ Message-Id: <1442311164-12921-5-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311182 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 WILL CHANGE THE COMMIT MESSAGE. All right, I make the renaming with define - though I'm not sure that with the ifdef for OS X and SIZE_MAX moved to a standalone patch we need it - shouldn't be this change rather dropped? Signed-off-by: Jan Tulak --- include/xfs.h | 2 ++ libhandle/handle.c | 4 ++-- libhandle/jdm.c | 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/include/xfs.h b/include/xfs.h index bc94068..8ee0106 100644 --- a/include/xfs.h +++ b/include/xfs.h @@ -53,6 +53,8 @@ # define ASSERT(EX) ((void) 0) #endif +#define XFS_XATTR_LIST_MAX XATTR_LIST_MAX + /* * sparse kernel source annotations */ diff --git a/libhandle/handle.c b/libhandle/handle.c index b1c0c10..7207186 100644 --- a/libhandle/handle.c +++ b/libhandle/handle.c @@ -397,8 +397,8 @@ attr_list_by_handle( alhreq.buffer = buf; alhreq.buflen = bufsize; /* prevent needless EINVAL from the kernel */ - if (alhreq.buflen > XATTR_LIST_MAX) - alhreq.buflen = XATTR_LIST_MAX; + if (alhreq.buflen > XFS_XATTR_LIST_MAX) + alhreq.buflen = XFS_XATTR_LIST_MAX; error = xfsctl(path, fd, XFS_IOC_ATTRLIST_BY_HANDLE, &alhreq); diff --git a/libhandle/jdm.c b/libhandle/jdm.c index d804423..e52f5d8 100644 --- a/libhandle/jdm.c +++ b/libhandle/jdm.c @@ -168,8 +168,8 @@ jdm_attr_list( jdm_fshandle_t *fshp, int rval; /* prevent needless EINVAL from the kernel */ - if (bufsz > XATTR_LIST_MAX) - bufsz = XATTR_LIST_MAX; + if (bufsz > XFS_XATTR_LIST_MAX) + bufsz = XFS_XATTR_LIST_MAX; jdm_fill_filehandle( &filehandle, fshandlep, statp ); rval = attr_list_by_handle (( void * )&filehandle, -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:44 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id BFE827F5A for ; Tue, 15 Sep 2015 04:59:44 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id A0C59304048 for ; Tue, 15 Sep 2015 02:59:44 -0700 (PDT) X-ASG-Debug-ID: 1442311183-04bdf04db6112c60001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id dAzxC93VdvsigETi (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:43 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 4872BC0B9190 for ; Tue, 15 Sep 2015 09:59:43 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbm5008327; Tue, 15 Sep 2015 05:59:42 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 05/14] xfsprogs: Add includes required for OS X builds (delta) Date: Tue, 15 Sep 2015 11:59:15 +0200 X-ASG-Orig-Subj: [PATCH 05/14] xfsprogs: Add includes required for OS X builds (delta) Message-Id: <1442311164-12921-6-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311183 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Delta patch, an older version missing 3 includes was merged into 4.2.0-rc2. Signed-off-by: Jan Tulak Reviewed-by: Christoph Hellwig --- include/darwin.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/darwin.h b/include/darwin.h index 4b7ba3a..fe489a6 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -18,6 +18,9 @@ #ifndef __XFS_DARWIN_H__ #define __XFS_DARWIN_H__ +#include +#include +#include #include #include #include -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:45 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 82D747F5A for ; Tue, 15 Sep 2015 04:59:45 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 099E3AC002 for ; Tue, 15 Sep 2015 02:59:41 -0700 (PDT) X-ASG-Debug-ID: 1442311180-04cbb005eb118fe0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 8zHnW8q2Fu9ADjGQ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:41 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 8D8B28C1A3 for ; Tue, 15 Sep 2015 09:59:40 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbm2008327; Tue, 15 Sep 2015 05:59:39 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 02/14] xfsprogs: Add XATTR_LIST_MAX to OS X headers Date: Tue, 15 Sep 2015 11:59:12 +0200 X-ASG-Orig-Subj: [PATCH 02/14] xfsprogs: Add XATTR_LIST_MAX to OS X headers Message-Id: <1442311164-12921-3-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311180 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 OS X has no XATTR_LIST_MAX value. So add it to the platform header. Signed-off-by: Jan Tulak --- include/darwin.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/darwin.h b/include/darwin.h index b904898..4b7ba3a 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -39,6 +39,11 @@ # ifndef SYS_fsctl # define SYS_fsctl 242 # endif + +#ifndef XATTR_LIST_MAX +#define XATTR_LIST_MAX 65536 +#endif + static __inline__ int xfsctl(const char *path, int fd, int cmd, void *p) { return syscall(SYS_fsctl, path, cmd, p, 0); -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:46 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 72C677F5A for ; Tue, 15 Sep 2015 04:59:46 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id EFDA0AC002 for ; Tue, 15 Sep 2015 02:59:45 -0700 (PDT) X-ASG-Debug-ID: 1442311184-04cbb005ec118ff0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 7YvglK07Nrrw6FEQ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:44 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 4C9E0C0B2003 for ; Tue, 15 Sep 2015 09:59:44 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbm6008327; Tue, 15 Sep 2015 05:59:43 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 06/14] xfsprogs: Add autoconf check for fsetxattr call Date: Tue, 15 Sep 2015 11:59:16 +0200 X-ASG-Orig-Subj: [PATCH 06/14] xfsprogs: Add autoconf check for fsetxattr call Message-Id: <1442311164-12921-7-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311184 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 OS X has fsetxattr() in another header and with different arguments. For now, check for the Linux variant and if not available, skip the code using the call. Signed-off-by: Jan Tulak Reviewed-by: Christoph Hellwig --- configure.ac | 1 + fsr/xfs_fsr.c | 2 ++ include/builddefs.in | 4 ++++ m4/package_libcdev.m4 | 13 +++++++++++++ 4 files changed, 20 insertions(+) diff --git a/configure.ac b/configure.ac index aa241cd..5d8486e 100644 --- a/configure.ac +++ b/configure.ac @@ -123,6 +123,7 @@ AC_HAVE_SYNC_FILE_RANGE AC_HAVE_MNTENT AC_HAVE_FLS AC_HAVE_READDIR +AC_HAVE_FSETXATTR if test "$enable_blkid" = yes; then AC_HAVE_BLKID_TOPO diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c index b673761..e1b7bd6 100644 --- a/fsr/xfs_fsr.c +++ b/fsr/xfs_fsr.c @@ -1025,6 +1025,7 @@ fsr_setup_attr_fork( int tfd, xfs_bstat_t *bstatp) { +#ifdef HAVE_FSETXATTR struct stat64 tstatbuf; int i; int diff = 0; @@ -1199,6 +1200,7 @@ out: if (dflag && diff) fsrprintf(_("failed to match fork offset\n"));; +#endif /* HAVE_FSETXATTR */ return 0; } diff --git a/include/builddefs.in b/include/builddefs.in index 6c16a65..25b8816 100644 --- a/include/builddefs.in +++ b/include/builddefs.in @@ -106,6 +106,7 @@ HAVE_SYNC_FILE_RANGE = @have_sync_file_range@ HAVE_READDIR = @have_readdir@ HAVE_MNTENT = @have_mntent@ HAVE_FLS = @have_fls@ +HAVE_FSETXATTR = @have_fsetxattr@ GCCFLAGS = -funsigned-char -fno-strict-aliasing -Wall # -Wbitwise -Wno-transparent-union -Wno-old-initializer -Wno-decl @@ -139,6 +140,9 @@ endif ifeq ($(HAVE_MNTENT),yes) PCFLAGS+= -DHAVE_MNTENT endif +ifeq ($(HAVE_FSETXATTR),yes) +PCFLAGS+= -DHAVE_FSETXATTR +endif ifeq ($(ENABLE_BLKID),yes) PCFLAGS+= -DENABLE_BLKID endif diff --git a/m4/package_libcdev.m4 b/m4/package_libcdev.m4 index 4a96374..5e900ab 100644 --- a/m4/package_libcdev.m4 +++ b/m4/package_libcdev.m4 @@ -215,6 +215,19 @@ AC_DEFUN([AC_HAVE_FLS], ]) # +# Check if we have a fsetxattr call (Mac OS X) +# +AC_DEFUN([AC_HAVE_FSETXATTR], + [ AC_CHECK_DECL([fsetxattr], + have_fsetxattr=yes, + [], + [#include + #include ] + ) + AC_SUBST(have_fsetxattr) + ]) + +# # Check if there is mntent.h # AC_DEFUN([AC_HAVE_MNTENT], -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:47 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id BD3247F3F for ; Tue, 15 Sep 2015 04:59:47 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 9FE6C304048 for ; Tue, 15 Sep 2015 02:59:47 -0700 (PDT) X-ASG-Debug-ID: 1442311186-04cb6c355cffad0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id XiyWikxMquLMtPRB (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:46 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id E91443B3C7 for ; Tue, 15 Sep 2015 09:59:45 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbm7008327; Tue, 15 Sep 2015 05:59:44 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 07/14] xfsprogs: uuid changes for OS X Date: Tue, 15 Sep 2015 11:59:17 +0200 X-ASG-Orig-Subj: [PATCH 07/14] xfsprogs: uuid changes for OS X Message-Id: <1442311164-12921-8-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311186 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 UUID API changed in OS X in last few years, so fix the platform_ calls. Signed-off-by: Jan Tulak Reviewed-by: Christoph Hellwig --- include/darwin.h | 22 +++++++--------------- 1 file changed, 7 insertions(+), 15 deletions(-) diff --git a/include/darwin.h b/include/darwin.h index fe489a6..78f7df3 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -81,45 +81,37 @@ static __inline__ void platform_getoptreset(void) static __inline__ int platform_uuid_compare(uuid_t *uu1, uuid_t *uu2) { - return uuid_compare(uu1, uu2, NULL); + return uuid_compare(*uu1, *uu2); } static __inline__ void platform_uuid_unparse(uuid_t *uu, char *buffer) { - uint32_t status; - char *s; - uuid_to_string(uu, &s, &status); - if (status == uuid_s_ok) - strcpy(buffer, s); - else buffer[0] = '\0'; - free(s); + uuid_unparse(*uu, buffer); } static __inline__ int platform_uuid_parse(char *buffer, uuid_t *uu) { - uint32_t status; - uuid_from_string(buffer, uu, &status); - return (status == uuid_s_ok); + return uuid_parse(buffer, *uu); } static __inline__ int platform_uuid_is_null(uuid_t *uu) { - return uuid_is_nil(uu, NULL); + return uuid_is_null(*uu); } static __inline__ void platform_uuid_generate(uuid_t *uu) { - uuid_create(uu, NULL); + uuid_generate(*uu); } static __inline__ void platform_uuid_clear(uuid_t *uu) { - uuid_create_nil(uu, NULL); + uuid_clear(*uu); } static __inline__ void platform_uuid_copy(uuid_t *dst, uuid_t *src) { - memcpy(dst, src, sizeof(uuid_t)); + uuid_copy(*dst, *src); } typedef unsigned char __u8; -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 5B7027F72 for ; Tue, 15 Sep 2015 04:59:48 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 398CA8F8037 for ; Tue, 15 Sep 2015 02:59:48 -0700 (PDT) X-ASG-Debug-ID: 1442311186-04cbb005ec119000001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 7mDRTsd85B2MIWyD (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:47 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id CFA44A89 for ; Tue, 15 Sep 2015 09:59:46 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbm8008327; Tue, 15 Sep 2015 05:59:46 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 08/14] xfsprogs: Remove conflicting define for OS X Date: Tue, 15 Sep 2015 11:59:18 +0200 X-ASG-Orig-Subj: [PATCH 08/14] xfsprogs: Remove conflicting define for OS X Message-Id: <1442311164-12921-9-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311187 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 ENOATTR already exists in OS X. Signed-off-by: Jan Tulak Reviewed-by: Christoph Hellwig --- include/darwin.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/darwin.h b/include/darwin.h index 78f7df3..1409c91 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -156,7 +156,6 @@ typedef int64_t xfs_daddr_t; #define O_SYNC 0 #endif -#define ENOATTR 989 /* Attribute not found */ #define EFSCORRUPTED 990 /* Filesystem is corrupted */ #define EFSBADCRC 991 /* Bad CRC detected */ #define constpp char * const * -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:49 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 529BC7F55 for ; Tue, 15 Sep 2015 04:59:49 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 449A48F8040 for ; Tue, 15 Sep 2015 02:59:49 -0700 (PDT) X-ASG-Debug-ID: 1442311187-04cb6c355dffae0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id FcZcRWwusejCbART (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:48 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id AF9128EA29 for ; Tue, 15 Sep 2015 09:59:47 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbm9008327; Tue, 15 Sep 2015 05:59:47 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 09/14] xfsprogs: change nftw64 to nftw Date: Tue, 15 Sep 2015 11:59:19 +0200 X-ASG-Orig-Subj: [PATCH 09/14] xfsprogs: change nftw64 to nftw Message-Id: <1442311164-12921-10-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311188 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 There is only one usage of nftw64 in entire xfsprogs, but multiple usages of nftw. It seems the 64 variant has no reason, and causes difficulties with some other platforms which has only nftw call. Signed-off-by: Jan Tulak --- estimate/xfs_estimate.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/estimate/xfs_estimate.c b/estimate/xfs_estimate.c index 65b7168..323137c 100644 --- a/estimate/xfs_estimate.c +++ b/estimate/xfs_estimate.c @@ -45,7 +45,7 @@ cvtnum(char *s) return 0LL; } -int ffn(const char *, const struct stat64 *, int, struct FTW *); +int ffn(const char *, const struct stat *, int, struct FTW *); #define BLOCKSIZE 4096 #define INODESIZE 256 @@ -168,7 +168,7 @@ main(int argc, char **argv) ndirs=0LL; /* number of directories */ nspecial=0LL; /* number of special files */ - nftw64(argv[optind], ffn, 40, FTW_PHYS | FTW_MOUNT); + nftw(argv[optind], ffn, 40, FTW_PHYS | FTW_MOUNT); if (__debug) { printf(_("dirsize=%llu\n"), dirsize); @@ -214,7 +214,7 @@ main(int argc, char **argv) } int -ffn(const char *path, const struct stat64 *stb, int flags, struct FTW *f) +ffn(const char *path, const struct stat *stb, int flags, struct FTW *f) { /* cases are in most-encountered to least-encountered order */ dirsize+=PERDIRENTRY+strlen(path); -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:50 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 2F5F87F81 for ; Tue, 15 Sep 2015 04:59:50 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 0759F8F8037 for ; Tue, 15 Sep 2015 02:59:50 -0700 (PDT) X-ASG-Debug-ID: 1442311188-04cbb005e9119000001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id bgZgEnxptqGNZ9FH (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:49 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 957B640C4D for ; Tue, 15 Sep 2015 09:59:48 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbmA008327; Tue, 15 Sep 2015 05:59:47 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 10/14] xfsprogs: Add a timer implementation for OS X Date: Tue, 15 Sep 2015 11:59:20 +0200 X-ASG-Orig-Subj: [PATCH 10/14] xfsprogs: Add a timer implementation for OS X Message-Id: <1442311164-12921-11-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311188 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 OS X does not have the timer used in xfs_repair. Add a simple implementation providing the required capabilities. Signed-off-by: Jan Tulak --- include/darwin.h | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ repair/progress.c | 16 ++++++++++++++-- 2 files changed, 62 insertions(+), 2 deletions(-) diff --git a/include/darwin.h b/include/darwin.h index 1409c91..0d2f175 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include @@ -168,4 +169,51 @@ platform_discard_blocks(int fd, uint64_t start, uint64_t len) return 0; } +/* + * POSIX timer replacement. + * It really just do the minimum we need for xfs_repair. + * Also, as setitimer can't create multiple timers, + * the timerid things are useless - we have only one ITIMER_REAL + * timer. + */ +#define CLOCK_REALTIME ITIMER_REAL +#define itimerspec itimerval +typedef uint64_t timer_t; +typedef double timer_c; +typedef clock_id_t clockid_t; + + +static inline int timer_create (clockid_t __clock_id, + struct sigevent *__restrict __evp, + timer_t *__restrict timer) +{ + // set something, to initialize the variable, just in case + *timer = 0; + return 0; +} + +static inline int timer_settime (timer_t timerid, int flags, + const struct itimerspec *__restrict timerspec, + struct itimerspec *__restrict ovalue) +{ + return setitimer(ITIMER_REAL, timerspec, ovalue); +} + +static inline int timer_delete (timer_t timerid) +{ + struct itimerspec timespec; + + timespec.it_interval.tv_sec=0; + timespec.it_interval.tv_usec=0; + timespec.it_value.tv_sec=0; + timespec.it_value.tv_usec=0; + + return setitimer(ITIMER_REAL, ×pec, NULL); +} + +static inline int timer_gettime (timer_t timerid, struct itimerspec *value) +{ + return getitimer(ITIMER_REAL, value); +} + #endif /* __XFS_DARWIN_H__ */ diff --git a/repair/progress.c b/repair/progress.c index 27cbaef..0fee7dc 100644 --- a/repair/progress.c +++ b/repair/progress.c @@ -184,10 +184,22 @@ progress_rpt_thread (void *p) */ timespec.it_value.tv_sec = msgp->interval; - timespec.it_value.tv_nsec = 0; timespec.it_interval.tv_sec = msgp->interval; + /* + * On some platforms (like OS X), timers and time things are slightly + * different: itimerspec is replaced with itimerval and timeval struct + * has no tv_nsec, but just tv_usec member. + * For compatibility, itimerspec is a macro defined to the existing + * itimerval on these platforms, and in such case, use usec instead + * of nsec. + */ +#ifndef itimerspec + timespec.it_value.tv_nsec = 0; timespec.it_interval.tv_nsec = 0; - +#else + timespec.it_value.tv_usec = 0; + timespec.it_interval.tv_usec = 0; +#endif if (timer_create (CLOCK_REALTIME, NULL, &timerid)) do_error(_("progress_rpt: cannot create timer\n")); -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:52 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id C814E7F8D for ; Tue, 15 Sep 2015 04:59:52 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id AB60730404E for ; Tue, 15 Sep 2015 02:59:52 -0700 (PDT) X-ASG-Debug-ID: 1442311189-04bdf04db5112c80001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Yt8RHKzoCLsXG83p (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:49 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 7C0E3C0B91A1 for ; Tue, 15 Sep 2015 09:59:49 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbmB008327; Tue, 15 Sep 2015 05:59:48 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 11/14] xfsprogs: Add statvfs64 for osx Date: Tue, 15 Sep 2015 11:59:21 +0200 X-ASG-Orig-Subj: [PATCH 11/14] xfsprogs: Add statvfs64 for osx Message-Id: <1442311164-12921-12-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311189 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Simply rename statvfs64 to statfs with a #define. OSX version of statvfs is missing some members, so if the renaming is in effect (stavfs64 is defined), don't try to use them and go directly for the other member value. Signed-off-by: Jan Tulak --- fsr/xfs_fsr.c | 14 ++++++++++++++ include/builddefs.in | 2 +- include/darwin.h | 5 +++++ 3 files changed, 20 insertions(+), 1 deletion(-) diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c index e1b7bd6..5f95cdc 100644 --- a/fsr/xfs_fsr.c +++ b/fsr/xfs_fsr.c @@ -36,6 +36,12 @@ # include #endif +#ifdef __APPLE__ +//# define statvfs64 statfs; +# include +# include +#endif + #ifndef XFS_XFLAG_NODEFRAG #define XFS_XFLAG_NODEFRAG 0x00002000 /* src dependancy, remove later */ #endif @@ -948,7 +954,11 @@ fsrfile_common( fname, strerror(errno)); return -1; } +#ifndef statvfs64 bsize = vfss.f_frsize ? vfss.f_frsize : vfss.f_bsize; +#else + bsize = vfss.f_bsize; +#endif if (statp->bs_blksize * statp->bs_blocks > vfss.f_bfree * bsize - minimumfree) { fsrprintf(_("insufficient freespace for: %s: " @@ -1728,7 +1738,11 @@ xfs_getrt(int fd, struct statvfs64 *sfbp) close(fd); return -1; } +#ifndef statvfs64 bsize = (sfbp->f_frsize ? sfbp->f_frsize : sfbp->f_bsize); +#else + bsize = sfbp->f_bsize; +#endif factor = fsgeom.blocksize / bsize; /* currently this is == 1 */ sfbp->f_bfree = (cnt.freertx * fsgeom.rtextsize) * factor; return 0; diff --git a/include/builddefs.in b/include/builddefs.in index 25b8816..31e21ba 100644 --- a/include/builddefs.in +++ b/include/builddefs.in @@ -123,7 +123,7 @@ PCFLAGS = -D_GNU_SOURCE $(GCCFLAGS) endif ifeq ($(PKG_PLATFORM),darwin) PCFLAGS = $(GCCFLAGS) -DEPENDFLAGS = -D__APPLE__ +DEPENDFLAGS = -D__APPLE__ -D_DARWIN_FEATURE_64_BIT_INODE endif ifeq ($(PKG_PLATFORM),irix) PLDLIBS = -ldisk -lgen diff --git a/include/darwin.h b/include/darwin.h index 0d2f175..288ad1f 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -216,4 +216,9 @@ static inline int timer_gettime (timer_t timerid, struct itimerspec *value) return getitimer(ITIMER_REAL, value); } +/* FSR */ + +#define statvfs64 statfs +#define _PATH_MOUNTED "/etc/mtab" + #endif /* __XFS_DARWIN_H__ */ -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:53 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id F31537F90 for ; Tue, 15 Sep 2015 04:59:52 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 7DCD9AC002 for ; Tue, 15 Sep 2015 02:59:52 -0700 (PDT) X-ASG-Debug-ID: 1442311190-04cbb005ea119010001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id kncj3RlHR704h2BX (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:50 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 6883991C02 for ; Tue, 15 Sep 2015 09:59:50 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbmC008327; Tue, 15 Sep 2015 05:59:49 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 12/14] xfsprogs: make fsr use mntinfo when there is no mntent Date: Tue, 15 Sep 2015 11:59:22 +0200 X-ASG-Orig-Subj: [PATCH 12/14] xfsprogs: make fsr use mntinfo when there is no mntent Message-Id: <1442311164-12921-13-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311190 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 For what fsr needs, mntinfo can be used instead of mntent. Custom mntent struct is used to avoid too big ifdefs: We only change few lines and the rest of the code can still use mntent as before. Signed-off-by: Jan Tulak --- fsr/Makefile | 8 +++++++ fsr/xfs_fsr.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++-------- include/darwin.h | 20 ++++++++++++++++ 3 files changed, 87 insertions(+), 10 deletions(-) diff --git a/fsr/Makefile b/fsr/Makefile index a9d1bf6..d3521b2 100644 --- a/fsr/Makefile +++ b/fsr/Makefile @@ -9,6 +9,14 @@ LTCOMMAND = xfs_fsr CFILES = xfs_fsr.c LLDLIBS = $(LIBHANDLE) +ifeq ($(HAVE_GETMNTENT),yes) +LCFLAGS += -DHAVE_GETMNTENT +endif + +ifeq ($(HAVE_GETMNTINFO),yes) +LCFLAGS += -DHAVE_GETMNTINFO +endif + default: depend $(LTCOMMAND) include $(BUILDRULES) diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c index 5f95cdc..ff791d3 100644 --- a/fsr/xfs_fsr.c +++ b/fsr/xfs_fsr.c @@ -32,8 +32,10 @@ #include #include -#ifdef HAVE_MNTENT +#if defined(HAVE_GETMNTENT) # include +#elif defined(HAVE_GETMNTINFO) +# include #endif #ifdef __APPLE__ @@ -191,9 +193,10 @@ find_mountpoint(char *mtab, char *argname, struct stat64 *sb) { struct mntent *t; struct stat64 ms; - FILE *mtabp; char *mntp = NULL; +#if defined(HAVE_GETMNTENT) + FILE *mtabp; mtabp = setmntent(mtab, "r"); if (!mtabp) { fprintf(stderr, _("%s: cannot read %s\n"), @@ -202,6 +205,27 @@ find_mountpoint(char *mtab, char *argname, struct stat64 *sb) } while ((t = getmntent(mtabp))) { +#elif defined(HAVE_GETMNTINFO) + struct statfs *stats; + int error, i, count; + // because "t" is a pointer, but we don't need to use + // malloc for this usage + struct mntent t_tmp; + t = &t_tmp; + + + error = 0; + if ((count = getmntinfo(&stats, 0)) < 0) { + fprintf(stderr, _("%s: getmntinfo() failed: %s\n"), + progname, strerror(errno)); + return 0; + } + + for (i = 0; i < count; i++) { + mntinfo2mntent(&stats[i], t); +#else +# error "How do I extract info about mounted filesystems on this platform?" +#endif if (S_ISDIR(sb->st_mode)) { /* mount point */ if (stat64(t->mnt_dir, &ms) < 0) continue; @@ -233,10 +257,11 @@ find_mountpoint(char *mtab, char *argname, struct stat64 *sb) break; } +#if defined(HAVE_GETMNTENT) endmntent(mtabp); +#endif return mntp; } - int main(int argc, char **argv) { @@ -411,18 +436,11 @@ usage(int ret) static void initallfs(char *mtab) { - FILE *fp; struct mntent *mp; int mi; char *cp; struct stat64 sb; - fp = setmntent(mtab, "r"); - if (fp == NULL) { - fsrprintf(_("could not open mtab file: %s\n"), mtab); - exit(1); - } - /* malloc a number of descriptors, increased later if needed */ if (!(fsbase = (fsdesc_t *)malloc(fsbufsize * sizeof(fsdesc_t)))) { fsrprintf(_("out of memory: %s\n"), strerror(errno)); @@ -433,7 +451,36 @@ initallfs(char *mtab) /* find all rw xfs file systems */ mi = 0; fs = fsbase; + +#if defined(HAVE_GETMNTENT) + FILE *fp; + fp = setmntent(mtab, "r"); + if (fp == NULL) { + fsrprintf(_("could not open mtab file: %s\n"), mtab); + exit(1); + } + while ((mp = getmntent(fp))) { +#elif defined(HAVE_GETMNTINFO) + struct statfs *stats; + int error, i, count; + // because "t" is a pointer, but we don't need to use + // malloc for this usage + struct mntent mp_tmp; + mp = &mp_tmp; + error = 0; + if ((count = getmntinfo(&stats, 0)) < 0) { + fprintf(stderr, _("%s: getmntinfo() failed: %s\n"), + progname, strerror(errno)); + exit(1); + } + + for (i = 0; i < count; i++) { + mntinfo2mntent(&stats[i], mp); +#else +# error "How do I extract info about mounted filesystems on this platform?" +#endif + int rw = 0; if (strcmp(mp->mnt_type, MNTTYPE_XFS ) != 0 || @@ -485,7 +532,9 @@ initallfs(char *mtab) } numfs = mi; fsend = (fsbase + numfs); +#if defined(HAVE_GETMNTENT) endmntent(fp); +#endif if (numfs == 0) { fsrprintf(_("no rw xfs file systems in mtab: %s\n"), mtab); exit(0); diff --git a/include/darwin.h b/include/darwin.h index 288ad1f..0313f46 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -218,7 +218,27 @@ static inline int timer_gettime (timer_t timerid, struct itimerspec *value) /* FSR */ +# include +# include +#include +#include #define statvfs64 statfs #define _PATH_MOUNTED "/etc/mtab" +struct mntent +{ + char *mnt_fsname; + char *mnt_dir; + char *mnt_type; + char *mnt_opts; + int mnt_freq; + int mnt_passno; +}; + +static inline void mntinfo2mntent (struct statfs * stats, struct mntent * mnt) { + mnt->mnt_fsname = stats->f_mntfromname; + mnt->mnt_dir = stats->f_mntonname; + mnt->mnt_type = stats->f_fstypename; +} + #endif /* __XFS_DARWIN_H__ */ -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:53 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 536147F8D for ; Tue, 15 Sep 2015 04:59:53 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 2D3888F8049 for ; Tue, 15 Sep 2015 02:59:53 -0700 (PDT) X-ASG-Debug-ID: 1442311191-04cb6c355affaf0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id D2eiaMb9JVM4TwDo (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:51 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 5B885461D7 for ; Tue, 15 Sep 2015 09:59:51 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbmD008327; Tue, 15 Sep 2015 05:59:50 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 13/14] xfsprogs: Make mremap conditional Date: Tue, 15 Sep 2015 11:59:23 +0200 X-ASG-Orig-Subj: [PATCH 13/14] xfsprogs: Make mremap conditional Message-Id: <1442311164-12921-14-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311191 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Don't build mremap (in xfs_io) on platforms where it has no support. Signed-off-by: Jan Tulak --- configure.ac | 1 + include/builddefs.in | 1 + include/darwin.h | 1 + io/mmap.c | 8 ++++++++ m4/package_libcdev.m4 | 13 +++++++++++++ 5 files changed, 24 insertions(+) diff --git a/configure.ac b/configure.ac index 5d8486e..7cb87bc 100644 --- a/configure.ac +++ b/configure.ac @@ -124,6 +124,7 @@ AC_HAVE_MNTENT AC_HAVE_FLS AC_HAVE_READDIR AC_HAVE_FSETXATTR +AC_HAVE_MREMAP if test "$enable_blkid" = yes; then AC_HAVE_BLKID_TOPO diff --git a/include/builddefs.in b/include/builddefs.in index 31e21ba..c1797fd 100644 --- a/include/builddefs.in +++ b/include/builddefs.in @@ -107,6 +107,7 @@ HAVE_READDIR = @have_readdir@ HAVE_MNTENT = @have_mntent@ HAVE_FLS = @have_fls@ HAVE_FSETXATTR = @have_fsetxattr@ +HAVE_MREMAP = @have_mremap@ GCCFLAGS = -funsigned-char -fno-strict-aliasing -Wall # -Wbitwise -Wno-transparent-union -Wno-old-initializer -Wno-decl diff --git a/include/darwin.h b/include/darwin.h index 0313f46..16ead12 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -33,6 +33,7 @@ #include #include #include +#include #include #define __BYTE_ORDER BYTE_ORDER diff --git a/io/mmap.c b/io/mmap.c index f26276e..7093650 100644 --- a/io/mmap.c +++ b/io/mmap.c @@ -28,7 +28,9 @@ static cmdinfo_t mread_cmd; static cmdinfo_t msync_cmd; static cmdinfo_t munmap_cmd; static cmdinfo_t mwrite_cmd; +#ifdef HAVE_MREMAP static cmdinfo_t mremap_cmd; +#endif /* HAVE_MREMAP */ mmap_region_t *maptable; int mapcount; @@ -574,6 +576,7 @@ mwrite_f( return 0; } +#ifdef HAVE_MREMAP static void mremap_help(void) { @@ -633,6 +636,7 @@ mremap_f( return 0; } +#endif /* HAVE_MREMAP */ void mmap_init(void) @@ -688,6 +692,7 @@ mmap_init(void) _("writes data into a region in the current memory mapping"); mwrite_cmd.help = mwrite_help; +#ifdef HAVE_MREMAP mremap_cmd.name = "mremap"; mremap_cmd.altname = "mrm"; mremap_cmd.cfunc = mremap_f; @@ -698,11 +703,14 @@ mmap_init(void) mremap_cmd.oneline = _("alters the size of the current memory mapping"); mremap_cmd.help = mremap_help; +#endif /* HAVE_MREMAP */ add_command(&mmap_cmd); add_command(&mread_cmd); add_command(&msync_cmd); add_command(&munmap_cmd); add_command(&mwrite_cmd); +#ifdef HAVE_MREMAP add_command(&mremap_cmd); +#endif /* HAVE_MREMAP */ } diff --git a/m4/package_libcdev.m4 b/m4/package_libcdev.m4 index 5e900ab..b6a7a54 100644 --- a/m4/package_libcdev.m4 +++ b/m4/package_libcdev.m4 @@ -235,3 +235,16 @@ AC_DEFUN([AC_HAVE_MNTENT], have_mntent=yes) AC_SUBST(have_mntent) ]) + +# +# Check if we have a mremap call (not on Mac OS X) +# +AC_DEFUN([AC_HAVE_MREMAP], + [ AC_CHECK_DECL([mremap], + have_mremap=yes, + [], + [#define _GNU_SOURCE + #include ] + ) + AC_SUBST(have_mremap) + ]) -- 2.4.3 From jtulak@redhat.com Tue Sep 15 04:59:53 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id B7A257F8D for ; Tue, 15 Sep 2015 04:59:53 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id A9B88304051 for ; Tue, 15 Sep 2015 02:59:53 -0700 (PDT) X-ASG-Debug-ID: 1442311192-04cb6c355dffb00001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id iK0bl3OunDv9JRp6 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 02:59:52 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 3B7DC8E3E9 for ; Tue, 15 Sep 2015 09:59:52 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8F9xbmE008327; Tue, 15 Sep 2015 05:59:51 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: Jan Tulak Subject: [PATCH 14/14] xfsprogs: rename lstat64 to lstat for OS X Date: Tue, 15 Sep 2015 11:59:24 +0200 X-ASG-Orig-Subj: [PATCH 14/14] xfsprogs: rename lstat64 to lstat for OS X Message-Id: <1442311164-12921-15-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-1-git-send-email-jtulak@redhat.com> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442311192 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 OS X has a different means to distinguish between a 32 and 64bit calls - using xxx64 is deprecated. Signed-off-by: Jan Tulak --- include/darwin.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/darwin.h b/include/darwin.h index 16ead12..4ad2de1 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -224,6 +224,7 @@ static inline int timer_gettime (timer_t timerid, struct itimerspec *value) #include #include #define statvfs64 statfs +#define lstat64 lstat #define _PATH_MOUNTED "/etc/mtab" struct mntent -- 2.4.3 From bfoster@redhat.com Tue Sep 15 06:00:51 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id AC5E67F37 for ; Tue, 15 Sep 2015 06:00:51 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 9F742304048 for ; Tue, 15 Sep 2015 04:00:48 -0700 (PDT) X-ASG-Debug-ID: 1442314844-04cb6c355a104070001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id pjhfdMlmGrGyvXnl (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 04:00:47 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E60633B3C7; Tue, 15 Sep 2015 11:00:43 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8FB0h2F003621; Tue, 15 Sep 2015 07:00:43 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id B0A071201EB; Tue, 15 Sep 2015 07:00:42 -0400 (EDT) Date: Tue, 15 Sep 2015 07:00:42 -0400 From: Brian Foster To: Grant Keller Cc: xfs@oss.sgi.com Subject: Re: rm Tainted warning after kernel update. Message-ID: <20150915110042.GA21323@bfoster.bfoster> X-ASG-Orig-Subj: Re: rm Tainted warning after kernel update. References: <55F718A1.10801@sonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F718A1.10801@sonic.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442314847 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Mon, Sep 14, 2015 at 11:57:37AM -0700, Grant Keller wrote: > Hello, > > I have a server running Scientific Linux 6.7, and since updating to > kernel 2.6.32-573.3.1.el6.x86_64 the following error has begun appearing > in our message logs: > > Sep 14 11:43:03 localhost kernel: ------------[ cut here ]------------ > Sep 14 11:43:03 localhost kernel: WARNING: at fs/dcache.c:758 > d_delete+0x260/0x2c0() (Tainted: G W -- ------------ ) > Sep 14 11:43:03 localhost kernel: Hardware name: X7DB8 > Sep 14 11:43:03 localhost kernel: Modules linked in: nfsd nfs_acl > auth_rpcgss autofs4 lockd sunrpc p4_clockmod freq_table speedstep_lib > nf_conntrack_ftp iptable_mangle xt_comment nf_conntrack_ipv4 > nf_defrag_ipv4 xt_multiport iptable_filter ip_tables ip6t_REJECT > nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter > ip6_tables ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm > iw_cm ib_sa ib_mad ib_core ib_addr ipv6 xfs exportfs ppdev parport_pc > parport sg e1000e microcode serio_raw iTCO_wdt iTCO_vendor_support ixgbe > ptp pps_core mdio i2c_i801 lpc_ich mfd_core i5000_edac edac_core i5k_amb > ioatdma dca shpchp ext4 jbd2 mbcache sd_mod crc_t10dif 3w_9xxx pata_acpi > ata_generic ata_piix radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core > dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ipmi_msghandler] > Sep 14 11:43:03 localhost kernel: Pid: 15893, comm: rm Tainted: G > W -- ------------ 2.6.32-573.3.1.el6.x86_64 #1 > Sep 14 11:43:03 localhost kernel: Call Trace: > Sep 14 11:43:03 localhost kernel: [] ? > warn_slowpath_common+0x91/0xe0 > Sep 14 11:43:03 localhost kernel: [] ? > warn_slowpath_null+0x1a/0x20 > Sep 14 11:43:03 localhost kernel: [] ? > d_delete+0x260/0x2c0 > Sep 14 11:43:03 localhost kernel: [] ? vfs_rmdir+0xe8/0xf0 > Sep 14 11:43:03 localhost kernel: [] ? > do_rmdir+0x184/0x1f0 > Sep 14 11:43:03 localhost kernel: [] ? __fput+0x1a1/0x210 > Sep 14 11:43:03 localhost kernel: [] ? > audit_syscall_entry+0x1d7/0x200 > Sep 14 11:43:03 localhost kernel: [] ? > sys_unlinkat+0x2d/0x40 > Sep 14 11:43:03 localhost kernel: [] ? > system_call_fastpath+0x16/0x1b > Sep 14 11:43:03 localhost kernel: ---[ end trace 6080ec4a7ec5ec25 ]--- > > This happens when we are expiring older backups from the archives, so I > have quite a few of these. We have xfsprogs 3.1.1-16.el6.x86_64 > installed. Looking for advice on how to proceed. > This looks like something funky going on in the vfs. The warning is from unhash_offsprings() and it appears to be complaining about a refcount on a dentry that is a child of a directory being removed. It checks a refcount on a dentry in one loop and either drops it or moves it to another list for apparent deletion. The second iteration of the aforementioned list sees a refcount on an object that wasn't there before. I suspect this means something is going from 0->1 unexpectedly, but I'm not familiar enough with that code to grok why that shouldn't happen and how it could without reproducing it and digging into it from there. Have you identified an explicit reproducer? I assume files are simply being removed with 'rm -rf' here..? If so, does anything else have access to this directory structure (e.g., separate commands, a running backup application?) at the the time of removal? Also, what kernel were you running before this started to occur? Brian > -- > Grant Keller > System Operations > 707-237-2451 > grant.keller@sonic.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Tue Sep 15 06:14:32 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 1B8057F37 for ; Tue, 15 Sep 2015 06:14:32 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 5D3AEAC001 for ; Tue, 15 Sep 2015 04:14:28 -0700 (PDT) X-ASG-Debug-ID: 1442315666-04cbb005ea11f170001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id mBlkXBO8jROY3P1Q (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 04:14:26 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id E51AC8EA27; Tue, 15 Sep 2015 11:14:25 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8FBEP5S013673; Tue, 15 Sep 2015 07:14:25 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 734551201EB; Tue, 15 Sep 2015 07:14:20 -0400 (EDT) Date: Tue, 15 Sep 2015 07:14:20 -0400 From: Brian Foster To: "zhao.mingyue@h3c.com" Cc: "xfs@oss.sgi.com" , Xudonghai Subject: Re: umount hanging problem Message-ID: <20150915111420.GB21323@bfoster.bfoster> X-ASG-Orig-Subj: Re: umount hanging problem References: <1CB94550540AE44E9CAAE8CD5AF40BF846CEDB68@H3CMLB12-EX.srv.huawei-3com.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1CB94550540AE44E9CAAE8CD5AF40BF846CEDB68@H3CMLB12-EX.srv.huawei-3com.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442315666 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 15, 2015 at 02:59:53AM +0000, zhao.mingyue@h3c.com wrote: > Hi,everyone > > I have some question about XFS FILEsystem，can someone help me sovle my problem ？ > What kernel? > I built a Oracle database on a rbd block which had been created xfs filesystem ，then I removed the rbd block ，then the file directory of the oracle was broken and couldn’t be used，next，I recover the rbd block > > and umount the file directory of the oracle ，what happed next is the question which I was confused ，the process of the umount is hunging there and couldn’t be killed，how to solve the problem ？？ > It's waiting to flush everything out that was previously written to the log and sitting in the AIL list. It sounds like the filesystem shutdown because the underlying block device was torn down before the filesystem was unmounted, which is not the way to do things. ;) Recent kernels have had issues with extent freeing logging such that EFI/EFD objects are not reference counted correctly and can sit in the AIL and pin it indefinitely, particularly on races with fs shutdown. Fixes for (hopefully) most of these problems are pending in 4.3. For the time being you'll probably have to reboot to recover. Also note that this should never happen except due to some other crash, caused in this case by breaking down the block device before unmounting the fs. Brian > thanksï¼ > > > > > part of the log is as follows： > > Sep 11 10:22:29 localhost systemd: Started Fingerprint Authentication Daemon. > Sep 11 10:22:29 localhost fprintd: Launching FprintObject > Sep 11 10:22:29 localhost fprintd: ** Message: D-Bus service launched with name: net.reactivated.Fprint > Sep 11 10:22:29 localhost fprintd: ** Message: entering main loop > Sep 11 10:22:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:22:47 localhost systemd-logind: Removed session 1. > Sep 11 10:22:59 localhost fprintd: ** Message: No devices in use, exit > Sep 11 10:23:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:23:19 localhost systemd-logind: Removed session 136. > Sep 11 10:23:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:23:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > Sep 11 10:23:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Sep 11 10:23:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > Sep 11 10:23:44 localhost kernel: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8 > Sep 11 10:23:44 localhost kernel: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > Sep 11 10:23:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 > Sep 11 10:23:44 localhost kernel: Call Trace: > Sep 11 10:23:44 localhost kernel: [] schedule+0x29/0x70 > Sep 11 10:23:44 localhost kernel: [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] > Sep 11 10:23:44 localhost kernel: [] ? wake_up_bit+0x30/0x30 > Sep 11 10:23:44 localhost kernel: [] xfs_unmountfs+0x68/0x160 [xfs] > Sep 11 10:23:44 localhost kernel: [] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs] > Sep 11 10:23:44 localhost kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] > Sep 11 10:23:44 localhost kernel: [] generic_shutdown_super+0x56/0xe0 > Sep 11 10:23:44 localhost kernel: [] kill_block_super+0x27/0x70 > Sep 11 10:23:44 localhost kernel: [] deactivate_locked_super+0x3d/0x60 > Sep 11 10:23:44 localhost kernel: [] deactivate_super+0x46/0x60 > Sep 11 10:23:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 > Sep 11 10:23:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 > Sep 11 10:23:44 localhost kernel: [] system_call_fastpath+0x16/0x1b > Sep 11 10:23:57 localhost systemd-logind: Removed session 133. > Sep 11 10:24:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:24:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:25:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:25:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:25:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > Sep 11 10:25:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Sep 11 10:25:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > Sep 11 10:25:44 localhost kernel: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8 > Sep 11 10:25:44 localhost kernel: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > Sep 11 10:25:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 > Sep 11 10:25:44 localhost kernel: Call Trace: > Sep 11 10:25:44 localhost kernel: [] schedule+0x29/0x70 > Sep 11 10:25:44 localhost kernel: [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] > Sep 11 10:25:44 localhost kernel: [] ? wake_up_bit+0x30/0x30 > Sep 11 10:25:44 localhost kernel: [] xfs_unmountfs+0x68/0x160 [xfs] > Sep 11 10:25:44 localhost kernel: [] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs] > Sep 11 10:25:44 localhost kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] > Sep 11 10:25:44 localhost kernel: [] generic_shutdown_super+0x56/0xe0 > Sep 11 10:25:44 localhost kernel: [] kill_block_super+0x27/0x70 > Sep 11 10:25:44 localhost kernel: [] deactivate_locked_super+0x3d/0x60 > Sep 11 10:25:44 localhost kernel: [] deactivate_super+0x46/0x60 > Sep 11 10:25:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 > Sep 11 10:25:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 > Sep 11 10:25:44 localhost kernel: [] system_call_fastpath+0x16/0x1b > Sep 11 10:26:05 localhost systemd-logind: New session 138 of user root. > Sep 11 10:26:05 localhost systemd: Starting Session 138 of user root. > Sep 11 10:26:05 localhost systemd: Started Session 138 of user root. > Sep 11 10:26:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:26:29 localhost systemd-logind: New session 139 of user root. > Sep 11 10:26:29 localhost systemd: Starting Session 139 of user root. > Sep 11 10:26:29 localhost systemd: Started Session 139 of user root. > Sep 11 10:26:32 localhost systemd-logind: Removed session 139. > Sep 11 10:26:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:27:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:27:38 localhost goa[28775]: goa-daemon version 3.8.5 starting [main.c:113, main()] > Sep 11 10:27:38 localhost goa[28782]: GoaKerberosIdentityManager: Using polling for change notification for credential cache type 'KEYRING' [goakerberosidentitymanager.c:1394, monitor_credentials_cache()] > Sep 11 10:27:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:27:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > Sep 11 10:27:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Sep 11 10:27:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > Sep 11 10:27:44 localhost kernel: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8 > Sep 11 10:27:44 localhost kernel: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > Sep 11 10:27:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 > Sep 11 10:27:44 localhost kernel: Call Trace: > Sep 11 10:27:44 localhost kernel: [] schedule+0x29/0x70 > Sep 11 10:27:44 localhost kernel: [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] > Sep 11 10:27:44 localhost kernel: [] ? wake_up_bit+0x30/0x30 > Sep 11 10:27:44 localhost kernel: [] xfs_unmountfs+0x68/0x160 [xfs] > Sep 11 10:27:44 localhost kernel: [] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs] > Sep 11 10:27:44 localhost kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] > Sep 11 10:27:44 localhost kernel: [] generic_shutdown_super+0x56/0xe0 > Sep 11 10:27:44 localhost kernel: [] kill_block_super+0x27/0x70 > Sep 11 10:27:44 localhost kernel: [] deactivate_locked_super+0x3d/0x60 > Sep 11 10:27:44 localhost kernel: [] deactivate_super+0x46/0x60 > Sep 11 10:27:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 > Sep 11 10:27:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 > Sep 11 10:27:44 localhost kernel: [] system_call_fastpath+0x16/0x1b > Sep 11 10:28:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:28:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:29:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:29:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:29:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > Sep 11 10:29:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Sep 11 10:29:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > Sep 11 10:29:44 localhost kernel: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8 > Sep 11 10:29:44 localhost kernel: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > Sep 11 10:29:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 > Sep 11 10:29:44 localhost kernel: Call Trace: > Sep 11 10:29:44 localhost kernel: [] schedule+0x29/0x70 > Sep 11 10:29:44 localhost kernel: [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] > Sep 11 10:29:44 localhost kernel: [] ? wake_up_bit+0x30/0x30 > Sep 11 10:29:44 localhost kernel: [] xfs_unmountfs+0x68/0x160 [xfs] > Sep 11 10:29:44 localhost kernel: [] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs] > Sep 11 10:29:44 localhost kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] > Sep 11 10:29:44 localhost kernel: [] generic_shutdown_super+0x56/0xe0 > Sep 11 10:29:44 localhost kernel: [] kill_block_super+0x27/0x70 > Sep 11 10:29:44 localhost kernel: [] deactivate_locked_super+0x3d/0x60 > Sep 11 10:29:44 localhost kernel: [] deactivate_super+0x46/0x60 > Sep 11 10:29:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 > Sep 11 10:29:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 > Sep 11 10:29:44 localhost kernel: [] system_call_fastpath+0x16/0x1b > Sep 11 10:29:44 localhost kernel: INFO: task mount:28669 blocked for more than 120 seconds. > Sep 11 10:29:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Sep 11 10:29:44 localhost kernel: mount D ffff880703cf3680 0 28669 27990 0x00000084 > Sep 11 10:29:44 localhost kernel: ffff8806ca59fc48 0000000000000082 ffff880dea8771c0 ffff8806ca59ffd8 > Sep 11 10:29:44 localhost kernel: ffff8806ca59ffd8 ffff8806ca59ffd8 ffff880dea8771c0 ffff880dea8771c0 > Sep 11 10:29:44 localhost kernel: ffff880dec81f068 ffff880dec81f070 ffffffff00000000 ffff880dec81f078 > Sep 11 10:29:44 localhost kernel: Call Trace: > Sep 11 10:29:44 localhost kernel: [] schedule+0x29/0x70 > Sep 11 10:29:44 localhost kernel: [] rwsem_down_write_failed+0x115/0x220 > Sep 11 10:29:44 localhost kernel: [] ? __blkdev_get+0x221/0x4d0 > Sep 11 10:29:44 localhost kernel: [] ? set_bdev_super+0x40/0x40 > Sep 11 10:29:44 localhost kernel: [] call_rwsem_down_write_failed+0x13/0x20 > Sep 11 10:29:44 localhost kernel: [] ? down_write+0x2d/0x30 > Sep 11 10:29:44 localhost kernel: [] grab_super+0x2e/0xa0 > Sep 11 10:29:44 localhost kernel: [] sget+0x2a0/0x3d0 > Sep 11 10:29:44 localhost kernel: [] ? ns_test_super+0x20/0x20 > Sep 11 10:29:44 localhost kernel: [] mount_bdev+0xe2/0x1f0 > Sep 11 10:29:44 localhost kernel: [] ? xfs_parseargs+0xbf0/0xbf0 [xfs] > Sep 11 10:29:44 localhost kernel: [] ? ida_get_new_above+0x230/0x2a0 > Sep 11 10:29:44 localhost kernel: [] xfs_fs_mount+0x15/0x20 [xfs] > Sep 11 10:29:44 localhost kernel: [] mount_fs+0x39/0x1b0 > Sep 11 10:29:44 localhost kernel: [] ? __alloc_percpu+0x10/0x20 > Sep 11 10:29:44 localhost kernel: [] vfs_kern_mount+0x5f/0xf0 > Sep 11 10:29:44 localhost kernel: [] do_mount+0x24e/0xa40 > Sep 11 10:29:44 localhost kernel: [] ? strndup_user+0x4b/0xf0 > Sep 11 10:29:44 localhost kernel: [] SyS_mount+0x96/0xf0 > Sep 11 10:29:44 localhost kernel: [] system_call_fastpath+0x16/0x1b > Sep 11 10:30:01 localhost systemd: Starting Session 140 of user root. > Sep 11 10:30:01 localhost systemd: Started Session 140 of user root. > Sep 11 10:30:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:30:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:31:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:31:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:31:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > Sep 11 10:31:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Sep 11 10:31:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > Sep 11 10:31:44 localhost kernel: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8 > Sep 11 10:31:44 localhost kernel: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > Sep 11 10:31:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 > Sep 11 10:31:44 localhost kernel: Call Trace: > Sep 11 10:31:44 localhost kernel: [] schedule+0x29/0x70 > Sep 11 10:31:44 localhost kernel: [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] > Sep 11 10:31:44 localhost kernel: [] ? wake_up_bit+0x30/0x30 > Sep 11 10:31:44 localhost kernel: [] xfs_unmountfs+0x68/0x160 [xfs] > Sep 11 10:31:44 localhost kernel: [] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs] > Sep 11 10:31:44 localhost kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] > Sep 11 10:31:44 localhost kernel: [] generic_shutdown_super+0x56/0xe0 > Sep 11 10:31:44 localhost kernel: [] kill_block_super+0x27/0x70 > Sep 11 10:31:44 localhost kernel: [] deactivate_locked_super+0x3d/0x60 > Sep 11 10:31:44 localhost kernel: [] deactivate_super+0x46/0x60 > Sep 11 10:31:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 > Sep 11 10:31:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 > Sep 11 10:31:44 localhost kernel: [] system_call_fastpath+0x16/0x1b > Sep 11 10:32:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > ------------------------------------------------------------------------------------------------------------------------------------- > 本邮件åŠå…¶é™„件å«æœ‰æ­å·žåŽä¸‰é€šä¿¡æŠ€æœ¯æœ‰é™å…¬å¸çš„ä¿å¯†ä¿¡æ¯ï¼Œä»…é™äºŽå‘é€ç»™ä¸Šé¢åœ°å€ä¸­åˆ—出 > 的个人或群组。ç¦æ­¢ä»»ä½•å…¶ä»–人以任何形å¼ä½¿ç”¨ï¼ˆåŒ…括但ä¸é™äºŽå…¨éƒ¨æˆ–部分地泄露ã€å¤åˆ¶ã€ > 或散å‘）本邮件中的信æ¯ã€‚如果您错收了本邮件，请您立å³ç”µè¯æˆ–邮件通知å‘件人并删除本 > é‚®ä»¶ï¼ > This e-mail and its attachments contain confidential information from H3C, which is > intended only for the person or entity whose address is listed above. Any use of the > information contained herein in any way (including, but not limited to, total or partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender > by phone or email immediately and delete it! > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Tue Sep 15 06:20:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 404E87F37 for ; Tue, 15 Sep 2015 06:20:48 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id C8D8CAC002 for ; Tue, 15 Sep 2015 04:20:44 -0700 (PDT) X-ASG-Debug-ID: 1442316043-04bdf04db6118c50001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id nxyBCHhQ2IuiA08e (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 04:20:43 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 4D5588E696; Tue, 15 Sep 2015 11:20:30 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8FBKLeZ016216; Tue, 15 Sep 2015 07:20:22 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 734551201EB; Tue, 15 Sep 2015 07:14:20 -0400 (EDT) Date: Tue, 15 Sep 2015 07:14:20 -0400 From: Brian Foster To: "zhao.mingyue@h3c.com" Cc: "xfs@oss.sgi.com" , Xudonghai Subject: Re: umount hanging problem Message-ID: <20150915111420.GB21323@bfoster.bfoster> X-ASG-Orig-Subj: Re: umount hanging problem References: <1CB94550540AE44E9CAAE8CD5AF40BF846CEDB68@H3CMLB12-EX.srv.huawei-3com.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1CB94550540AE44E9CAAE8CD5AF40BF846CEDB68@H3CMLB12-EX.srv.huawei-3com.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442316043 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 15, 2015 at 02:59:53AM +0000, zhao.mingyue@h3c.com wrote: > Hi,everyone > > I have some question about XFS FILEsystem，can someone help me sovle my problem ？ > What kernel? > I built a Oracle database on a rbd block which had been created xfs filesystem ，then I removed the rbd block ，then the file directory of the oracle was broken and couldn’t be used，next，I recover the rbd block > > and umount the file directory of the oracle ，what happed next is the question which I was confused ，the process of the umount is hunging there and couldn’t be killed，how to solve the problem ？？ > It's waiting to flush everything out that was previously written to the log and sitting in the AIL list. It sounds like the filesystem shutdown because the underlying block device was torn down before the filesystem was unmounted, which is not the way to do things. ;) Recent kernels have had issues with extent freeing logging such that EFI/EFD objects are not reference counted correctly and can sit in the AIL and pin it indefinitely, particularly on races with fs shutdown. Fixes for (hopefully) most of these problems are pending in 4.3. For the time being you'll probably have to reboot to recover. Also note that this should never happen except due to some other crash, caused in this case by breaking down the block device before unmounting the fs. Brian > thanksï¼ > > > > > part of the log is as follows： > > Sep 11 10:22:29 localhost systemd: Started Fingerprint Authentication Daemon. > Sep 11 10:22:29 localhost fprintd: Launching FprintObject > Sep 11 10:22:29 localhost fprintd: ** Message: D-Bus service launched with name: net.reactivated.Fprint > Sep 11 10:22:29 localhost fprintd: ** Message: entering main loop > Sep 11 10:22:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:22:47 localhost systemd-logind: Removed session 1. > Sep 11 10:22:59 localhost fprintd: ** Message: No devices in use, exit > Sep 11 10:23:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:23:19 localhost systemd-logind: Removed session 136. > Sep 11 10:23:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:23:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > Sep 11 10:23:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Sep 11 10:23:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > Sep 11 10:23:44 localhost kernel: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8 > Sep 11 10:23:44 localhost kernel: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > Sep 11 10:23:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 > Sep 11 10:23:44 localhost kernel: Call Trace: > Sep 11 10:23:44 localhost kernel: [] schedule+0x29/0x70 > Sep 11 10:23:44 localhost kernel: [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] > Sep 11 10:23:44 localhost kernel: [] ? wake_up_bit+0x30/0x30 > Sep 11 10:23:44 localhost kernel: [] xfs_unmountfs+0x68/0x160 [xfs] > Sep 11 10:23:44 localhost kernel: [] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs] > Sep 11 10:23:44 localhost kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] > Sep 11 10:23:44 localhost kernel: [] generic_shutdown_super+0x56/0xe0 > Sep 11 10:23:44 localhost kernel: [] kill_block_super+0x27/0x70 > Sep 11 10:23:44 localhost kernel: [] deactivate_locked_super+0x3d/0x60 > Sep 11 10:23:44 localhost kernel: [] deactivate_super+0x46/0x60 > Sep 11 10:23:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 > Sep 11 10:23:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 > Sep 11 10:23:44 localhost kernel: [] system_call_fastpath+0x16/0x1b > Sep 11 10:23:57 localhost systemd-logind: Removed session 133. > Sep 11 10:24:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:24:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:25:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:25:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:25:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > Sep 11 10:25:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Sep 11 10:25:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > Sep 11 10:25:44 localhost kernel: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8 > Sep 11 10:25:44 localhost kernel: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > Sep 11 10:25:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 > Sep 11 10:25:44 localhost kernel: Call Trace: > Sep 11 10:25:44 localhost kernel: [] schedule+0x29/0x70 > Sep 11 10:25:44 localhost kernel: [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] > Sep 11 10:25:44 localhost kernel: [] ? wake_up_bit+0x30/0x30 > Sep 11 10:25:44 localhost kernel: [] xfs_unmountfs+0x68/0x160 [xfs] > Sep 11 10:25:44 localhost kernel: [] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs] > Sep 11 10:25:44 localhost kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] > Sep 11 10:25:44 localhost kernel: [] generic_shutdown_super+0x56/0xe0 > Sep 11 10:25:44 localhost kernel: [] kill_block_super+0x27/0x70 > Sep 11 10:25:44 localhost kernel: [] deactivate_locked_super+0x3d/0x60 > Sep 11 10:25:44 localhost kernel: [] deactivate_super+0x46/0x60 > Sep 11 10:25:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 > Sep 11 10:25:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 > Sep 11 10:25:44 localhost kernel: [] system_call_fastpath+0x16/0x1b > Sep 11 10:26:05 localhost systemd-logind: New session 138 of user root. > Sep 11 10:26:05 localhost systemd: Starting Session 138 of user root. > Sep 11 10:26:05 localhost systemd: Started Session 138 of user root. > Sep 11 10:26:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:26:29 localhost systemd-logind: New session 139 of user root. > Sep 11 10:26:29 localhost systemd: Starting Session 139 of user root. > Sep 11 10:26:29 localhost systemd: Started Session 139 of user root. > Sep 11 10:26:32 localhost systemd-logind: Removed session 139. > Sep 11 10:26:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:27:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:27:38 localhost goa[28775]: goa-daemon version 3.8.5 starting [main.c:113, main()] > Sep 11 10:27:38 localhost goa[28782]: GoaKerberosIdentityManager: Using polling for change notification for credential cache type 'KEYRING' [goakerberosidentitymanager.c:1394, monitor_credentials_cache()] > Sep 11 10:27:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:27:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > Sep 11 10:27:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Sep 11 10:27:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > Sep 11 10:27:44 localhost kernel: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8 > Sep 11 10:27:44 localhost kernel: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > Sep 11 10:27:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 > Sep 11 10:27:44 localhost kernel: Call Trace: > Sep 11 10:27:44 localhost kernel: [] schedule+0x29/0x70 > Sep 11 10:27:44 localhost kernel: [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] > Sep 11 10:27:44 localhost kernel: [] ? wake_up_bit+0x30/0x30 > Sep 11 10:27:44 localhost kernel: [] xfs_unmountfs+0x68/0x160 [xfs] > Sep 11 10:27:44 localhost kernel: [] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs] > Sep 11 10:27:44 localhost kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] > Sep 11 10:27:44 localhost kernel: [] generic_shutdown_super+0x56/0xe0 > Sep 11 10:27:44 localhost kernel: [] kill_block_super+0x27/0x70 > Sep 11 10:27:44 localhost kernel: [] deactivate_locked_super+0x3d/0x60 > Sep 11 10:27:44 localhost kernel: [] deactivate_super+0x46/0x60 > Sep 11 10:27:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 > Sep 11 10:27:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 > Sep 11 10:27:44 localhost kernel: [] system_call_fastpath+0x16/0x1b > Sep 11 10:28:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:28:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:29:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:29:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:29:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > Sep 11 10:29:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Sep 11 10:29:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > Sep 11 10:29:44 localhost kernel: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8 > Sep 11 10:29:44 localhost kernel: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > Sep 11 10:29:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 > Sep 11 10:29:44 localhost kernel: Call Trace: > Sep 11 10:29:44 localhost kernel: [] schedule+0x29/0x70 > Sep 11 10:29:44 localhost kernel: [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] > Sep 11 10:29:44 localhost kernel: [] ? wake_up_bit+0x30/0x30 > Sep 11 10:29:44 localhost kernel: [] xfs_unmountfs+0x68/0x160 [xfs] > Sep 11 10:29:44 localhost kernel: [] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs] > Sep 11 10:29:44 localhost kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] > Sep 11 10:29:44 localhost kernel: [] generic_shutdown_super+0x56/0xe0 > Sep 11 10:29:44 localhost kernel: [] kill_block_super+0x27/0x70 > Sep 11 10:29:44 localhost kernel: [] deactivate_locked_super+0x3d/0x60 > Sep 11 10:29:44 localhost kernel: [] deactivate_super+0x46/0x60 > Sep 11 10:29:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 > Sep 11 10:29:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 > Sep 11 10:29:44 localhost kernel: [] system_call_fastpath+0x16/0x1b > Sep 11 10:29:44 localhost kernel: INFO: task mount:28669 blocked for more than 120 seconds. > Sep 11 10:29:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Sep 11 10:29:44 localhost kernel: mount D ffff880703cf3680 0 28669 27990 0x00000084 > Sep 11 10:29:44 localhost kernel: ffff8806ca59fc48 0000000000000082 ffff880dea8771c0 ffff8806ca59ffd8 > Sep 11 10:29:44 localhost kernel: ffff8806ca59ffd8 ffff8806ca59ffd8 ffff880dea8771c0 ffff880dea8771c0 > Sep 11 10:29:44 localhost kernel: ffff880dec81f068 ffff880dec81f070 ffffffff00000000 ffff880dec81f078 > Sep 11 10:29:44 localhost kernel: Call Trace: > Sep 11 10:29:44 localhost kernel: [] schedule+0x29/0x70 > Sep 11 10:29:44 localhost kernel: [] rwsem_down_write_failed+0x115/0x220 > Sep 11 10:29:44 localhost kernel: [] ? __blkdev_get+0x221/0x4d0 > Sep 11 10:29:44 localhost kernel: [] ? set_bdev_super+0x40/0x40 > Sep 11 10:29:44 localhost kernel: [] call_rwsem_down_write_failed+0x13/0x20 > Sep 11 10:29:44 localhost kernel: [] ? down_write+0x2d/0x30 > Sep 11 10:29:44 localhost kernel: [] grab_super+0x2e/0xa0 > Sep 11 10:29:44 localhost kernel: [] sget+0x2a0/0x3d0 > Sep 11 10:29:44 localhost kernel: [] ? ns_test_super+0x20/0x20 > Sep 11 10:29:44 localhost kernel: [] mount_bdev+0xe2/0x1f0 > Sep 11 10:29:44 localhost kernel: [] ? xfs_parseargs+0xbf0/0xbf0 [xfs] > Sep 11 10:29:44 localhost kernel: [] ? ida_get_new_above+0x230/0x2a0 > Sep 11 10:29:44 localhost kernel: [] xfs_fs_mount+0x15/0x20 [xfs] > Sep 11 10:29:44 localhost kernel: [] mount_fs+0x39/0x1b0 > Sep 11 10:29:44 localhost kernel: [] ? __alloc_percpu+0x10/0x20 > Sep 11 10:29:44 localhost kernel: [] vfs_kern_mount+0x5f/0xf0 > Sep 11 10:29:44 localhost kernel: [] do_mount+0x24e/0xa40 > Sep 11 10:29:44 localhost kernel: [] ? strndup_user+0x4b/0xf0 > Sep 11 10:29:44 localhost kernel: [] SyS_mount+0x96/0xf0 > Sep 11 10:29:44 localhost kernel: [] system_call_fastpath+0x16/0x1b > Sep 11 10:30:01 localhost systemd: Starting Session 140 of user root. > Sep 11 10:30:01 localhost systemd: Started Session 140 of user root. > Sep 11 10:30:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:30:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:31:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:31:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > Sep 11 10:31:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > Sep 11 10:31:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Sep 11 10:31:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > Sep 11 10:31:44 localhost kernel: ffff880dd3247d90 0000000000000086 ffff8806f730db00 ffff880dd3247fd8 > Sep 11 10:31:44 localhost kernel: ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > Sep 11 10:31:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 > Sep 11 10:31:44 localhost kernel: Call Trace: > Sep 11 10:31:44 localhost kernel: [] schedule+0x29/0x70 > Sep 11 10:31:44 localhost kernel: [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] > Sep 11 10:31:44 localhost kernel: [] ? wake_up_bit+0x30/0x30 > Sep 11 10:31:44 localhost kernel: [] xfs_unmountfs+0x68/0x160 [xfs] > Sep 11 10:31:44 localhost kernel: [] ? xfs_mru_cache_destroy+0x6b/0x90 [xfs] > Sep 11 10:31:44 localhost kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] > Sep 11 10:31:44 localhost kernel: [] generic_shutdown_super+0x56/0xe0 > Sep 11 10:31:44 localhost kernel: [] kill_block_super+0x27/0x70 > Sep 11 10:31:44 localhost kernel: [] deactivate_locked_super+0x3d/0x60 > Sep 11 10:31:44 localhost kernel: [] deactivate_super+0x46/0x60 > Sep 11 10:31:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 > Sep 11 10:31:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 > Sep 11 10:31:44 localhost kernel: [] system_call_fastpath+0x16/0x1b > Sep 11 10:32:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > ------------------------------------------------------------------------------------------------------------------------------------- > 本邮件åŠå…¶é™„件å«æœ‰æ­å·žåŽä¸‰é€šä¿¡æŠ€æœ¯æœ‰é™å…¬å¸çš„ä¿å¯†ä¿¡æ¯ï¼Œä»…é™äºŽå‘é€ç»™ä¸Šé¢åœ°å€ä¸­åˆ—出 > 的个人或群组。ç¦æ­¢ä»»ä½•å…¶ä»–人以任何形å¼ä½¿ç”¨ï¼ˆåŒ…括但ä¸é™äºŽå…¨éƒ¨æˆ–部分地泄露ã€å¤åˆ¶ã€ > 或散å‘）本邮件中的信æ¯ã€‚如果您错收了本邮件，请您立å³ç”µè¯æˆ–邮件通知å‘件人并删除本 > é‚®ä»¶ï¼ > This e-mail and its attachments contain confidential information from H3C, which is > intended only for the person or entity whose address is listed above. Any use of the > information contained herein in any way (including, but not limited to, total or partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender > by phone or email immediately and delete it! > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Tue Sep 15 06:42:49 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id C43647F37 for ; Tue, 15 Sep 2015 06:42:48 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id B004830404E for ; Tue, 15 Sep 2015 04:42:48 -0700 (PDT) X-ASG-Debug-ID: 1442317367-04cbb005ec1215d0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id XoZEkMk1ZwziBgyN (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 04:42:47 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id CAE272ED154; Tue, 15 Sep 2015 11:42:46 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8FBgkuC025041; Tue, 15 Sep 2015 07:42:46 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 5234D1201EB; Tue, 15 Sep 2015 07:42:45 -0400 (EDT) Date: Tue, 15 Sep 2015 07:42:45 -0400 From: Brian Foster To: Zhaohongjiang Cc: david@fromorbit.com, hch@infradead.org, xfs@oss.sgi.com Subject: Re: [PATCH] cancel the setfilesize transation when io error happen Message-ID: <20150915114244.GC21323@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH] cancel the setfilesize transation when io error happen References: <55F0DF7A.7050404@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F0DF7A.7050404@huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442317367 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 10, 2015 at 09:40:10AM +0800, Zhaohongjiang wrote: > When I ran xfstest/073 case, the remount process was blocked to wait > transactions to be zero. I found there was a io error happened, and the > setfilesize transaction was not released properly. We should add the > changes to cancel the io error in this case. > Thanks for the patch. Was the io error by chance or part of the test? I ask because it would be good to have test coverage for this if we don't currently. > Reproduction steps: > 1. dd if=/dev/zero of=xfs1.img bs=1M count=2048 > 2. mkfs.xfs xfs1.img > 3. losetup -f ./xfs1.img /dev/loop0 > 4. mount -t xfs /dev/loop0 /home/test_dir/ > 5. mkdir /home/test_dir/test > 6. mkfs.xfs -dfile,name=image,size=2g > 7. mount -t xfs -o loop image /home/test_dir/test > 8. cp a file bigger than 2g to /home/test_dir/test > 9. mount -t xfs -o remount,ro /home/test_dir/test > > Signed-off-by: Zhao Hongjiang > --- > fs/xfs/xfs_aops.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c > index 50ab287..fab55da 100644 > --- a/fs/xfs/xfs_aops.c > +++ b/fs/xfs/xfs_aops.c > @@ -212,8 +212,21 @@ xfs_end_io( > ioend->io_error = -EIO; > goto done; > } > - if (ioend->io_error) > + if (ioend->io_error) { > + /* > + * We should cancel the setfilesize transation when io error > + * happen. > + */ > + if (ioend->io_append_trans) { > + current_set_flags_nested(&ioend->io_append_trans->t_pflags, > + PF_FSTRANS); > + rwsem_acquire_read(&VFS_I(XFS_I(ioend->io_inode))->i_sb > + ->s_writers.lock_map[SB_FREEZE_FS-1], 0, 1, _THIS_IP_); > + xfs_trans_cancel(ioend->io_append_trans); Trailing whitespace on the line above. That aside, I wonder if it would be cleaner to put this stuff in a helper similar to xfs_setfilesize_ioend(). In fact, we could probably just update xfs_setfilesize_ioend() to check ioend->io_error after fixing up the task flags and whatnot and cancel the transaction instead of calling xfs_setfilesize(). Then, call it here also and update the new comment to point out that it cancels the transaction on error. Thoughts? Brian > + } > + > goto done; > + } > > /* > * For unwritten extents we need to issue transactions to convert a > -- > 1.8.3.1 > -- > version="9" > logging="no" > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From robin.listas@gmail.com Tue Sep 15 07:13:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 54C677F37 for ; Tue, 15 Sep 2015 07:13:43 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id AF7C6AC00A for ; Tue, 15 Sep 2015 05:13:42 -0700 (PDT) X-ASG-Debug-ID: 1442319219-04cbb005ea123d60001-NocioJ Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by cuda.sgi.com with ESMTP id yzEPwpuGDefdgEB9 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 15 Sep 2015 05:13:40 -0700 (PDT) X-Barracuda-Envelope-From: robin.listas@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.212.179 Received: by wiclk2 with SMTP id lk2so25748523wic.0 for ; Tue, 15 Sep 2015 05:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=sXXhwGev/VX11iCLkcAisdHnfkEmanecm2vTSz/2pBw=; b=tSIvroAlsnSZnJdilZ936ZRMje+jjUGJKtBu4cMuQfMFFy+AbNXANbzeF00Az6k1xB KsWY3XWn7/g8gC8EXQdl3lQiRNEs0kqoYT0Wt0aPQCaOs5T5RGyFM5pxq96GpOxFEkaY o3eWIPStpCsimgXL3BGSqpjobfZBGpmSedIlyTT+19NhcvOD7XlB9Tp+O397J+OLfsDH 1aFgnpFGbzd667CGK6kBCLuarkpMPu0zc1sfETinnYo1WsZExceySzAyHN1Z9YKzCdgg LfzfpnLsOV0kdGozSYD0+wOxnW3kl3oQPf0iXmrI7MWrCp8NAdq9aJgXdnTQeIpaXIdQ t4EQ== X-Received: by 10.180.108.35 with SMTP id hh3mr6450554wib.48.1442319219356; Tue, 15 Sep 2015 05:13:39 -0700 (PDT) Received: from minas-tirith.valinor (3.Red-83-42-78.dynamicIP.rima-tde.net. [83.42.78.3]) by smtp.gmail.com with ESMTPSA id l17sm20798305wjr.18.2015.09.15.05.13.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Sep 2015 05:13:38 -0700 (PDT) Sender: Carlos Robinson Received: from minas-tirith.valinor (localhost [127.0.0.1]) by minas-tirith.valinor (Postfix) with ESMTP id 1EE87183EC1 for ; Tue, 15 Sep 2015 14:13:37 +0200 (CEST) Subject: Re: xfsrestore and multi-tape backups To: XFS mailing list X-ASG-Orig-Subj: Re: xfsrestore and multi-tape backups References: <20150908144806.GA22811@teal.hq.k1024.org> <20150915093653.GA31370@teal.hq.k1024.org> From: "Carlos E. R." Message-ID: <55F80B70.4090103@opensuse.org> Date: Tue, 15 Sep 2015 14:13:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150915093653.GA31370@teal.hq.k1024.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-wi0-f179.google.com[209.85.212.179] X-Barracuda-Start-Time: 1442319220 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22559 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-09-15 11:36, Iustin Pop wrote: > So what's the correct way to restore a multi-tape dump? (Man page > says to start with tape 1, but that doesn't seem to be working). I don't know about your case, so I maybe totally wrong. But it is possible that the catalog or index is stored on the last tape only, which might explain why starting with the second tape works (if I read correctly your post). - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlX4C3AACgkQja8UbcUWM1zclgD7BDYcqlZDq7CGDP2wMaOe/f8Z LRcM/QZVK7LBw92ptBAA/iI9mB8Y/hP7fxcESBe9FIrKxguAcsVq8tr9FJDq+hiM =Cf72 -----END PGP SIGNATURE----- From iustin@k1024.org Tue Sep 15 07:54:04 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id CA1EA7F37 for ; Tue, 15 Sep 2015 07:54:04 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 9B24830404E for ; Tue, 15 Sep 2015 05:54:01 -0700 (PDT) X-ASG-Debug-ID: 1442321637-04bdf04db5120090001-NocioJ Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by cuda.sgi.com with ESMTP id paiV3Moc4oJ4Muzo (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 15 Sep 2015 05:53:58 -0700 (PDT) X-Barracuda-Envelope-From: iustin@k1024.org X-Barracuda-Apparent-Source-IP: 209.85.212.174 Received: by wiclk2 with SMTP id lk2so25954125wic.1 for ; Tue, 15 Sep 2015 05:53:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=0ijeHiuyMz3Ii/7nWRc0iXaSn0xr3FCtzA9QoV9yuDg=; b=hSTyMU7XhRGoeSIKVoxQ+l3jp0Ye/ehIKV2EbXYQA4lqC4nL9nI6ZlH0CxOj7qCuXE sVfAorl4zJZ3OpYylWRwmcDBPdKlnXKHMgxI8yNCz9frSywHn5JtSICa5g+7AgJk9S1b oXU4rudJs7fXI1G2eOWJN/BIqOXNa+08aioabiz7Qs+I4dQlw8D5EgpFb54M3N4nRqmy 9wk4YAOfeISLqbYOaG1kGMk26GyNsBD+IOgfe2+UvLlOv4g3UJx3PKVu09uBWk3VbEvI HS8p63xL4zjwsVurLkJUNbxSsPyEEGoMwwKlBFa3ey+CbwsQj6tnW4ReGtd5sZebzUiB SMyQ== X-Gm-Message-State: ALoCoQln/z+8YpQHam4YG1sDy69masdXnaRLUc1XerNhKzzYiHmMOT8/XMngLG1UVEc/Ikqn2w5X X-Received: by 10.180.106.66 with SMTP id gs2mr7211479wib.14.1442321637013; Tue, 15 Sep 2015 05:53:57 -0700 (PDT) Received: from teal.hq.k1024.org (178-83-234-80.dynamic.hispeed.ch. [178.83.234.80]) by smtp.gmail.com with ESMTPSA id p20sm19801756wie.5.2015.09.15.05.53.55 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Sep 2015 05:53:56 -0700 (PDT) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 70E4D485C00; Tue, 15 Sep 2015 14:53:55 +0200 (CEST) Date: Tue, 15 Sep 2015 14:53:55 +0200 From: Iustin Pop To: "Carlos E. R." Cc: XFS mailing list Subject: Re: xfsrestore and multi-tape backups Message-ID: <20150915125355.GA28436@teal.hq.k1024.org> X-ASG-Orig-Subj: Re: xfsrestore and multi-tape backups Mail-Followup-To: "Carlos E. R." , XFS mailing list References: <20150908144806.GA22811@teal.hq.k1024.org> <20150915093653.GA31370@teal.hq.k1024.org> <55F80B70.4090103@opensuse.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline In-Reply-To: <55F80B70.4090103@opensuse.org> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.23 (2014-03-12) X-Barracuda-Connect: mail-wi0-f174.google.com[209.85.212.174] X-Barracuda-Start-Time: 1442321638 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22560 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2015-09-15 14:13:36, Carlos E. R. wrote: > On 2015-09-15 11:36, Iustin Pop wrote: > > So what's the correct way to restore a multi-tape dump? (Man page > > says to start with tape 1, but that doesn't seem to be working). >=20 > I don't know about your case, so I maybe totally wrong. But it is > possible that the catalog or index is stored on the last tape only, > which might explain why starting with the second tape works (if I read > correctly your post). I suspect as much myself - since if during the backup if you run out of tape writing a normal object, you can't write the index anymore. But then why does the man page recommend starting with the first tape? And why, when starting with the last tape, doesn't it know exactly which tapes are needed? If the man page is just wrong, I'll happily update it. Just want to get a confirmation from someone familiar with the code. thanks! iustin --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJV+BTjAAoJEPZuPkGfhPTedlQP/1qp/oGey1NO7bGT9AFG+zpV /53eBGPne2wRc+EOElszqalDZIiNYhH1pzyMD2xopHtB4TmSwGq/biVP7Vj1P/Vf X6xhvTNtAQxuM7GdpWxtxVc/lsQ9YX5fEXLHG8Vh/BuxflA8Y1mDIFfT+YD9+OX7 TeFlPiaOZh0PntFVLBFLhDs0gX3C6CnSX+Vm9m/I50p4rfRbR9IyvmW+/V0hQxPA a0hnC57H8JcdplmB/djDZIbNZTMgZ/nuwT3+Hx9GY2IVsqqSgHeORUoee8de7al+ 9qVHDo8B/mCQC5q383Sk6FNoRvHthOquMPbMrNJjo33/L2p6gOUTWep5VCLylB2m Qg9W6Gs+EsZMgn5CeUdph5HquRumf4ejThPxaG4lurjRWBIvXXALXh5DXwP32nbH 3WGRaJfsV4ZCy/ht9RItWmSIuC0YKYKSRCUTz2AlETBQZ4/rMeBXaCAoGEUaXCJT 3OUUPmY3EUi5pD29CB23iefp9ysD61mFZSt+14ixjm/psX70+FIiqSItI08yoifK j3X+CNUvkDJldiiugPLPJrZvh01SDWm2PlHhW1looAOWlKz4R4nXt5OctvfvSu2D Ll5aDUvA9OlnN1nHx0Ch5yobjnVOKH5t7MuncetHf/W6JlGDCCqwsTPFl2UjDWqP NetghZDmcp5dpdY/ty6N =8r/8 -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- From zhao.mingyue@h3c.com Tue Sep 15 07:59:28 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id AC17E7F3F for ; Tue, 15 Sep 2015 07:59:28 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 9DA348F8040 for ; Tue, 15 Sep 2015 05:59:25 -0700 (PDT) X-ASG-Debug-ID: 1442321957-04cb6c355d10d260001-NocioJ Received: from h3cmg01-ex.h3c.com (smtp.h3c.com [60.191.123.56]) by cuda.sgi.com with ESMTP id qLdkI06eyuMM0zkp for ; Tue, 15 Sep 2015 05:59:20 -0700 (PDT) X-Barracuda-Envelope-From: zhao.mingyue@h3c.com X-Barracuda-Apparent-Source-IP: 60.191.123.56 Received: from H3CHUB03-EX.srv.huawei-3com.com (unknown [10.63.20.169]) by h3cmg01-ex.h3c.com with smtp id 1a7c_0137_26706a71_eafc_45d4_814e_64381d7be6b1; Tue, 15 Sep 2015 20:58:48 +0800 Received: from H3CMLB12-EX.srv.huawei-3com.com ([fe80::f091:bd11:f0a9:5cbe]) by H3CHUB03-EX.srv.huawei-3com.com ([fe80::ec6c:67e6:67f8:ce53%15]) with mapi id 14.01.0355.002; Tue, 15 Sep 2015 20:58:42 +0800 From: "zhao.mingyue@h3c.com" To: Brian Foster CC: "xfs@oss.sgi.com" , Xudonghai Subject: =?utf-8?B?562U5aSNOiB1bW91bnQgaGFuZ2luZyBwcm9ibGVt?= Thread-Topic: umount hanging problem X-ASG-Orig-Subj: =?utf-8?B?562U5aSNOiB1bW91bnQgaGFuZ2luZyBwcm9ibGVt?= Thread-Index: AQHQ76e56DZNxKL5A02KFnsnnd0C4p49i9Gg Date: Tue, 15 Sep 2015 12:59:27 +0000 Message-ID: <1CB94550540AE44E9CAAE8CD5AF40BF846CEDD8C@H3CMLB12-EX.srv.huawei-3com.com> References: <1CB94550540AE44E9CAAE8CD5AF40BF846CEDB68@H3CMLB12-EX.srv.huawei-3com.com> <20150915111420.GB21323@bfoster.bfoster> In-Reply-To: <20150915111420.GB21323@bfoster.bfoster> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.70.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Barracuda-Connect: smtp.h3c.com[60.191.123.56] X-Barracuda-Start-Time: 1442321957 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.69 X-Barracuda-Spam-Status: No, SCORE=1.69 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MV0113c, HELO_DYNAMIC_DHCP, HELO_DYNAMIC_DHCP_2, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22560 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MV0113c BSF_SC0_MV0113c 1.66 HELO_DYNAMIC_DHCP_2 HELO_DYNAMIC_DHCP_2 SGkgQnJpYW4sDQogVGhhbmtzIGZvciB5b3VyIGV4cGxhaW5hdGlvbiENCg0Ka2VybmVsIHZlcnNp b27vvJozLjEwLjAtMjI5LmUxNy54ODYtNjQNCg0KIkZpeGVzIGZvciAoaG9wZWZ1bGx5KSBtb3N0 IG9mIHRoZXNlIHByb2JsZW1zIGFyZSBwZW5kaW5nIGluIDQuMyItLS0tTm93IDQuM3JjMSBoYXMg YWxyZWFkeSBmaXggdGhpcyBwcm9ibGVtPw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hk u7bkuro6IEJyaWFuIEZvc3RlciBbbWFpbHRvOmJmb3N0ZXJAcmVkaGF0LmNvbV0gDQrlj5HpgIHm l7bpl7Q6IDIwMTXlubQ55pyIMTXml6UgMTk6MTQNCuaUtuS7tuS6ujogemhhb21pbmd5dWUgMDk0 NDAgKFJEKQ0K5oqE6YCBOiB4ZnNAb3NzLnNnaS5jb207IHh1ZG9uZ2hhaSAxMTUwNyAoUkQpDQrk uLvpopg6IFJlOiB1bW91bnQgaGFuZ2luZyBwcm9ibGVtDQoNCk9uIFR1ZSwgU2VwIDE1LCAyMDE1 IGF0IDAyOjU5OjUzQU0gKzAwMDAsIHpoYW8ubWluZ3l1ZUBoM2MuY29tIHdyb3RlOg0KPiBIaSxl dmVyeW9uZQ0KPiANCj4gIEkgaGF2ZSBzb21lIHF1ZXN0aW9uIGFib3V0IFhGUyBGSUxFc3lzdGVt 77yMY2FuIHNvbWVvbmUgaGVscCBtZSBzb3ZsZSANCj4gbXkgcHJvYmxlbSDvvJ8NCj4gDQoNCldo YXQga2VybmVsPw0KDQo+ICBJIGJ1aWx0IGEgT3JhY2xlIGRhdGFiYXNlIG9uIGEgcmJkIGJsb2Nr IHdoaWNoIGhhZCBiZWVuIGNyZWF0ZWQgeGZzIA0KPiBmaWxlc3lzdGVtIO+8jHRoZW4gSSByZW1v dmVkIHRoZSByYmQgYmxvY2sg77yMdGhlbiB0aGUgZmlsZSBkaXJlY3Rvcnkgb2YgDQo+IHRoZSBv cmFjbGUgd2FzIGJyb2tlbiBhbmQgY291bGRu4oCZdCBiZSB1c2Vk77yMbmV4dO+8jEkgcmVjb3Zl ciB0aGUgcmJkIA0KPiBibG9jaw0KPiANCj4gYW5kIHVtb3VudCB0aGUgZmlsZSBkaXJlY3Rvcnkg b2YgdGhlIG9yYWNsZSDvvIx3aGF0IGhhcHBlZCBuZXh0IGlzIHRoZSANCj4gcXVlc3Rpb24gd2hp Y2ggSSB3YXMgY29uZnVzZWQg77yMdGhlIHByb2Nlc3Mgb2YgdGhlIHVtb3VudCBpcyBodW5naW5n IA0KPiB0aGVyZSBhbmQgY291bGRu4oCZdCBiZSBraWxsZWTvvIxob3cgdG8gc29sdmUgdGhlIHBy b2JsZW0g77yf77yfDQo+IA0KDQpJdCdzIHdhaXRpbmcgdG8gZmx1c2ggZXZlcnl0aGluZyBvdXQg dGhhdCB3YXMgcHJldmlvdXNseSB3cml0dGVuIHRvIHRoZSBsb2cgYW5kIHNpdHRpbmcgaW4gdGhl IEFJTCBsaXN0LiBJdCBzb3VuZHMgbGlrZSB0aGUgZmlsZXN5c3RlbSBzaHV0ZG93biBiZWNhdXNl IHRoZSB1bmRlcmx5aW5nIGJsb2NrIGRldmljZSB3YXMgdG9ybiBkb3duIGJlZm9yZSB0aGUgZmls ZXN5c3RlbSB3YXMgdW5tb3VudGVkLCB3aGljaCBpcyBub3QgdGhlIHdheSB0byBkbyB0aGluZ3Mu IDspIFJlY2VudCBrZXJuZWxzIGhhdmUgaGFkIGlzc3VlcyB3aXRoIGV4dGVudCBmcmVlaW5nIGxv Z2dpbmcgc3VjaCB0aGF0IEVGSS9FRkQgb2JqZWN0cyBhcmUgbm90IHJlZmVyZW5jZSBjb3VudGVk IGNvcnJlY3RseSBhbmQgY2FuIHNpdCBpbiB0aGUgQUlMIGFuZCBwaW4gaXQgaW5kZWZpbml0ZWx5 LCBwYXJ0aWN1bGFybHkgb24gcmFjZXMgd2l0aCBmcyBzaHV0ZG93bi4NCg0KRml4ZXMgZm9yICho b3BlZnVsbHkpIG1vc3Qgb2YgdGhlc2UgcHJvYmxlbXMgYXJlIHBlbmRpbmcgaW4gNC4zLiBGb3Ig dGhlIHRpbWUgYmVpbmcgeW91J2xsIHByb2JhYmx5IGhhdmUgdG8gcmVib290IHRvIHJlY292ZXIu IEFsc28gbm90ZSB0aGF0IHRoaXMgc2hvdWxkIG5ldmVyIGhhcHBlbiBleGNlcHQgZHVlIHRvIHNv bWUgb3RoZXIgY3Jhc2gsIGNhdXNlZCBpbiB0aGlzIGNhc2UgYnkgYnJlYWtpbmcgZG93biB0aGUg YmxvY2sgZGV2aWNlIGJlZm9yZSB1bm1vdW50aW5nIHRoZSBmcy4NCg0KQnJpYW4NCg0KPiB0aGFu a3PvvIENCj4gDQo+IA0KPiANCj4gDQo+IHBhcnQgb2YgdGhlIGxvZyBpcyBhcyBmb2xsb3dz77ya DQo+IA0KPiBTZXAgMTEgMTA6MjI6MjkgbG9jYWxob3N0IHN5c3RlbWQ6IFN0YXJ0ZWQgRmluZ2Vy cHJpbnQgQXV0aGVudGljYXRpb24gRGFlbW9uLg0KPiBTZXAgMTEgMTA6MjI6MjkgbG9jYWxob3N0 IGZwcmludGQ6IExhdW5jaGluZyBGcHJpbnRPYmplY3QgU2VwIDExIA0KPiAxMDoyMjoyOSBsb2Nh bGhvc3QgZnByaW50ZDogKiogTWVzc2FnZTogRC1CdXMgc2VydmljZSBsYXVuY2hlZCB3aXRoIA0K PiBuYW1lOiBuZXQucmVhY3RpdmF0ZWQuRnByaW50IFNlcCAxMSAxMDoyMjoyOSBsb2NhbGhvc3Qg ZnByaW50ZDogKiogDQo+IE1lc3NhZ2U6IGVudGVyaW5nIG1haW4gbG9vcCBTZXAgMTEgMTA6MjI6 MzkgbG9jYWxob3N0IGtlcm5lbDogWEZTIChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSBy ZXR1cm5lZC4NCj4gU2VwIDExIDEwOjIyOjQ3IGxvY2FsaG9zdCBzeXN0ZW1kLWxvZ2luZDogUmVt b3ZlZCBzZXNzaW9uIDEuDQo+IFNlcCAxMSAxMDoyMjo1OSBsb2NhbGhvc3QgZnByaW50ZDogKiog TWVzc2FnZTogTm8gZGV2aWNlcyBpbiB1c2UsIGV4aXQgDQo+IFNlcCAxMSAxMDoyMzowOSBsb2Nh bGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVk Lg0KPiBTZXAgMTEgMTA6MjM6MTkgbG9jYWxob3N0IHN5c3RlbWQtbG9naW5kOiBSZW1vdmVkIHNl c3Npb24gMTM2Lg0KPiBTZXAgMTEgMTA6MjM6MzkgbG9jYWxob3N0IGtlcm5lbDogWEZTIChkbS0y KTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NCj4gU2VwIDExIDEwOjIzOjQ0IGxv Y2FsaG9zdCBrZXJuZWw6IElORk86IHRhc2sgdW1vdW50OjI3OTUwIGJsb2NrZWQgZm9yIG1vcmUg dGhhbiAxMjAgc2Vjb25kcy4NCj4gU2VwIDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6ICJl Y2hvIDAgPiAvcHJvYy9zeXMva2VybmVsL2h1bmdfdGFza190aW1lb3V0X3NlY3MiIGRpc2FibGVz IHRoaXMgbWVzc2FnZS4NCj4gU2VwIDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IHVtb3Vu dCAgICAgICAgICBEIGZmZmY4ODBlMWZhZjM2ODAgICAgIDAgMjc5NTAgIDI3Nzc1IDB4MDAwMDAw ODQNCj4gU2VwIDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IGZmZmY4ODBkZDMyNDdkOTAg MDAwMDAwMDAwMDAwMDA4NiANCj4gZmZmZjg4MDZmNzMwZGIwMCBmZmZmODgwZGQzMjQ3ZmQ4IFNl cCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gZmZmZjg4MGRkMzI0N2ZkOCBmZmZm ODgwZGQzMjQ3ZmQ4IGZmZmY4ODA2ZjczMGRiMDAgZmZmZjg4MDZlN2NlYWU4MCANCj4gU2VwIDEx IDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IGZmZmY4ODA2Y2I4ODhiNDggZmZmZjg4MDZlN2Nl YWVjMCBmZmZmODgwNmU3Y2VhZWU4IGZmZmY4ODA2ZTdjZWFlOTAgU2VwIDExIDEwOjIzOjQ0IGxv Y2FsaG9zdCBrZXJuZWw6IENhbGwgVHJhY2U6DQo+IFNlcCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qg a2VybmVsOiBbPGZmZmZmZmZmODE2MDkyNTk+XSANCj4gc2NoZWR1bGUrMHgyOS8weDcwIFNlcCAx MSAxMDoyMzo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gWzxmZmZmZmZmZmEwMmYxYWMxPl0geGZz X2FpbF9wdXNoX2FsbF9zeW5jKzB4YzEvMHgxMTAgW3hmc10gU2VwIDExIA0KPiAxMDoyMzo0NCBs b2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODEwOTgyMzA+XSA/IA0KPiB3YWtlX3VwX2JpdCsw eDMwLzB4MzAgU2VwIDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiBbPGZmZmZmZmZm YTAyYTFjNDg+XSB4ZnNfdW5tb3VudGZzKzB4NjgvMHgxNjAgW3hmc10gU2VwIDExIDEwOjIzOjQ0 IA0KPiBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmYTAyYTI0ZWI+XSA/IA0KPiB4ZnNfbXJ1 X2NhY2hlX2Rlc3Ryb3krMHg2Yi8weDkwIFt4ZnNdIFNlcCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qg DQo+IGtlcm5lbDogWzxmZmZmZmZmZmEwMmEzNzAxPl0geGZzX2ZzX3B1dF9zdXBlcisweDIxLzB4 NjAgW3hmc10gU2VwIDExIA0KPiAxMDoyMzo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZm ODExYzg5MzY+XSANCj4gZ2VuZXJpY19zaHV0ZG93bl9zdXBlcisweDU2LzB4ZTAgU2VwIDExIDEw OjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiBbPGZmZmZmZmZmODExYzhjMTc+XSBraWxsX2Js b2NrX3N1cGVyKzB4MjcvMHg3MCBTZXAgMTEgMTA6MjM6NDQgDQo+IGxvY2FsaG9zdCBrZXJuZWw6 IFs8ZmZmZmZmZmY4MTFjOGY0ZD5dIA0KPiBkZWFjdGl2YXRlX2xvY2tlZF9zdXBlcisweDNkLzB4 NjAgU2VwIDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFjOTU1Nj5d IGRlYWN0aXZhdGVfc3VwZXIrMHg0Ni8weDYwIFNlcCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qga2Vy bmVsOiBbPGZmZmZmZmZmODExZTYyNjU+XSBtbnRwdXRfbm9fZXhwaXJlKzB4YzUvMHgxMjAgU2Vw IDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFlNzM5Zj5dIFN5U191 bW91bnQrMHg5Zi8weDNjMCBTZXAgMTEgMTA6MjM6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZm ZmZmZjgxNjEzZGE5Pl0gc3lzdGVtX2NhbGxfZmFzdHBhdGgrMHgxNi8weDFiIFNlcCAxMSAxMDoy Mzo1NyBsb2NhbGhvc3Qgc3lzdGVtZC1sb2dpbmQ6IFJlbW92ZWQgc2Vzc2lvbiAxMzMuDQo+IFNl cCAxMSAxMDoyNDowOSBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNl OiBlcnJvciA1IHJldHVybmVkLg0KPiBTZXAgMTEgMTA6MjQ6MzkgbG9jYWxob3N0IGtlcm5lbDog WEZTIChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NCj4gU2VwIDExIDEw OjI1OjA5IGxvY2FsaG9zdCBrZXJuZWw6IFhGUyAoZG0tMik6IHhmc19sb2dfZm9yY2U6IGVycm9y IDUgcmV0dXJuZWQuDQo+IFNlcCAxMSAxMDoyNTozOSBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRt LTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0KPiBTZXAgMTEgMTA6MjU6NDQg bG9jYWxob3N0IGtlcm5lbDogSU5GTzogdGFzayB1bW91bnQ6Mjc5NTAgYmxvY2tlZCBmb3IgbW9y ZSB0aGFuIDEyMCBzZWNvbmRzLg0KPiBTZXAgMTEgMTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDog ImVjaG8gMCA+IC9wcm9jL3N5cy9rZXJuZWwvaHVuZ190YXNrX3RpbWVvdXRfc2VjcyIgZGlzYWJs ZXMgdGhpcyBtZXNzYWdlLg0KPiBTZXAgMTEgMTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogdW1v dW50ICAgICAgICAgIEQgZmZmZjg4MGUxZmFmMzY4MCAgICAgMCAyNzk1MCAgMjc3NzUgMHgwMDAw MDA4NA0KPiBTZXAgMTEgMTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4MGRkMzI0N2Q5 MCAwMDAwMDAwMDAwMDAwMDg2IA0KPiBmZmZmODgwNmY3MzBkYjAwIGZmZmY4ODBkZDMyNDdmZDgg U2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiBmZmZmODgwZGQzMjQ3ZmQ4IGZm ZmY4ODBkZDMyNDdmZDggZmZmZjg4MDZmNzMwZGIwMCBmZmZmODgwNmU3Y2VhZTgwIA0KPiBTZXAg MTEgMTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4MDZjYjg4OGI0OCBmZmZmODgwNmU3 Y2VhZWMwIGZmZmY4ODA2ZTdjZWFlZTggZmZmZjg4MDZlN2NlYWU5MCBTZXAgMTEgMTA6MjU6NDQg bG9jYWxob3N0IGtlcm5lbDogQ2FsbCBUcmFjZToNCj4gU2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9z dCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTYwOTI1OT5dIA0KPiBzY2hlZHVsZSsweDI5LzB4NzAgU2Vw IDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiBbPGZmZmZmZmZmYTAyZjFhYzE+XSB4 ZnNfYWlsX3B1c2hfYWxsX3N5bmMrMHhjMS8weDExMCBbeGZzXSBTZXAgMTEgDQo+IDEwOjI1OjQ0 IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTA5ODIzMD5dID8gDQo+IHdha2VfdXBfYml0 KzB4MzAvMHgzMCBTZXAgMTEgMTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogDQo+IFs8ZmZmZmZm ZmZhMDJhMWM0OD5dIHhmc191bm1vdW50ZnMrMHg2OC8weDE2MCBbeGZzXSBTZXAgMTEgMTA6MjU6 NDQgDQo+IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmZhMDJhMjRlYj5dID8gDQo+IHhmc19t cnVfY2FjaGVfZGVzdHJveSsweDZiLzB4OTAgW3hmc10gU2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9z dCANCj4ga2VybmVsOiBbPGZmZmZmZmZmYTAyYTM3MDE+XSB4ZnNfZnNfcHV0X3N1cGVyKzB4MjEv MHg2MCBbeGZzXSBTZXAgMTEgDQo+IDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZm ZmY4MTFjODkzNj5dIA0KPiBnZW5lcmljX3NodXRkb3duX3N1cGVyKzB4NTYvMHhlMCBTZXAgMTEg MTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogDQo+IFs8ZmZmZmZmZmY4MTFjOGMxNz5dIGtpbGxf YmxvY2tfc3VwZXIrMHgyNy8weDcwIFNlcCAxMSAxMDoyNTo0NCANCj4gbG9jYWxob3N0IGtlcm5l bDogWzxmZmZmZmZmZjgxMWM4ZjRkPl0gDQo+IGRlYWN0aXZhdGVfbG9ja2VkX3N1cGVyKzB4M2Qv MHg2MCBTZXAgMTEgMTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM5NTU2 Pl0gZGVhY3RpdmF0ZV9zdXBlcisweDQ2LzB4NjAgU2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBr ZXJuZWw6IFs8ZmZmZmZmZmY4MTFlNjI2NT5dIG1udHB1dF9ub19leHBpcmUrMHhjNS8weDEyMCBT ZXAgMTEgMTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWU3MzlmPl0gU3lT X3Vtb3VudCsweDlmLzB4M2MwIFNlcCAxMSAxMDoyNTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZm ZmZmZmZmODE2MTNkYTk+XSBzeXN0ZW1fY2FsbF9mYXN0cGF0aCsweDE2LzB4MWIgU2VwIDExIDEw OjI2OjA1IGxvY2FsaG9zdCBzeXN0ZW1kLWxvZ2luZDogTmV3IHNlc3Npb24gMTM4IG9mIHVzZXIg cm9vdC4NCj4gU2VwIDExIDEwOjI2OjA1IGxvY2FsaG9zdCBzeXN0ZW1kOiBTdGFydGluZyBTZXNz aW9uIDEzOCBvZiB1c2VyIHJvb3QuDQo+IFNlcCAxMSAxMDoyNjowNSBsb2NhbGhvc3Qgc3lzdGVt ZDogU3RhcnRlZCBTZXNzaW9uIDEzOCBvZiB1c2VyIHJvb3QuDQo+IFNlcCAxMSAxMDoyNjowOSBs b2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVy bmVkLg0KPiBTZXAgMTEgMTA6MjY6MjkgbG9jYWxob3N0IHN5c3RlbWQtbG9naW5kOiBOZXcgc2Vz c2lvbiAxMzkgb2YgdXNlciByb290Lg0KPiBTZXAgMTEgMTA6MjY6MjkgbG9jYWxob3N0IHN5c3Rl bWQ6IFN0YXJ0aW5nIFNlc3Npb24gMTM5IG9mIHVzZXIgcm9vdC4NCj4gU2VwIDExIDEwOjI2OjI5 IGxvY2FsaG9zdCBzeXN0ZW1kOiBTdGFydGVkIFNlc3Npb24gMTM5IG9mIHVzZXIgcm9vdC4NCj4g U2VwIDExIDEwOjI2OjMyIGxvY2FsaG9zdCBzeXN0ZW1kLWxvZ2luZDogUmVtb3ZlZCBzZXNzaW9u IDEzOS4NCj4gU2VwIDExIDEwOjI2OjM5IGxvY2FsaG9zdCBrZXJuZWw6IFhGUyAoZG0tMik6IHhm c19sb2dfZm9yY2U6IGVycm9yIDUgcmV0dXJuZWQuDQo+IFNlcCAxMSAxMDoyNzowOSBsb2NhbGhv c3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0K PiBTZXAgMTEgMTA6Mjc6MzggbG9jYWxob3N0IGdvYVsyODc3NV06IGdvYS1kYWVtb24gdmVyc2lv biAzLjguNSANCj4gc3RhcnRpbmcgW21haW4uYzoxMTMsIG1haW4oKV0gU2VwIDExIDEwOjI3OjM4 IGxvY2FsaG9zdCBnb2FbMjg3ODJdOiANCj4gR29hS2VyYmVyb3NJZGVudGl0eU1hbmFnZXI6IFVz aW5nIHBvbGxpbmcgZm9yIGNoYW5nZSBub3RpZmljYXRpb24gZm9yIGNyZWRlbnRpYWwgY2FjaGUg dHlwZSAnS0VZUklORycgW2dvYWtlcmJlcm9zaWRlbnRpdHltYW5hZ2VyLmM6MTM5NCwgbW9uaXRv cl9jcmVkZW50aWFsc19jYWNoZSgpXSBTZXAgMTEgMTA6Mjc6NDAgbG9jYWxob3N0IGtlcm5lbDog WEZTIChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NCj4gU2VwIDExIDEw OjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IElORk86IHRhc2sgdW1vdW50OjI3OTUwIGJsb2NrZWQg Zm9yIG1vcmUgdGhhbiAxMjAgc2Vjb25kcy4NCj4gU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBr ZXJuZWw6ICJlY2hvIDAgPiAvcHJvYy9zeXMva2VybmVsL2h1bmdfdGFza190aW1lb3V0X3NlY3Mi IGRpc2FibGVzIHRoaXMgbWVzc2FnZS4NCj4gU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJu ZWw6IHVtb3VudCAgICAgICAgICBEIGZmZmY4ODBlMWZhZjM2ODAgICAgIDAgMjc5NTAgIDI3Nzc1 IDB4MDAwMDAwODQNCj4gU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IGZmZmY4ODBk ZDMyNDdkOTAgMDAwMDAwMDAwMDAwMDA4NiANCj4gZmZmZjg4MDZmNzMwZGIwMCBmZmZmODgwZGQz MjQ3ZmQ4IFNlcCAxMSAxMDoyNzo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gZmZmZjg4MGRkMzI0 N2ZkOCBmZmZmODgwZGQzMjQ3ZmQ4IGZmZmY4ODA2ZjczMGRiMDAgZmZmZjg4MDZlN2NlYWU4MCAN Cj4gU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IGZmZmY4ODA2Y2I4ODhiNDggZmZm Zjg4MDZlN2NlYWVjMCBmZmZmODgwNmU3Y2VhZWU4IGZmZmY4ODA2ZTdjZWFlOTAgU2VwIDExIDEw OjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IENhbGwgVHJhY2U6DQo+IFNlcCAxMSAxMDoyNzo0NCBs b2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODE2MDkyNTk+XSANCj4gc2NoZWR1bGUrMHgyOS8w eDcwIFNlcCAxMSAxMDoyNzo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gWzxmZmZmZmZmZmEwMmYx YWMxPl0geGZzX2FpbF9wdXNoX2FsbF9zeW5jKzB4YzEvMHgxMTAgW3hmc10gU2VwIDExIA0KPiAx MDoyNzo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODEwOTgyMzA+XSA/IA0KPiB3YWtl X3VwX2JpdCsweDMwLzB4MzAgU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiBb PGZmZmZmZmZmYTAyYTFjNDg+XSB4ZnNfdW5tb3VudGZzKzB4NjgvMHgxNjAgW3hmc10gU2VwIDEx IDEwOjI3OjQ0IA0KPiBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmYTAyYTI0ZWI+XSA/IA0K PiB4ZnNfbXJ1X2NhY2hlX2Rlc3Ryb3krMHg2Yi8weDkwIFt4ZnNdIFNlcCAxMSAxMDoyNzo0NCBs b2NhbGhvc3QgDQo+IGtlcm5lbDogWzxmZmZmZmZmZmEwMmEzNzAxPl0geGZzX2ZzX3B1dF9zdXBl cisweDIxLzB4NjAgW3hmc10gU2VwIDExIA0KPiAxMDoyNzo0NCBsb2NhbGhvc3Qga2VybmVsOiBb PGZmZmZmZmZmODExYzg5MzY+XSANCj4gZ2VuZXJpY19zaHV0ZG93bl9zdXBlcisweDU2LzB4ZTAg U2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiBbPGZmZmZmZmZmODExYzhjMTc+ XSBraWxsX2Jsb2NrX3N1cGVyKzB4MjcvMHg3MCBTZXAgMTEgMTA6Mjc6NDQgDQo+IGxvY2FsaG9z dCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFjOGY0ZD5dIA0KPiBkZWFjdGl2YXRlX2xvY2tlZF9zdXBl cisweDNkLzB4NjAgU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4 MTFjOTU1Nj5dIGRlYWN0aXZhdGVfc3VwZXIrMHg0Ni8weDYwIFNlcCAxMSAxMDoyNzo0NCBsb2Nh bGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExZTYyNjU+XSBtbnRwdXRfbm9fZXhwaXJlKzB4YzUv MHgxMjAgU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFlNzM5 Zj5dIFN5U191bW91bnQrMHg5Zi8weDNjMCBTZXAgMTEgMTA6Mjc6NDQgbG9jYWxob3N0IGtlcm5l bDogWzxmZmZmZmZmZjgxNjEzZGE5Pl0gc3lzdGVtX2NhbGxfZmFzdHBhdGgrMHgxNi8weDFiIFNl cCAxMSAxMDoyODoxMCBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNl OiBlcnJvciA1IHJldHVybmVkLg0KPiBTZXAgMTEgMTA6Mjg6NDAgbG9jYWxob3N0IGtlcm5lbDog WEZTIChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NCj4gU2VwIDExIDEw OjI5OjEwIGxvY2FsaG9zdCBrZXJuZWw6IFhGUyAoZG0tMik6IHhmc19sb2dfZm9yY2U6IGVycm9y IDUgcmV0dXJuZWQuDQo+IFNlcCAxMSAxMDoyOTo0MCBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRt LTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0KPiBTZXAgMTEgMTA6Mjk6NDQg bG9jYWxob3N0IGtlcm5lbDogSU5GTzogdGFzayB1bW91bnQ6Mjc5NTAgYmxvY2tlZCBmb3IgbW9y ZSB0aGFuIDEyMCBzZWNvbmRzLg0KPiBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDog ImVjaG8gMCA+IC9wcm9jL3N5cy9rZXJuZWwvaHVuZ190YXNrX3RpbWVvdXRfc2VjcyIgZGlzYWJs ZXMgdGhpcyBtZXNzYWdlLg0KPiBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogdW1v dW50ICAgICAgICAgIEQgZmZmZjg4MGUxZmFmMzY4MCAgICAgMCAyNzk1MCAgMjc3NzUgMHgwMDAw MDA4NA0KPiBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4MGRkMzI0N2Q5 MCAwMDAwMDAwMDAwMDAwMDg2IA0KPiBmZmZmODgwNmY3MzBkYjAwIGZmZmY4ODBkZDMyNDdmZDgg U2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiBmZmZmODgwZGQzMjQ3ZmQ4IGZm ZmY4ODBkZDMyNDdmZDggZmZmZjg4MDZmNzMwZGIwMCBmZmZmODgwNmU3Y2VhZTgwIA0KPiBTZXAg MTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4MDZjYjg4OGI0OCBmZmZmODgwNmU3 Y2VhZWMwIGZmZmY4ODA2ZTdjZWFlZTggZmZmZjg4MDZlN2NlYWU5MCBTZXAgMTEgMTA6Mjk6NDQg bG9jYWxob3N0IGtlcm5lbDogQ2FsbCBUcmFjZToNCj4gU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9z dCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTYwOTI1OT5dIA0KPiBzY2hlZHVsZSsweDI5LzB4NzAgU2Vw IDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiBbPGZmZmZmZmZmYTAyZjFhYzE+XSB4 ZnNfYWlsX3B1c2hfYWxsX3N5bmMrMHhjMS8weDExMCBbeGZzXSBTZXAgMTEgDQo+IDEwOjI5OjQ0 IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTA5ODIzMD5dID8gDQo+IHdha2VfdXBfYml0 KzB4MzAvMHgzMCBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogDQo+IFs8ZmZmZmZm ZmZhMDJhMWM0OD5dIHhmc191bm1vdW50ZnMrMHg2OC8weDE2MCBbeGZzXSBTZXAgMTEgMTA6Mjk6 NDQgDQo+IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmZhMDJhMjRlYj5dID8gDQo+IHhmc19t cnVfY2FjaGVfZGVzdHJveSsweDZiLzB4OTAgW3hmc10gU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9z dCANCj4ga2VybmVsOiBbPGZmZmZmZmZmYTAyYTM3MDE+XSB4ZnNfZnNfcHV0X3N1cGVyKzB4MjEv MHg2MCBbeGZzXSBTZXAgMTEgDQo+IDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZm ZmY4MTFjODkzNj5dIA0KPiBnZW5lcmljX3NodXRkb3duX3N1cGVyKzB4NTYvMHhlMCBTZXAgMTEg MTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogDQo+IFs8ZmZmZmZmZmY4MTFjOGMxNz5dIGtpbGxf YmxvY2tfc3VwZXIrMHgyNy8weDcwIFNlcCAxMSAxMDoyOTo0NCANCj4gbG9jYWxob3N0IGtlcm5l bDogWzxmZmZmZmZmZjgxMWM4ZjRkPl0gDQo+IGRlYWN0aXZhdGVfbG9ja2VkX3N1cGVyKzB4M2Qv MHg2MCBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM5NTU2 Pl0gZGVhY3RpdmF0ZV9zdXBlcisweDQ2LzB4NjAgU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBr ZXJuZWw6IFs8ZmZmZmZmZmY4MTFlNjI2NT5dIG1udHB1dF9ub19leHBpcmUrMHhjNS8weDEyMCBT ZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWU3MzlmPl0gU3lT X3Vtb3VudCsweDlmLzB4M2MwIFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZm ZmZmZmZmODE2MTNkYTk+XSBzeXN0ZW1fY2FsbF9mYXN0cGF0aCsweDE2LzB4MWIgU2VwIDExIDEw OjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IElORk86IHRhc2sgbW91bnQ6Mjg2NjkgYmxvY2tlZCBm b3IgbW9yZSB0aGFuIDEyMCBzZWNvbmRzLg0KPiBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtl cm5lbDogImVjaG8gMCA+IC9wcm9jL3N5cy9rZXJuZWwvaHVuZ190YXNrX3RpbWVvdXRfc2VjcyIg ZGlzYWJsZXMgdGhpcyBtZXNzYWdlLg0KPiBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5l bDogbW91bnQgICAgICAgICAgIEQgZmZmZjg4MDcwM2NmMzY4MCAgICAgMCAyODY2OSAgMjc5OTAg MHgwMDAwMDA4NA0KPiBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4MDZj YTU5ZmM0OCAwMDAwMDAwMDAwMDAwMDgyIA0KPiBmZmZmODgwZGVhODc3MWMwIGZmZmY4ODA2Y2E1 OWZmZDggU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiBmZmZmODgwNmNhNTlm ZmQ4IGZmZmY4ODA2Y2E1OWZmZDggZmZmZjg4MGRlYTg3NzFjMCBmZmZmODgwZGVhODc3MWMwIA0K PiBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4MGRlYzgxZjA2OCBmZmZm ODgwZGVjODFmMDcwIGZmZmZmZmZmMDAwMDAwMDAgZmZmZjg4MGRlYzgxZjA3OCBTZXAgMTEgMTA6 Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogQ2FsbCBUcmFjZToNCj4gU2VwIDExIDEwOjI5OjQ0IGxv Y2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTYwOTI1OT5dIA0KPiBzY2hlZHVsZSsweDI5LzB4 NzAgU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiBbPGZmZmZmZmZmODE2MGFi MzU+XSByd3NlbV9kb3duX3dyaXRlX2ZhaWxlZCsweDExNS8weDIyMA0KPiBTZXAgMTEgMTA6Mjk6 NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMjAxNDgxPl0gPyANCj4gX19ibGtkZXZf Z2V0KzB4MjIxLzB4NGQwIFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gWzxm ZmZmZmZmZjgxMWM4ODMwPl0gPyBzZXRfYmRldl9zdXBlcisweDQwLzB4NDAgU2VwIDExIDEwOjI5 OjQ0IA0KPiBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODEyZTI5YTM+XSANCj4gY2FsbF9y d3NlbV9kb3duX3dyaXRlX2ZhaWxlZCsweDEzLzB4MjANCj4gU2VwIDExIDEwOjI5OjQ0IGxvY2Fs aG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTYwODY0ZD5dID8gDQo+IGRvd25fd3JpdGUrMHgyZC8w eDMwIFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gWzxmZmZmZmZmZjgxMWM5 MTdlPl0gZ3JhYl9zdXBlcisweDJlLzB4YTAgU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCANCj4g a2VybmVsOiBbPGZmZmZmZmZmODExYzk4MTA+XSBzZ2V0KzB4MmEwLzB4M2QwIFNlcCAxMSAxMDoy OTo0NCANCj4gbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM4N2YwPl0gPyBuc190ZXN0 X3N1cGVyKzB4MjAvMHgyMCBTZXAgDQo+IDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8 ZmZmZmZmZmY4MTFjOWI5Mj5dIA0KPiBtb3VudF9iZGV2KzB4ZTIvMHgxZjAgU2VwIDExIDEwOjI5 OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiBbPGZmZmZmZmZmYTAyYTQ1ODA+XSA/IHhmc19wYXJz ZWFyZ3MrMHhiZjAvMHhiZjAgW3hmc10gU2VwIDExIDEwOjI5OjQ0IA0KPiBsb2NhbGhvc3Qga2Vy bmVsOiBbPGZmZmZmZmZmODEyZDYyMzA+XSA/IGlkYV9nZXRfbmV3X2Fib3ZlKzB4MjMwLzB4MmEw IA0KPiBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZmEwMmEyNzc1 Pl0gDQo+IHhmc19mc19tb3VudCsweDE1LzB4MjAgW3hmc10gU2VwIDExIDEwOjI5OjQ0IGxvY2Fs aG9zdCBrZXJuZWw6IA0KPiBbPGZmZmZmZmZmODExY2E1OTk+XSBtb3VudF9mcysweDM5LzB4MWIw IFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3QgDQo+IGtlcm5lbDogWzxmZmZmZmZmZjgxMTc4NDIw Pl0gPyBfX2FsbG9jX3BlcmNwdSsweDEwLzB4MjAgU2VwIDExIA0KPiAxMDoyOTo0NCBsb2NhbGhv c3Qga2VybmVsOiBbPGZmZmZmZmZmODExZTVhNmY+XSANCj4gdmZzX2tlcm5fbW91bnQrMHg1Zi8w eGYwIFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gWzxmZmZmZmZmZjgxMWU3 ZmJlPl0gZG9fbW91bnQrMHgyNGUvMHhhNDAgU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJu ZWw6IFs8ZmZmZmZmZmY4MTE3MzE3Yj5dID8gc3RybmR1cF91c2VyKzB4NGIvMHhmMCBTZXAgMTEg MTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWU4ODQ2Pl0gU3lTX21vdW50 KzB4OTYvMHhmMCBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgx NjEzZGE5Pl0gc3lzdGVtX2NhbGxfZmFzdHBhdGgrMHgxNi8weDFiIFNlcCAxMSAxMDozMDowMSBs b2NhbGhvc3Qgc3lzdGVtZDogU3RhcnRpbmcgU2Vzc2lvbiAxNDAgb2YgdXNlciByb290Lg0KPiBT ZXAgMTEgMTA6MzA6MDEgbG9jYWxob3N0IHN5c3RlbWQ6IFN0YXJ0ZWQgU2Vzc2lvbiAxNDAgb2Yg dXNlciByb290Lg0KPiBTZXAgMTEgMTA6MzA6MTAgbG9jYWxob3N0IGtlcm5lbDogWEZTIChkbS0y KTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NCj4gU2VwIDExIDEwOjMwOjQwIGxv Y2FsaG9zdCBrZXJuZWw6IFhGUyAoZG0tMik6IHhmc19sb2dfZm9yY2U6IGVycm9yIDUgcmV0dXJu ZWQuDQo+IFNlcCAxMSAxMDozMToxMCBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNf bG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0KPiBTZXAgMTEgMTA6MzE6NDAgbG9jYWxob3N0 IGtlcm5lbDogWEZTIChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NCj4g U2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IElORk86IHRhc2sgdW1vdW50OjI3OTUw IGJsb2NrZWQgZm9yIG1vcmUgdGhhbiAxMjAgc2Vjb25kcy4NCj4gU2VwIDExIDEwOjMxOjQ0IGxv Y2FsaG9zdCBrZXJuZWw6ICJlY2hvIDAgPiAvcHJvYy9zeXMva2VybmVsL2h1bmdfdGFza190aW1l b3V0X3NlY3MiIGRpc2FibGVzIHRoaXMgbWVzc2FnZS4NCj4gU2VwIDExIDEwOjMxOjQ0IGxvY2Fs aG9zdCBrZXJuZWw6IHVtb3VudCAgICAgICAgICBEIGZmZmY4ODBlMWZhZjM2ODAgICAgIDAgMjc5 NTAgIDI3Nzc1IDB4MDAwMDAwODQNCj4gU2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6 IGZmZmY4ODBkZDMyNDdkOTAgMDAwMDAwMDAwMDAwMDA4NiANCj4gZmZmZjg4MDZmNzMwZGIwMCBm ZmZmODgwZGQzMjQ3ZmQ4IFNlcCAxMSAxMDozMTo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gZmZm Zjg4MGRkMzI0N2ZkOCBmZmZmODgwZGQzMjQ3ZmQ4IGZmZmY4ODA2ZjczMGRiMDAgZmZmZjg4MDZl N2NlYWU4MCANCj4gU2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IGZmZmY4ODA2Y2I4 ODhiNDggZmZmZjg4MDZlN2NlYWVjMCBmZmZmODgwNmU3Y2VhZWU4IGZmZmY4ODA2ZTdjZWFlOTAg U2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IENhbGwgVHJhY2U6DQo+IFNlcCAxMSAx MDozMTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODE2MDkyNTk+XSANCj4gc2NoZWR1 bGUrMHgyOS8weDcwIFNlcCAxMSAxMDozMTo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gWzxmZmZm ZmZmZmEwMmYxYWMxPl0geGZzX2FpbF9wdXNoX2FsbF9zeW5jKzB4YzEvMHgxMTAgW3hmc10gU2Vw IDExIA0KPiAxMDozMTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODEwOTgyMzA+XSA/ IA0KPiB3YWtlX3VwX2JpdCsweDMwLzB4MzAgU2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJu ZWw6IA0KPiBbPGZmZmZmZmZmYTAyYTFjNDg+XSB4ZnNfdW5tb3VudGZzKzB4NjgvMHgxNjAgW3hm c10gU2VwIDExIDEwOjMxOjQ0IA0KPiBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmYTAyYTI0 ZWI+XSA/IA0KPiB4ZnNfbXJ1X2NhY2hlX2Rlc3Ryb3krMHg2Yi8weDkwIFt4ZnNdIFNlcCAxMSAx MDozMTo0NCBsb2NhbGhvc3QgDQo+IGtlcm5lbDogWzxmZmZmZmZmZmEwMmEzNzAxPl0geGZzX2Zz X3B1dF9zdXBlcisweDIxLzB4NjAgW3hmc10gU2VwIDExIA0KPiAxMDozMTo0NCBsb2NhbGhvc3Qg a2VybmVsOiBbPGZmZmZmZmZmODExYzg5MzY+XSANCj4gZ2VuZXJpY19zaHV0ZG93bl9zdXBlcisw eDU2LzB4ZTAgU2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiBbPGZmZmZmZmZm ODExYzhjMTc+XSBraWxsX2Jsb2NrX3N1cGVyKzB4MjcvMHg3MCBTZXAgMTEgMTA6MzE6NDQgDQo+ IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFjOGY0ZD5dIA0KPiBkZWFjdGl2YXRlX2xv Y2tlZF9zdXBlcisweDNkLzB4NjAgU2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8 ZmZmZmZmZmY4MTFjOTU1Nj5dIGRlYWN0aXZhdGVfc3VwZXIrMHg0Ni8weDYwIFNlcCAxMSAxMDoz MTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExZTYyNjU+XSBtbnRwdXRfbm9fZXhw aXJlKzB4YzUvMHgxMjAgU2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZm ZmY4MTFlNzM5Zj5dIFN5U191bW91bnQrMHg5Zi8weDNjMCBTZXAgMTEgMTA6MzE6NDQgbG9jYWxo b3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxNjEzZGE5Pl0gc3lzdGVtX2NhbGxfZmFzdHBhdGgrMHgx Ni8weDFiIFNlcCAxMSAxMDozMjoxMCBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNf bG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiDmnKzpgq7ku7blj4rlhbbpmYTku7blkKvmnInmna3lt57ljY7kuInpgJrkv6HmioDmnK/mnInp mZDlhazlj7jnmoTkv53lr4bkv6Hmga/vvIzku4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLlnLDlnYDk uK3liJflh7oNCj4g55qE5Liq5Lq65oiW576k57uE44CC56aB5q2i5Lu75L2V5YW25LuW5Lq65Lul 5Lu75L2V5b2i5byP5L2/55So77yI5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo5YiG5Zyw 5rOE6Zyy44CB5aSN5Yi244CBDQo+IOaIluaVo+WPke+8ieacrOmCruS7tuS4reeahOS/oeaBr+OA guWmguaenOaCqOmUmeaUtuS6huacrOmCruS7tu+8jOivt+aCqOeri+WNs+eUteivneaIlumCruS7 tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZpOacrA0KPiDpgq7ku7bvvIENCj4gVGhpcyBlLW1haWwg YW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9t IA0KPiBIM0MsIHdoaWNoIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5 IHdob3NlIGFkZHJlc3MgaXMgDQo+IGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IA0KPiAoaW5jbHVkaW5nLCBidXQgbm90 IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgZGlzY2xvc3VyZSwgDQo+IHJlcHJvZHVjdGlv biwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0K PiByZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwg aW4gZXJyb3IsIA0KPiBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwg aW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiB4ZnMgbWFpbGluZyBsaXN0DQo+IHhmc0Bvc3Muc2dp LmNvbQ0KPiBodHRwOi8vb3NzLnNnaS5jb20vbWFpbG1hbi9saXN0aW5mby94ZnMNCg0K From bfoster@redhat.com Tue Sep 15 10:16:04 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 0CCD17F37 for ; Tue, 15 Sep 2015 10:16:04 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id EF8408F8037 for ; Tue, 15 Sep 2015 08:16:00 -0700 (PDT) X-ASG-Debug-ID: 1442330158-04cbb005eb1326d0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 8AOsC2pyVcBKRIVj (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Sep 2015 08:15:59 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 91FABC0B91AC; Tue, 15 Sep 2015 15:15:58 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8FFFwg2026730; Tue, 15 Sep 2015 11:15:58 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 042771201EB; Tue, 15 Sep 2015 11:15:56 -0400 (EDT) Date: Tue, 15 Sep 2015 11:15:56 -0400 From: Brian Foster To: "zhao.mingyue@h3c.com" Cc: "xfs@oss.sgi.com" , Xudonghai Subject: Re: =?utf-8?B?562U5aSN?= =?utf-8?Q?=3A?= umount hanging problem Message-ID: <20150915151556.GD21323@bfoster.bfoster> X-ASG-Orig-Subj: Re: =?utf-8?B?562U5aSN?= =?utf-8?Q?=3A?= umount hanging problem References: <1CB94550540AE44E9CAAE8CD5AF40BF846CEDB68@H3CMLB12-EX.srv.huawei-3com.com> <20150915111420.GB21323@bfoster.bfoster> <1CB94550540AE44E9CAAE8CD5AF40BF846CEDD8C@H3CMLB12-EX.srv.huawei-3com.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1CB94550540AE44E9CAAE8CD5AF40BF846CEDD8C@H3CMLB12-EX.srv.huawei-3com.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442330159 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 15, 2015 at 12:59:27PM +0000, zhao.mingyue@h3c.com wrote: > Hi Brian, > Thanks for your explaination! > > kernel version：3.10.0-229.e17.x86-64 > > "Fixes for (hopefully) most of these problems are pending in 4.3"----Now 4.3rc1 has already fix this problem? > Yes, as of roughly commits 5e4b538 through d4a97a0 or so. Brian > -----邮件原件----- > å‘件人: Brian Foster [mailto:bfoster@redhat.com] > å‘é€æ—¶é—´: 2015å¹´9月15æ—¥ 19:14 > 收件人: zhaomingyue 09440 (RD) > 抄é€: xfs@oss.sgi.com; xudonghai 11507 (RD) > 主题: Re: umount hanging problem > > On Tue, Sep 15, 2015 at 02:59:53AM +0000, zhao.mingyue@h3c.com wrote: > > Hi,everyone > > > > I have some question about XFS FILEsystem，can someone help me sovle > > my problem ？ > > > > What kernel? > > > I built a Oracle database on a rbd block which had been created xfs > > filesystem ，then I removed the rbd block ，then the file directory of > > the oracle was broken and couldn’t be used，next，I recover the rbd > > block > > > > and umount the file directory of the oracle ，what happed next is the > > question which I was confused ，the process of the umount is hunging > > there and couldn’t be killed，how to solve the problem ？？ > > > > It's waiting to flush everything out that was previously written to the log and sitting in the AIL list. It sounds like the filesystem shutdown because the underlying block device was torn down before the filesystem was unmounted, which is not the way to do things. ;) Recent kernels have had issues with extent freeing logging such that EFI/EFD objects are not reference counted correctly and can sit in the AIL and pin it indefinitely, particularly on races with fs shutdown. > > Fixes for (hopefully) most of these problems are pending in 4.3. For the time being you'll probably have to reboot to recover. Also note that this should never happen except due to some other crash, caused in this case by breaking down the block device before unmounting the fs. > > Brian > > > thanksï¼ > > > > > > > > > > part of the log is as follows： > > > > Sep 11 10:22:29 localhost systemd: Started Fingerprint Authentication Daemon. > > Sep 11 10:22:29 localhost fprintd: Launching FprintObject Sep 11 > > 10:22:29 localhost fprintd: ** Message: D-Bus service launched with > > name: net.reactivated.Fprint Sep 11 10:22:29 localhost fprintd: ** > > Message: entering main loop Sep 11 10:22:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:22:47 localhost systemd-logind: Removed session 1. > > Sep 11 10:22:59 localhost fprintd: ** Message: No devices in use, exit > > Sep 11 10:23:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:23:19 localhost systemd-logind: Removed session 136. > > Sep 11 10:23:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:23:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > > Sep 11 10:23:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > Sep 11 10:23:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > > Sep 11 10:23:44 localhost kernel: ffff880dd3247d90 0000000000000086 > > ffff8806f730db00 ffff880dd3247fd8 Sep 11 10:23:44 localhost kernel: > > ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > > Sep 11 10:23:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 Sep 11 10:23:44 localhost kernel: Call Trace: > > Sep 11 10:23:44 localhost kernel: [] > > schedule+0x29/0x70 Sep 11 10:23:44 localhost kernel: > > [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] Sep 11 > > 10:23:44 localhost kernel: [] ? > > wake_up_bit+0x30/0x30 Sep 11 10:23:44 localhost kernel: > > [] xfs_unmountfs+0x68/0x160 [xfs] Sep 11 10:23:44 > > localhost kernel: [] ? > > xfs_mru_cache_destroy+0x6b/0x90 [xfs] Sep 11 10:23:44 localhost > > kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] Sep 11 > > 10:23:44 localhost kernel: [] > > generic_shutdown_super+0x56/0xe0 Sep 11 10:23:44 localhost kernel: > > [] kill_block_super+0x27/0x70 Sep 11 10:23:44 > > localhost kernel: [] > > deactivate_locked_super+0x3d/0x60 Sep 11 10:23:44 localhost kernel: [] deactivate_super+0x46/0x60 Sep 11 10:23:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 Sep 11 10:23:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 Sep 11 10:23:44 localhost kernel: [] system_call_fastpath+0x16/0x1b Sep 11 10:23:57 localhost systemd-logind: Removed session 133. > > Sep 11 10:24:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:24:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:25:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:25:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:25:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > > Sep 11 10:25:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > Sep 11 10:25:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > > Sep 11 10:25:44 localhost kernel: ffff880dd3247d90 0000000000000086 > > ffff8806f730db00 ffff880dd3247fd8 Sep 11 10:25:44 localhost kernel: > > ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > > Sep 11 10:25:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 Sep 11 10:25:44 localhost kernel: Call Trace: > > Sep 11 10:25:44 localhost kernel: [] > > schedule+0x29/0x70 Sep 11 10:25:44 localhost kernel: > > [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] Sep 11 > > 10:25:44 localhost kernel: [] ? > > wake_up_bit+0x30/0x30 Sep 11 10:25:44 localhost kernel: > > [] xfs_unmountfs+0x68/0x160 [xfs] Sep 11 10:25:44 > > localhost kernel: [] ? > > xfs_mru_cache_destroy+0x6b/0x90 [xfs] Sep 11 10:25:44 localhost > > kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] Sep 11 > > 10:25:44 localhost kernel: [] > > generic_shutdown_super+0x56/0xe0 Sep 11 10:25:44 localhost kernel: > > [] kill_block_super+0x27/0x70 Sep 11 10:25:44 > > localhost kernel: [] > > deactivate_locked_super+0x3d/0x60 Sep 11 10:25:44 localhost kernel: [] deactivate_super+0x46/0x60 Sep 11 10:25:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 Sep 11 10:25:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 Sep 11 10:25:44 localhost kernel: [] system_call_fastpath+0x16/0x1b Sep 11 10:26:05 localhost systemd-logind: New session 138 of user root. > > Sep 11 10:26:05 localhost systemd: Starting Session 138 of user root. > > Sep 11 10:26:05 localhost systemd: Started Session 138 of user root. > > Sep 11 10:26:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:26:29 localhost systemd-logind: New session 139 of user root. > > Sep 11 10:26:29 localhost systemd: Starting Session 139 of user root. > > Sep 11 10:26:29 localhost systemd: Started Session 139 of user root. > > Sep 11 10:26:32 localhost systemd-logind: Removed session 139. > > Sep 11 10:26:39 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:27:09 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:27:38 localhost goa[28775]: goa-daemon version 3.8.5 > > starting [main.c:113, main()] Sep 11 10:27:38 localhost goa[28782]: > > GoaKerberosIdentityManager: Using polling for change notification for credential cache type 'KEYRING' [goakerberosidentitymanager.c:1394, monitor_credentials_cache()] Sep 11 10:27:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:27:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > > Sep 11 10:27:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > Sep 11 10:27:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > > Sep 11 10:27:44 localhost kernel: ffff880dd3247d90 0000000000000086 > > ffff8806f730db00 ffff880dd3247fd8 Sep 11 10:27:44 localhost kernel: > > ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > > Sep 11 10:27:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 Sep 11 10:27:44 localhost kernel: Call Trace: > > Sep 11 10:27:44 localhost kernel: [] > > schedule+0x29/0x70 Sep 11 10:27:44 localhost kernel: > > [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] Sep 11 > > 10:27:44 localhost kernel: [] ? > > wake_up_bit+0x30/0x30 Sep 11 10:27:44 localhost kernel: > > [] xfs_unmountfs+0x68/0x160 [xfs] Sep 11 10:27:44 > > localhost kernel: [] ? > > xfs_mru_cache_destroy+0x6b/0x90 [xfs] Sep 11 10:27:44 localhost > > kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] Sep 11 > > 10:27:44 localhost kernel: [] > > generic_shutdown_super+0x56/0xe0 Sep 11 10:27:44 localhost kernel: > > [] kill_block_super+0x27/0x70 Sep 11 10:27:44 > > localhost kernel: [] > > deactivate_locked_super+0x3d/0x60 Sep 11 10:27:44 localhost kernel: [] deactivate_super+0x46/0x60 Sep 11 10:27:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 Sep 11 10:27:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 Sep 11 10:27:44 localhost kernel: [] system_call_fastpath+0x16/0x1b Sep 11 10:28:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:28:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:29:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:29:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:29:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > > Sep 11 10:29:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > Sep 11 10:29:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > > Sep 11 10:29:44 localhost kernel: ffff880dd3247d90 0000000000000086 > > ffff8806f730db00 ffff880dd3247fd8 Sep 11 10:29:44 localhost kernel: > > ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > > Sep 11 10:29:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 Sep 11 10:29:44 localhost kernel: Call Trace: > > Sep 11 10:29:44 localhost kernel: [] > > schedule+0x29/0x70 Sep 11 10:29:44 localhost kernel: > > [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] Sep 11 > > 10:29:44 localhost kernel: [] ? > > wake_up_bit+0x30/0x30 Sep 11 10:29:44 localhost kernel: > > [] xfs_unmountfs+0x68/0x160 [xfs] Sep 11 10:29:44 > > localhost kernel: [] ? > > xfs_mru_cache_destroy+0x6b/0x90 [xfs] Sep 11 10:29:44 localhost > > kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] Sep 11 > > 10:29:44 localhost kernel: [] > > generic_shutdown_super+0x56/0xe0 Sep 11 10:29:44 localhost kernel: > > [] kill_block_super+0x27/0x70 Sep 11 10:29:44 > > localhost kernel: [] > > deactivate_locked_super+0x3d/0x60 Sep 11 10:29:44 localhost kernel: [] deactivate_super+0x46/0x60 Sep 11 10:29:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 Sep 11 10:29:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 Sep 11 10:29:44 localhost kernel: [] system_call_fastpath+0x16/0x1b Sep 11 10:29:44 localhost kernel: INFO: task mount:28669 blocked for more than 120 seconds. > > Sep 11 10:29:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > Sep 11 10:29:44 localhost kernel: mount D ffff880703cf3680 0 28669 27990 0x00000084 > > Sep 11 10:29:44 localhost kernel: ffff8806ca59fc48 0000000000000082 > > ffff880dea8771c0 ffff8806ca59ffd8 Sep 11 10:29:44 localhost kernel: > > ffff8806ca59ffd8 ffff8806ca59ffd8 ffff880dea8771c0 ffff880dea8771c0 > > Sep 11 10:29:44 localhost kernel: ffff880dec81f068 ffff880dec81f070 ffffffff00000000 ffff880dec81f078 Sep 11 10:29:44 localhost kernel: Call Trace: > > Sep 11 10:29:44 localhost kernel: [] > > schedule+0x29/0x70 Sep 11 10:29:44 localhost kernel: > > [] rwsem_down_write_failed+0x115/0x220 > > Sep 11 10:29:44 localhost kernel: [] ? > > __blkdev_get+0x221/0x4d0 Sep 11 10:29:44 localhost kernel: > > [] ? set_bdev_super+0x40/0x40 Sep 11 10:29:44 > > localhost kernel: [] > > call_rwsem_down_write_failed+0x13/0x20 > > Sep 11 10:29:44 localhost kernel: [] ? > > down_write+0x2d/0x30 Sep 11 10:29:44 localhost kernel: > > [] grab_super+0x2e/0xa0 Sep 11 10:29:44 localhost > > kernel: [] sget+0x2a0/0x3d0 Sep 11 10:29:44 > > localhost kernel: [] ? ns_test_super+0x20/0x20 Sep > > 11 10:29:44 localhost kernel: [] > > mount_bdev+0xe2/0x1f0 Sep 11 10:29:44 localhost kernel: > > [] ? xfs_parseargs+0xbf0/0xbf0 [xfs] Sep 11 10:29:44 > > localhost kernel: [] ? ida_get_new_above+0x230/0x2a0 > > Sep 11 10:29:44 localhost kernel: [] > > xfs_fs_mount+0x15/0x20 [xfs] Sep 11 10:29:44 localhost kernel: > > [] mount_fs+0x39/0x1b0 Sep 11 10:29:44 localhost > > kernel: [] ? __alloc_percpu+0x10/0x20 Sep 11 > > 10:29:44 localhost kernel: [] > > vfs_kern_mount+0x5f/0xf0 Sep 11 10:29:44 localhost kernel: > > [] do_mount+0x24e/0xa40 Sep 11 10:29:44 localhost kernel: [] ? strndup_user+0x4b/0xf0 Sep 11 10:29:44 localhost kernel: [] SyS_mount+0x96/0xf0 Sep 11 10:29:44 localhost kernel: [] system_call_fastpath+0x16/0x1b Sep 11 10:30:01 localhost systemd: Starting Session 140 of user root. > > Sep 11 10:30:01 localhost systemd: Started Session 140 of user root. > > Sep 11 10:30:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:30:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:31:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:31:40 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > Sep 11 10:31:44 localhost kernel: INFO: task umount:27950 blocked for more than 120 seconds. > > Sep 11 10:31:44 localhost kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > Sep 11 10:31:44 localhost kernel: umount D ffff880e1faf3680 0 27950 27775 0x00000084 > > Sep 11 10:31:44 localhost kernel: ffff880dd3247d90 0000000000000086 > > ffff8806f730db00 ffff880dd3247fd8 Sep 11 10:31:44 localhost kernel: > > ffff880dd3247fd8 ffff880dd3247fd8 ffff8806f730db00 ffff8806e7ceae80 > > Sep 11 10:31:44 localhost kernel: ffff8806cb888b48 ffff8806e7ceaec0 ffff8806e7ceaee8 ffff8806e7ceae90 Sep 11 10:31:44 localhost kernel: Call Trace: > > Sep 11 10:31:44 localhost kernel: [] > > schedule+0x29/0x70 Sep 11 10:31:44 localhost kernel: > > [] xfs_ail_push_all_sync+0xc1/0x110 [xfs] Sep 11 > > 10:31:44 localhost kernel: [] ? > > wake_up_bit+0x30/0x30 Sep 11 10:31:44 localhost kernel: > > [] xfs_unmountfs+0x68/0x160 [xfs] Sep 11 10:31:44 > > localhost kernel: [] ? > > xfs_mru_cache_destroy+0x6b/0x90 [xfs] Sep 11 10:31:44 localhost > > kernel: [] xfs_fs_put_super+0x21/0x60 [xfs] Sep 11 > > 10:31:44 localhost kernel: [] > > generic_shutdown_super+0x56/0xe0 Sep 11 10:31:44 localhost kernel: > > [] kill_block_super+0x27/0x70 Sep 11 10:31:44 > > localhost kernel: [] > > deactivate_locked_super+0x3d/0x60 Sep 11 10:31:44 localhost kernel: [] deactivate_super+0x46/0x60 Sep 11 10:31:44 localhost kernel: [] mntput_no_expire+0xc5/0x120 Sep 11 10:31:44 localhost kernel: [] SyS_umount+0x9f/0x3c0 Sep 11 10:31:44 localhost kernel: [] system_call_fastpath+0x16/0x1b Sep 11 10:32:10 localhost kernel: XFS (dm-2): xfs_log_force: error 5 returned. > > ---------------------------------------------------------------------- > > --------------------------------------------------------------- > > 本邮件åŠå…¶é™„件å«æœ‰æ­å·žåŽä¸‰é€šä¿¡æŠ€æœ¯æœ‰é™å…¬å¸çš„ä¿å¯†ä¿¡æ¯ï¼Œä»…é™äºŽå‘é€ç»™ä¸Šé¢åœ°å€ä¸­åˆ—出 > > 的个人或群组。ç¦æ­¢ä»»ä½•å…¶ä»–人以任何形å¼ä½¿ç”¨ï¼ˆåŒ…括但ä¸é™äºŽå…¨éƒ¨æˆ–部分地泄露ã€å¤åˆ¶ã€ > > 或散å‘）本邮件中的信æ¯ã€‚如果您错收了本邮件，请您立å³ç”µè¯æˆ–邮件通知å‘件人并删除本 > > é‚®ä»¶ï¼ > > This e-mail and its attachments contain confidential information from > > H3C, which is intended only for the person or entity whose address is > > listed above. Any use of the information contained herein in any way > > (including, but not limited to, total or partial disclosure, > > reproduction, or dissemination) by persons other than the intended > > recipient(s) is prohibited. If you receive this e-mail in error, > > please notify the sender by phone or email immediately and delete it! > > > _______________________________________________ > > xfs mailing list > > xfs@oss.sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs > From ella-xfs=oss.sgi.com@stordoor.com Tue Sep 15 13:05:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 28F187F37 for ; Tue, 15 Sep 2015 13:05:43 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 05FD730404E for ; Tue, 15 Sep 2015 11:05:39 -0700 (PDT) X-ASG-Debug-ID: 1442340311-04cb6c355a122140001-NocioJ Received: from services.stordoor.com (services.stordoor.com [37.247.117.166]) by cuda.sgi.com with ESMTP id kPPbqN8NB9nJ9eMw for ; Tue, 15 Sep 2015 11:05:11 -0700 (PDT) X-Barracuda-Envelope-From: ella-xfs=oss.sgi.com@stordoor.com X-Barracuda-Apparent-Source-IP: 37.247.117.166 Received: by services.stordoor.com id hv1ev40001gb for ; Tue, 15 Sep 2015 10:52:01 -0700 (envelope-from ) MIME-Version: 1.0 From: "Ella Badgley" To: xfs@oss.sgi.com Subject: Say goodbye to losing stuff! Date: Tue, 15 Sep 2015 10:52:01 -0700 X-ASG-Orig-Subj: Say goodbye to losing stuff! Content-Type: text/plain; Message-ID: <0.0.0.2E.1D0EFDF39AE8DCA.14B18B@services.stordoor.com> X-Barracuda-Connect: services.stordoor.com[37.247.117.166] X-Barracuda-Start-Time: 1442340311 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.50 X-Barracuda-Spam-Status: No, SCORE=1.50 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MV0702 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22570 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.50 BSF_SC0_MV0702 Custom rule MV0702 Incredible new app makes it so you never have to lose anything again. Your car, keys, luggage, even pets, can be easily located with revolutionary new app. Go to http://stordoor.com/PcQobFauGhcbpLl/TrackR . . . . . . . . . . . . . . . To stop getting emails from us go: http://stordoor.com/3Lz3mv8dD2IRzrX/RemoveTrack .3121 Matthews Street,Chicago, IL 60605 From ella-xfs=oss.sgi.com@stordoor.com Tue Sep 15 13:05:44 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 222BD7F37 for ; Tue, 15 Sep 2015 13:05:44 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 128298F8037 for ; Tue, 15 Sep 2015 11:05:40 -0700 (PDT) X-ASG-Debug-ID: 1442340311-04cb6c355a122140002-NocioJ Received: from services.stordoor.com (services.stordoor.com [37.247.117.166]) by cuda.sgi.com with ESMTP id rFql3tM4B3dyjrLw for ; Tue, 15 Sep 2015 11:05:39 -0700 (PDT) X-Barracuda-Envelope-From: ella-xfs=oss.sgi.com@stordoor.com X-Barracuda-Apparent-Source-IP: 37.247.117.166 Received: by services.stordoor.com id hv1ev80001g7 for ; Tue, 15 Sep 2015 10:53:11 -0700 (envelope-from ) MIME-Version: 1.0 From: "Ella Badgley" To: xfs@oss.sgi.com Subject: Say goodbye to losing stuff! Date: Tue, 15 Sep 2015 10:53:11 -0700 X-ASG-Orig-Subj: Say goodbye to losing stuff! Content-Type: text/plain; Message-ID: <0.0.0.4A.1D0EFDF6373E4F2.54176E@services.stordoor.com> X-Barracuda-Connect: services.stordoor.com[37.247.117.166] X-Barracuda-Start-Time: 1442340338 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.50 X-Barracuda-Spam-Status: No, SCORE=1.50 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MV0702 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22570 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.50 BSF_SC0_MV0702 Custom rule MV0702 Incredible new app makes it so you never have to lose anything again. Your car, keys, luggage, even pets, can be easily located with revolutionary new app. Go to http://stordoor.com/PcQobFauGhcbpLl/TrackR . . . . . . . . . . . . . . . To stop getting emails from us go: http://stordoor.com/3Lz3mv8dD2IRzrX/RemoveTrack .3121 Matthews Street,Chicago, IL 60605 From diemloan@yeah123.net Tue Sep 15 16:27:17 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.9 required=5.0 tests=HTML_MESSAGE,TVD_FROM_1 autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id BA6717F37 for ; Tue, 15 Sep 2015 16:27:17 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 545DFAC007 for ; Tue, 15 Sep 2015 14:27:14 -0700 (PDT) X-ASG-Debug-ID: 1442352431-04bdf04db41442c0001-NocioJ Received: from minivps2072 ([42.112.16.151]) by cuda.sgi.com with ESMTP id JZKBpRCzcDrl3J1i for ; Tue, 15 Sep 2015 14:27:11 -0700 (PDT) X-Barracuda-Envelope-From: diemloan@yeah123.net X-Barracuda-Apparent-Source-IP: 42.112.16.151 Received: from OpenServer (adsl.viettel.vn [115.73.84.25]) by minivps2072 with SMTP; Wed, 16 Sep 2015 01:30:25 +0700 From: To: xfs@oss.sgi.com Subject: =?utf-8?Q?Di=E1=BB=85m_Loan_invites_you_to_Startupf.net.?= X-PHP-Originating-Script: 0:class.phpmailer.php X-ASG-Orig-Subj: =?utf-8?Q?Di=E1=BB=85m_Loan_invites_you_to_Startupf.net.?= Date: Tue, 15 Sep 2015 17:18:20 +0000 Message-ID: <2433c5fc9255b0c90d29088215e9b5d0@startupf.net> X-Mailer: PHPMailer 5.2.10 (https://github.com/PHPMailer/PHPMailer/) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_2433c5fc9255b0c90d29088215e9b5d0" Content-Transfer-Encoding: 8bit X-Barracuda-Connect: UNKNOWN[42.112.16.151] X-Barracuda-Start-Time: 1442352431 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC5_MJ1963, HTML_MESSAGE, NO_REAL_NAME, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22579 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 This is a multi-part message in MIME format. --b1_2433c5fc9255b0c90d29088215e9b5d0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello, Diá»…m Loan invites you to Startupf.net. To check out this invitation, follow the link below:
http://startupf.net
Takeoff and landing in Tan son Nhat
Aeon Mall lớn nhất Việt Nam
Biggest Airplan Diem Loan --b1_2433c5fc9255b0c90d29088215e9b5d0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello,

Diá»…m Loan invites you to Startupf.net.

To check out this invitation, follow the link below:

http://startupf.net

Takeoff and landing in Tan son Nhat


Aeon Mall lớn nhất Việt Nam


Biggest Airplan

Diem Loan --b1_2433c5fc9255b0c90d29088215e9b5d0-- From grant.keller@sonic.com Tue Sep 15 17:33:50 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 7B8DF7F37 for ; Tue, 15 Sep 2015 17:33:50 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 2688AAC001 for ; Tue, 15 Sep 2015 15:33:47 -0700 (PDT) X-ASG-Debug-ID: 1442356424-04bdf04db4148290001-NocioJ Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by cuda.sgi.com with ESMTP id vGrnHrdp2lZ5pYAC (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 15 Sep 2015 15:33:44 -0700 (PDT) X-Barracuda-Envelope-From: grant.keller@sonic.com X-Barracuda-Apparent-Source-IP: 64.142.111.80 Received: from [64.142.18.25] (gwork.noc.sonic.net [64.142.18.25]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t8FMXh19021416 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Sep 2015 15:33:43 -0700 Subject: Re: rm Tainted warning after kernel update. To: Brian Foster X-ASG-Orig-Subj: Re: rm Tainted warning after kernel update. References: <55F718A1.10801@sonic.com> <20150915110042.GA21323@bfoster.bfoster> Cc: xfs@oss.sgi.com From: Grant Keller X-Enigmail-Draft-Status: N1110 Message-ID: <55F89C76.4090808@sonic.com> Date: Tue, 15 Sep 2015 15:32:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150915110042.GA21323@bfoster.bfoster> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYRiSg64ptk+fq89cbvbaPft1LxDBWli0lY/aKrEKTBNY3TXXB2t3q0I9X82pmfSxeuIEPcAVFIWv3JCzCR2UBq X-Sonic-ID: C;vL0h0vlb5RG1iL0U9jFv0A== M;sjA70vlb5RG1iL0U9jFv0A== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-Barracuda-Connect: c.mail.sonic.net[64.142.111.80] X-Barracuda-Start-Time: 1442356424 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22581 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 09/15/2015 04:00 AM, Brian Foster wrote: > On Mon, Sep 14, 2015 at 11:57:37AM -0700, Grant Keller wrote: >> Hello, >> >> I have a server running Scientific Linux 6.7, and since updating to >> kernel 2.6.32-573.3.1.el6.x86_64 the following error has begun appearing >> in our message logs: >> >> Sep 14 11:43:03 localhost kernel: ------------[ cut here ]------------ >> Sep 14 11:43:03 localhost kernel: WARNING: at fs/dcache.c:758 >> d_delete+0x260/0x2c0() (Tainted: G W -- ------------ ) >> Sep 14 11:43:03 localhost kernel: Hardware name: X7DB8 >> Sep 14 11:43:03 localhost kernel: Modules linked in: nfsd nfs_acl >> auth_rpcgss autofs4 lockd sunrpc p4_clockmod freq_table speedstep_lib >> nf_conntrack_ftp iptable_mangle xt_comment nf_conntrack_ipv4 >> nf_defrag_ipv4 xt_multiport iptable_filter ip_tables ip6t_REJECT >> nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter >> ip6_tables ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm >> iw_cm ib_sa ib_mad ib_core ib_addr ipv6 xfs exportfs ppdev parport_pc >> parport sg e1000e microcode serio_raw iTCO_wdt iTCO_vendor_support ixgbe >> ptp pps_core mdio i2c_i801 lpc_ich mfd_core i5000_edac edac_core i5k_amb >> ioatdma dca shpchp ext4 jbd2 mbcache sd_mod crc_t10dif 3w_9xxx pata_acpi >> ata_generic ata_piix radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core >> dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ipmi_msghandler] >> Sep 14 11:43:03 localhost kernel: Pid: 15893, comm: rm Tainted: G >> W -- ------------ 2.6.32-573.3.1.el6.x86_64 #1 >> Sep 14 11:43:03 localhost kernel: Call Trace: >> Sep 14 11:43:03 localhost kernel: [] ? >> warn_slowpath_common+0x91/0xe0 >> Sep 14 11:43:03 localhost kernel: [] ? >> warn_slowpath_null+0x1a/0x20 >> Sep 14 11:43:03 localhost kernel: [] ? >> d_delete+0x260/0x2c0 >> Sep 14 11:43:03 localhost kernel: [] ? vfs_rmdir+0xe8/0xf0 >> Sep 14 11:43:03 localhost kernel: [] ? >> do_rmdir+0x184/0x1f0 >> Sep 14 11:43:03 localhost kernel: [] ? __fput+0x1a1/0x210 >> Sep 14 11:43:03 localhost kernel: [] ? >> audit_syscall_entry+0x1d7/0x200 >> Sep 14 11:43:03 localhost kernel: [] ? >> sys_unlinkat+0x2d/0x40 >> Sep 14 11:43:03 localhost kernel: [] ? >> system_call_fastpath+0x16/0x1b >> Sep 14 11:43:03 localhost kernel: ---[ end trace 6080ec4a7ec5ec25 ]--- >> >> This happens when we are expiring older backups from the archives, so I >> have quite a few of these. We have xfsprogs 3.1.1-16.el6.x86_64 >> installed. Looking for advice on how to proceed. >> > This looks like something funky going on in the vfs. The warning is from > unhash_offsprings() and it appears to be complaining about a refcount on > a dentry that is a child of a directory being removed. It checks a > refcount on a dentry in one loop and either drops it or moves it to > another list for apparent deletion. The second iteration of the > aforementioned list sees a refcount on an object that wasn't there > before. > > I suspect this means something is going from 0->1 unexpectedly, but I'm > not familiar enough with that code to grok why that shouldn't happen and > how it could without reproducing it and digging into it from there. Have > you identified an explicit reproducer? I assume files are simply being > removed with 'rm -rf' here..? If so, does anything else have access to > this directory structure (e.g., separate commands, a running backup > application?) at the the time of removal. There could be something else running, but I would have to investigate the next time this happens. The rm -rf is called by our backup program expiring older backups from the filesystem. The thing is, the expirations happen on a nightly basis, but we don't always see these warnings in the logs. On the nights we do, there are 1000+ warnings. > > Also, what kernel were you running before this started to occur? 2.6.32-573.el6.x86_64 was the previous kernel. > > Brian > > -- Grant Keller System Operations 707-237-2451 grant.keller@sonic.com From MD-NO--34305-37-FR-PR--xfs=oss.sgi.com@lists.mdirector.com Wed Sep 16 00:53:37 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,T_DKIM_INVALID, T_KHOP_FOREIGN_CLICK autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id E66817F37 for ; Wed, 16 Sep 2015 00:53:37 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 8A1AE8F8040 for ; Tue, 15 Sep 2015 22:53:34 -0700 (PDT) X-ASG-Debug-ID: 1442382805-04bdf04db415f1c0001-NocioJ Received: from mta141.181.mdrctr.com (mta141.181.mdrctr.com [62.97.141.181]) by cuda.sgi.com with ESMTP id 0yjsOuytgaF5tFON for ; Tue, 15 Sep 2015 22:53:26 -0700 (PDT) X-Barracuda-Envelope-From: MD-NO--34305-37-FR-PR--xfs=oss.sgi.com@lists.mdirector.com X-Barracuda-Apparent-Source-IP: 62.97.141.181 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=free; d=interbev.frmdirector.com; h=From:Reply-To:To:Date:List-Id:List-Unsubscribe:Subject:MIME-Version:Content-Type:Message-ID; i=info@interbev.frmdirector.com; bh=6hMWR9r83KaD3JqpD5I11PPjH/s=; b=QD0i75bJIpdC8G5Ta5UAXA+Z7Yoi6JRx+ylQnmrWaUguKbR75hmvWU7oreRREr9jua8UHOZnS7dN AiZK/dbrtKEqyxNTvssHf/zpBulAxi1YSfIamQnOiafj94jkvg/oIPf5AM8HMRYkAXTDIsvkplEU i3q+q2dJ7GNpCfF54mI= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=free; d=interbev.frmdirector.com; b=KfApxUP2nIas9HOazzDffBB6EOv+H23MZXOZ2ndGhKH3btUfTX2Y6XdxdAcngW9gC7Un+4QY1zvC VPm4hJYHUsNNeKX4zbwrUcky3HPCk5upTRWEeRB/vB2pi6QdKgU1HNpcZL+Phs2LEWqqRmtfd1Hy b1Wayyl4iWk0zrLKbLk=; Received: from pmtarelay.mta.antevenio.com (172.16.18.20) by mta141.181.mdrctr.com id hv41ro15miog for ; Wed, 16 Sep 2015 07:50:14 +0200 (envelope-from ) Received: from pmtarelay.mta.antevenio.com (172.16.18.20) by pmtarelay.mta.antevenio.com id hv41k015mg8l for ; Wed, 16 Sep 2015 07:50:43 +0200 (envelope-from ) From: "L'Agneau si simple si bon !" Reply-To: "L'Agneau si simple si bon !" To: Precedence: bulk X-rpcampaign: mdMDNO3430537FRPR X-rpcampaignok: mdmdMD-NO--34305-37-FR-PR X-reputation: -1 Date: Wed, 16 Sep 2015 07:50:43 +0200 List-Id: 34305-4.mdirector.com List-Unsubscribe: , X-LU: , Subject: L'agneau,=?UTF-8?Q?=20si=20simple=20si=20bon=20pou?= =?UTF-8?Q?r=20la=20rentr=C3=A9e=20=21?= MIME-Version: 1.0 X-ASG-Orig-Subj: L'agneau,=?UTF-8?Q?=20si=20simple=20si=20bon=20pou?= =?UTF-8?Q?r=20la=20rentr=C3=A9e=20=21?= Content-Type: multipart/mixed; boundary="boundaryTagForMixed" Message-ID: <0.0.0.58.1D0F043A017F466.10602B2@pmtarelay.mta.antevenio.com> X-Barracuda-Connect: mta141.181.mdrctr.com[62.97.141.181] X-Barracuda-Start-Time: 1442382805 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.40 X-Barracuda-Spam-Status: No, SCORE=0.40 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA085b, DKIM_SIGNED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22590 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message 0.40 BSF_SC0_SA085b Custom Rule SA085b --boundaryTagForMixed Content-Type: multipart/alternative; boundary="boundaryTagForAlternative" --boundaryTagForAlternative Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit ********************************************************************** Vous pourrez exercer vos droits d´accès, annulation, rectification et opposition concernant vos données à caractère personnel, en cliquant * annulation //www.mdirector.com/track/pre-unsubscribe/category/EMAIL/empId/34305/subId/37/listId/4/conId/27806/signature/7421d9d8e64429ac5e784d273435fdb2/conEmail/xfs@oss.sgi.com/conMovil/- --boundaryTagForAlternative Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Si bon si simple de jouer avec l'agneau
 
Si vous n’arrivez pas à visualiser cet email, cliquez ici.
 
 
SI BON SI SIMPLE DE JOUER AVEC L'AGNEAU
 
 
TENTEZ DE GAGNER* L'UN DES 100 COFFRETS WOK OU POÊLES AVEC LEUR POIGNÉE MAGNÉTIQUE.
 
JE TENTE MA CHANCE
 
 
Wrap Agneau Avocat
 
WRAP À L’AGNEAU ET AU GUACAMOLE
 
Temps de préparation : 15 minutesTemps de préparation : 15 minutes
 
DÉCOUVREZ LA RECETTE
 
Le saviez-vous ? Un agneau est un mouton de moins de 300 jours
S'INSCRIRE À LA NEWSLETTER
 
Campagne financée avec le concours de l'Union EuropéenneInterbevAHDBBord BIA
 
Conformément à la loi "Informatique et libertés" du 6 janvier 1978, vous bénéficiez d'un droit d'accès, de modification, de rectification et de suppression des données qui vous concernent. Si vous souhaitez exercer ce droit et obtenir communication des informations vous concernant, veuillez vous adresser à : Venise Activation, 7-13 boulevard Paul Émile Victor 92200 Neuilly-Sur-Seine.
*Le règlement du jeu concours sans obligation d’achat « Si simple et si bon de jouer avec l’agneau » est disponible en cliquant sur ce lien: http://www.sisimplesibondejoueraveclagneau.com.
 
 
Pour ne plus recevoir d'email de la part de L’agneau si simple si bon, cliquez ici.
 
Vous pourrez exercer vos droits d´accès, annulation, rectification et opposition concernant vos données à caractère personnel, en cliquant annulation.
--boundaryTagForAlternative-- --boundaryTagForMixed-- From muawiyafiad@bk.ru Wed Sep 16 02:37:42 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=2.0 required=5.0 tests=FREEMAIL_FROM, HTML_IMAGE_ONLY_16,HTML_MESSAGE autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 26ACF7F37 for ; Wed, 16 Sep 2015 02:37:42 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 04CFA304039 for ; Wed, 16 Sep 2015 00:37:38 -0700 (PDT) X-ASG-Debug-ID: 1442389055-04cbb005ec16db60001-NocioJ Received: from [46.225.201.30] ([46.225.201.30]) by cuda.sgi.com with ESMTP id KqCT6VaivFitPqLK for ; Wed, 16 Sep 2015 00:37:35 -0700 (PDT) X-Barracuda-Envelope-From: muawiyafiad@bk.ru X-Barracuda-Apparent-Source-IP: 46.225.201.30 To: xfs From: =?koi8-r?B?6cfOwdTYxdc=?= Message-ID: <201509161107237TPFH73RD5CRI9127795@bk.ru> Reply-To: =?koi8-r?B?6cfOwdTYxdc=?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="GAV96QNX64T0" Precedence: bulk X-Mailer: IPB PHP X-XN-Filter:yes Subject: =?koi8-r?B?99nXxcTVINPBytQg1yAxMMvVIMTF28XXzMUgxNLVx8nIIQ==?= Date: Wed, 16 Sep 2015 11:07:23 +0330 X-ASG-Orig-Subj: =?koi8-r?B?99nXxcTVINPBytQg1yAxMMvVIMTF28XXzMUgxNLVx8nIIQ==?= X-Barracuda-Connect: UNKNOWN[46.225.201.30] X-Barracuda-Start-Time: 1442389055 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.73 X-Barracuda-Spam-Status: No, SCORE=0.73 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_TG035a, HTML_IMAGE_ONLY_16, HTML_MESSAGE, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22592 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 0.00 BSF_SC0_TG035a Message contains invalid style definition 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS --GAV96QNX64T0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable =F1 - =E6=D2=C9=CC=C1=CE=D3=C5=D2. =ED=CF=CA =CF=D0=D9=D4 =D5=D3=D0=C5= =DB=CE=CF=C7=CF =D7=D9=D7=CF=C4=C1 =D3=C1=CA=D4=CF=D7 =D7 =F4=EF=F0 - =C2= =CF=CC=C5=C5 7 =CC=C5=D4. =F7=D9 =D0=CF=CC=D5=DE=C1=C5=D4=C5 =D2=C5=DA= =D5=CC=D8=D4=C1=D4 =C2=C5=DA =D0=C5=D2=C5=D0=CC=C1=D4=D9 =CB=C1=CB=CF=CA-= =CC=C9=C2=CF =CB=CF=CD=D0=C1=CE=C9=C9. =EF=C2=DF=A3=CD =D2=C1=C2=CF=D4, = =CB=CF=D4=CF=D2=D9=CA =D1 =D0=D2=C5=C4=CC=C1=C7=C1=C0, =D3=D4=CF=C9=D4 = =D7=C5=DA=C4=C5 =CF=D4 25 =D4=D9=D3.=D2=D5=C2. =D7 =CD=C5=D3., =CE=CF =F7= =D9 =D0=CF=CC=D5=DE=C1=C5=D4=C5 =CB=C1=DE=C5=D3=D4=D7=C5=CE=CE=D9=CA =D2= =C5=DA=D5=CC=D8=D4=C1=D4 =CF=D4 =CD=C5=CE=D1 =DA=C1 =C3=C5=CE=D5, =D3=D5= =DD=C5=D3=D4=D7=C5=CE=CE=CF =C2=CF=CC=C5=C5 =CE=C9=DA=CB=D5=C0 =CF=C2=CF= =DA=CE=C1=DE=C5=CE=CE=CF=CA. =F7=C1=CD =CE=D5=D6=CE=D9 =CE=CF=D7=D9=C5 = =DA=C1=CB=C1=DA=D9 =C9 =D3=C1=CA=D4 =D7 =F4=EF=F0 =D0=CF =DA=C1=D0=D2=CF= =D3=C1=CD =D5=D6=C5 =DE=C5=D2=C5=DA 3-4 =CD=C5=D3=D1=C3=C1? =E5=D3=CC=C9 = "=C4=C1", =D4=CF =D7 =D4=C5=CB=D3=D4=C5 =DA=C1=D0=D2=CF=D3=C1 = =D0=CF e-mail =D5=CB=C1=D6=C9=D4=C5 =D3=CC=C5=C4=D5=C0=DD=C5=C5: 1). =E1= =C4=D2=C5=D3 =D3=C1=CA=D4=C1, =CB=CF=D4=CF=D2=D9=CA =CE=D5=D6=CE=CF =D0= =D2=CF=C4=D7=C9=C7=C1=D4=D8. 2). =EB=CC=C0=DE=C5=D7=D9=C5 =D3=CC=CF=D7=C1= , =D0=CF =CB=CF=D4=CF=D2=D9=CD =CE=D5=D6=CE=CF =D0=D2=CF=C4=D7=C9=C7=C1= =D4=D8 =F7=C1=DB =D3=C1=CA=D4 (=C9=CC=C9 =D1 =D0=D2=C5=C4=CC=CF=D6=D5 =D3= =D7=CF=CA =D7=C1=D2=C9=C1=CE=D4). 3). =F0=CF =CB=C1=CB=CF=CD=D5 =D2=C5=C7= =C9=CF=CE=D5 =C9/=C9=CC=C9 =C7=CF=D2=CF=C4=D5 =CE=D5=D6=C5=CE =D7=D9=C8= =CF=C4 =D7 =F4=EF=F0 =DA=C1=D0=D2=CF=D3=CF=D7. =F7 =CF=D4=D7=C5=D4=CE=CF= =CD =D0=C9=D3=D8=CD=C5 =D1 =D0=D2=C9=DB=CC=C0 =F7=C1=CD =D0=CF=C4=D2=CF= =C2=CE=D9=CA =D0=CC=C1=CE =D2=C1=C2=CF=D4 =C9 =C9=C8 =D3=D4=CF=C9=CD=CF= =D3=D4=D8. --GAV96QNX64T0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

=F1 - = =E6=D2=C9=CC=C1=CE=D3=C5=D2. =ED=CF=CA =CF=D0=D9=D4 =D5=D3=D0=C5=DB=CE=CF= =C7=CF =D7=D9=D7=CF=C4=C1 =D3=C1=CA=D4=CF=D7 =D7 =F4=EF=F0 - =C2=CF=CC=C5= =C5 7 =CC=C5=D4.

=F7=D9 =D0=CF=CC= =D5=DE=C1=C5=D4=C5 =D2=C5=DA=D5=CC=D8=D4=C1=D4 =C2=C5=DA =D0=C5=D2=C5=D0= =CC=C1=D4=D9 =CB=C1=CB=CF=CA-=CC=C9=C2=CF =CB=CF=CD=D0=C1=CE=C9=C9.

=EF=C2=DF=A3=CD = =D2=C1=C2=CF=D4, =CB=CF=D4=CF=D2=D9=CA =D1 =D0=D2=C5=C4=CC=C1=C7=C1=C0, = =D3=D4=CF=C9=D4 =D7=C5=DA=C4=C5 =CF=D4 25 =D4=D9=D3.=D2=D5=C2. =D7 =CD=C5= =D3., =CE=CF =F7=D9 =D0=CF=CC=D5=DE=C1=C5=D4=C5 =CB=C1=DE=C5=D3=D4=D7=C5= =CE=CE=D9=CA =D2=C5=DA=D5=CC=D8=D4=C1=D4 =CF=D4 =CD=C5=CE=D1 =DA=C1 =C3= =C5=CE=D5, =D3=D5=DD=C5=D3=D4=D7=C5=CE=CE=CF =C2=CF=CC=C5=C5 =CE=C9=DA=CB= =D5=C0 =CF=C2=CF=DA=CE=C1=DE=C5=CE=CE=CF=CA.

=F7=C1= =CD =CE=D5=D6=CE=D9 =CE=CF=D7=D9=C5 =DA=C1=CB=C1=DA=D9 =C9 =D3=C1=CA=D4 = =D7 =F4=EF=F0 =D0=CF =DA=C1=D0=D2=CF=D3=C1=CD =D5=D6=C5 =DE=C5=D2=C5=DA 3= -4 =CD=C5=D3=D1=C3=C1?
=E5=D3=CC=C9 "=C4=C1", =D4=CF =D7 =D4=C5=CB=D3=D4=C5 =DA=C1=D0= =D2=CF=D3=C1 =D0=CF e-mail =D5=CB=C1=D6=C9=D4=C5 =D3=CC=C5=C4=D5=C0=DD=C5= =C5:

1). =E1=C4=D2=C5= =D3 =D3=C1=CA=D4=C1, =CB=CF=D4=CF=D2=D9=CA =CE=D5=D6=CE=CF =D0=D2=CF=C4= =D7=C9=C7=C1=D4=D8.
2). =EB=CC=C0=DE= =C5=D7=D9=C5 =D3=CC=CF=D7=C1, =D0=CF =CB=CF=D4=CF=D2=D9=CD =CE=D5=D6=CE= =CF =D0=D2=CF=C4=D7=C9=C7=C1=D4=D8 =F7=C1=DB =D3=C1=CA=D4 (=C9=CC=C9 =D1 = =D0=D2=C5=C4=CC=CF=D6=D5 =D3=D7=CF=CA =D7=C1=D2=C9=C1=CE=D4).
3). =F0=CF =CB= =C1=CB=CF=CD=D5 =D2=C5=C7=C9=CF=CE=D5 =C9/=C9=CC=C9 =C7=CF=D2=CF=C4=D5 = =CE=D5=D6=C5=CE =D7=D9=C8=CF=C4 =D7 =F4=EF=F0 =DA=C1=D0=D2=CF=D3=CF=D7.

=F7 =CF=D4=D7=C5= =D4=CE=CF=CD =D0=C9=D3=D8=CD=C5 =D1 =D0=D2=C9=DB=CC=C0 =F7=C1=CD =D0= =CF=C4=D2=CF=C2=CE=D9=CA =D0=CC=C1=CE =D2=C1=C2=CF=D4 =C9 =C9=C8 =D3= =D4=CF=C9=CD=CF=D3=D4=D8.

--GAV96QNX64T0-- From bfoster@redhat.com Wed Sep 16 05:50:26 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 8A54B7F37 for ; Wed, 16 Sep 2015 05:50:26 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 663968F8037 for ; Wed, 16 Sep 2015 03:50:26 -0700 (PDT) X-ASG-Debug-ID: 1442400624-04cbb005eb175490001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id ycNIrhD4EjKhvG24 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 16 Sep 2015 03:50:25 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 9D2E08C1DA; Wed, 16 Sep 2015 10:50:24 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8GAoOM8002581; Wed, 16 Sep 2015 06:50:24 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 2FA611201EB; Wed, 16 Sep 2015 06:50:23 -0400 (EDT) Date: Wed, 16 Sep 2015 06:50:23 -0400 From: Brian Foster To: Grant Keller Cc: xfs@oss.sgi.com, lczerner@redhat.com Subject: Re: rm Tainted warning after kernel update. Message-ID: <20150916105022.GA37016@bfoster.bfoster> X-ASG-Orig-Subj: Re: rm Tainted warning after kernel update. References: <55F718A1.10801@sonic.com> <20150915110042.GA21323@bfoster.bfoster> <55F89C76.4090808@sonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F89C76.4090808@sonic.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442400625 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 cc Lukas On Tue, Sep 15, 2015 at 03:32:22PM -0700, Grant Keller wrote: > On 09/15/2015 04:00 AM, Brian Foster wrote: > > On Mon, Sep 14, 2015 at 11:57:37AM -0700, Grant Keller wrote: > >> Hello, > >> > >> I have a server running Scientific Linux 6.7, and since updating to > >> kernel 2.6.32-573.3.1.el6.x86_64 the following error has begun appearing > >> in our message logs: > >> > >> Sep 14 11:43:03 localhost kernel: ------------[ cut here ]------------ > >> Sep 14 11:43:03 localhost kernel: WARNING: at fs/dcache.c:758 > >> d_delete+0x260/0x2c0() (Tainted: G W -- ------------ ) > >> Sep 14 11:43:03 localhost kernel: Hardware name: X7DB8 > >> Sep 14 11:43:03 localhost kernel: Modules linked in: nfsd nfs_acl > >> auth_rpcgss autofs4 lockd sunrpc p4_clockmod freq_table speedstep_lib > >> nf_conntrack_ftp iptable_mangle xt_comment nf_conntrack_ipv4 > >> nf_defrag_ipv4 xt_multiport iptable_filter ip_tables ip6t_REJECT > >> nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter > >> ip6_tables ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm > >> iw_cm ib_sa ib_mad ib_core ib_addr ipv6 xfs exportfs ppdev parport_pc > >> parport sg e1000e microcode serio_raw iTCO_wdt iTCO_vendor_support ixgbe > >> ptp pps_core mdio i2c_i801 lpc_ich mfd_core i5000_edac edac_core i5k_amb > >> ioatdma dca shpchp ext4 jbd2 mbcache sd_mod crc_t10dif 3w_9xxx pata_acpi > >> ata_generic ata_piix radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core > >> dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ipmi_msghandler] > >> Sep 14 11:43:03 localhost kernel: Pid: 15893, comm: rm Tainted: G > >> W -- ------------ 2.6.32-573.3.1.el6.x86_64 #1 > >> Sep 14 11:43:03 localhost kernel: Call Trace: > >> Sep 14 11:43:03 localhost kernel: [] ? > >> warn_slowpath_common+0x91/0xe0 > >> Sep 14 11:43:03 localhost kernel: [] ? > >> warn_slowpath_null+0x1a/0x20 > >> Sep 14 11:43:03 localhost kernel: [] ? > >> d_delete+0x260/0x2c0 > >> Sep 14 11:43:03 localhost kernel: [] ? vfs_rmdir+0xe8/0xf0 > >> Sep 14 11:43:03 localhost kernel: [] ? > >> do_rmdir+0x184/0x1f0 > >> Sep 14 11:43:03 localhost kernel: [] ? __fput+0x1a1/0x210 > >> Sep 14 11:43:03 localhost kernel: [] ? > >> audit_syscall_entry+0x1d7/0x200 > >> Sep 14 11:43:03 localhost kernel: [] ? > >> sys_unlinkat+0x2d/0x40 > >> Sep 14 11:43:03 localhost kernel: [] ? > >> system_call_fastpath+0x16/0x1b > >> Sep 14 11:43:03 localhost kernel: ---[ end trace 6080ec4a7ec5ec25 ]--- > >> > >> This happens when we are expiring older backups from the archives, so I > >> have quite a few of these. We have xfsprogs 3.1.1-16.el6.x86_64 > >> installed. Looking for advice on how to proceed. > >> > > This looks like something funky going on in the vfs. The warning is from > > unhash_offsprings() and it appears to be complaining about a refcount on > > a dentry that is a child of a directory being removed. It checks a > > refcount on a dentry in one loop and either drops it or moves it to > > another list for apparent deletion. The second iteration of the > > aforementioned list sees a refcount on an object that wasn't there > > before. > > > > I suspect this means something is going from 0->1 unexpectedly, but I'm > > not familiar enough with that code to grok why that shouldn't happen and > > how it could without reproducing it and digging into it from there. Have > > you identified an explicit reproducer? I assume files are simply being > > removed with 'rm -rf' here..? If so, does anything else have access to > > this directory structure (e.g., separate commands, a running backup > > application?) at the the time of removal. > There could be something else running, but I would have to investigate > the next time this happens. The rm -rf is called by our backup program > expiring older backups from the filesystem. The thing is, the > expirations happen on a nightly basis, but we don't always see these > warnings in the logs. On the nights we do, there are 1000+ warnings. > > > > Also, what kernel were you running before this started to occur? > 2.6.32-573.el6.x86_64 was the previous kernel. Interesting... there are only a few fs changes between this kernel and the current. One of them is this: 959c503 [fs] vfs: Unhash and evict unused children dentries after rmdir ... which actually introduces the unhash_offsprings() thing. I've cc'd Lukas who is probably more familiar with this code. FWIW, I suspect the more you can elaborate on what the backup application might be doing here (beyond just the rm -rf), the more likely this can be reproduced and resolved. Brian > > > > Brian > > > > > > -- > Grant Keller > System Operations > 707-237-2451 > grant.keller@sonic.com > From allenbearing_vip.163.com@mail8.fa.tsender.com Wed Sep 16 06:06:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=DEAR_SOMETHING,HTML_MESSAGE, MIME_BASE64_BLANKS,PRICES_ARE_AFFORDABLE autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id C80217F37 for ; Wed, 16 Sep 2015 06:06:05 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 797C88F8037 for ; Wed, 16 Sep 2015 04:06:02 -0700 (PDT) X-ASG-Debug-ID: 1442401551-04bdf04db31723b0001-NocioJ Received: from mail8.fa.tsender.com ([119.61.5.204]) by cuda.sgi.com with ESMTP id DpfiZ79rYfubK0M0 for ; Wed, 16 Sep 2015 04:05:51 -0700 (PDT) X-Barracuda-Envelope-From: allenbearing_vip.163.com@mail8.fa.tsender.com X-Barracuda-Apparent-Source-IP: 119.61.5.204 Received: from localhost.localdomain (unknown [118.102.24.44]) by mail8.fa.tsender.com (Postfix - by 360email.cn) with ESMTPA id 779062A1829 for ; Wed, 16 Sep 2015 18:26:08 +0800 (CST) X-DKIM: Sendmail DKIM Filter v2.8.3 mail8.fa.tsender.com 779062A1829 Date: Wed, 16 Sep 2015 19:05:47 +0800 To: xfs@oss.sgi.com From: Allen Bearing Reply-To: Allen Bearing Subject: Branded Bearings*Shanghai*Fast Delivery*Good Price Message-ID: X-ASG-Orig-Subj: Branded Bearings*Shanghai*Fast Delivery*Good Price X-Priority: 3 Precedence: bulk MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_d4a4c3016b4b399eaac7c610f8889ebb" X-Barracuda-Connect: UNKNOWN[119.61.5.204] X-Barracuda-Start-Time: 1442401551 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.10 X-Barracuda-Spam-Status: No, SCORE=1.10 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MV0713, BSF_SC5_MJ1963, HTML_MESSAGE, MIME_BASE64_BLANKS, PRICES_ARE_AFFORDABLE, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22595 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 PRICES_ARE_AFFORDABLE BODY: Message says that prices aren't too expensive 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 MIME_BASE64_BLANKS RAW: Extra blank lines in base64 encoding 0.50 BSF_SC0_MV0713 Custom rule MV0713 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 --b1_d4a4c3016b4b399eaac7c610f8889ebb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 6ZiF6K+76YCA6K6i5Li+5oqlICAgICAgIERlYXIgU2lyIG9yIE1hZGFtLMKgwqBBcmUgeW91IGlu dGVyZXN0ZWQgaW4KRkFHL1NLRi9OU0svVElNS0VOL0tPWU8vTlROIGJlYXJpbmdzP1dlIGhhdmUg YmVlbiBleHBvcnRlcnMgb2YgYmVhcmluZ3MgZnJvbQpTaGFuZ2hhaSBzaW5jZSAxOTkwLiBBbGwg cHJvZHVjdHMgYXJlIGdlbnVpbmUgYXQgYWZmb3JkYWJsZSBwcmljZXMuwqBTdXJmIG9mIG91cgp3 ZWI6IGh0dHA6Ly93d3cuYWxsZW4tYmVhcmluZy5jb20gZm9yIG1vcmUgaW5mb3JtYXRpb24uTXkg Y29udGFjdCBkZXRhaWxzIGFyZQpiZWxvdyBhbmQgSSB3b3VsZCBiZSBnbGFkIHRvIGhlYXIgZnJv bSB5b3UuwqBQbGVhc2UgZW1haWwgbWUgZm9yIGFueSBmdXJ0aGVyCmluZm9ybWF0aW9uIHlvdSBt aWdodCBuZWVkLkhvcGluZyBmb3IgeW91ciBlYXJseSByZXNwb25zZS7CoFRoYW5rIHlvdSBhbmQg YmVzdApyZWdhcmRzwqBBbGxlbiBXYW5nwqBTYWxlcyBNYW5hZ2VyU2hhbmdoYWkgQWxsZW4gQmVh cmluZyBDby4sTHRkQWRkOiBCYW9sdgpSb2FkLkJhb3NoYW4gRGlzY3RyaWN0LlNoYW5naGFpLlAu Ui5PZiBDaGluYVQuCjAwODYtMjEtNjIzNjYxMTlFbWFpbDphbGxlbmJlYXJpbmdAYWxsZW4tYmVh cmluZy5jb21Ta3lwZToKaHltb3RvcmN5Y2xlwqBXZWI6d3d3LmFsbGVuLWJlYXJpbmcuY29tIMKg IMKgd3d3LmZhZ2luYWJlYXJpbmdzLmNvbQ0K --b1_d4a4c3016b4b399eaac7c610f8889ebb Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgaWQ9ImRtdHh4Ij48dGFibGUgc3R5bGU9ImJvcmRlci1ib3R0b206I2NjY2NjYyAxcHggc29s aWQ7Ym9yZGVyLWxlZnQ6I2NjY2NjYyAxcHggc29saWQ7Ym9yZGVyLXRvcDojY2NjY2NjIDFweCBz b2xpZDtib3JkZXItcmlnaHQ6I2NjY2NjYyAxcHggc29saWQ7IiBjbGFzcz0ia2UtemVyb2JvcmRl ciIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI3NTAi IGFsaWduPSJjZW50ZXIiPjx0Ym9keT48dHI+PHRkIHN0eWxlPSJwYWRkaW5nLWxlZnQ6MTBweDtm b250LWZhbWlseTon5b6u6L2v6ZuF6buRJztmb250LXNpemU6MTJweDsiIGhlaWdodD0iMzAiPjxh IHN0eWxlPSJtYXJnaW4tcmlnaHQ6MTBweDsiICBocmVmPSJodHRwOi8vY291bnQuaXVybC53YW5n Lz92PWhwSU1QbnJmY3dSejZsOXl2NHVrZEdKakllNFl1WjBNZHlOYThUdFBFb3ZrSGRoVjhBME00 Vks3bmFyT0FiZWJZR01VUDJBcUtsaUtBWkdmal96VVpuXzBkWnR2S1B3NFZ2YnVCT21WcllfRm9C eUxyT0VZZmlpMmRlUXFqckEwM3dFNkJlNjA0N01MV1hfSjJuQ1czZGtEdDhXZi1SSjFDSlpVTGVR XzBrSEN5ZjVXMDkwS3BnNk8wN0RJdE5nN21kblJ5SmRBTG9EZTJxaExqdjk2WDIxS19LWVpQd0JG cEU2cnJaQzFxTFFQMVg5MkJyNWVZNEhkbkgyeF9adVdadkRqT0E1bllaYmxZbmNxNkN0SmdWODgx dGttdENzY3BiY0FJMkhUOEVRIiB0YXJnZXQ9Il9ibGFuayI+6ZiF6K+7PC9hPjxhIHN0eWxlPSJt YXJnaW4tcmlnaHQ6MTBweDsiICBocmVmPSJodHRwOi8vY291bnQuaXVybC53YW5nLz92PWhwSU1Q bnJmY3dSejZsOXl2NHVrZEdKakllNFl1WjBNZHlOYThUdFBFb3ZrSGRoVjhBME00Vks3bmFyT0Fi ZWJZR01VUDJBcUtsaUtBWkdmal96VVpoUmdaQ1llNmg2U1RnWTdJUVk1MUxJOFhmYzRUMGtIcDdy MzhyVkF2SXVoaW5XUlFnUnhRWHl3eVdsNU5wblMzeHhUTXhwOENjczhDVE1wOHlYQTRnNTRUSmst TklTRWMwcGRvRC1TRHBxV0pQMkQ1RGZxQUNrOTQwa002dzlZQl9sZlZLcGJLVndFNWowNEQ1QXg0 WkF4TFJwV2lIcWFYQktMWTBMc0hpa2F5aEZibjk4OVd6OGdNX0tKM0FuNjVQQ3ZjOXIwR2wwdWY5 djFacXBVT0ZFYlQ0QnNiSVhreV9IaXliRzVWNmJWMXZ3MDZwQkpzNHl6X2lQUHFaTjVfUSIgdGFy Z2V0PSJfYmxhbmsiPumAgOiuojwvYT48YSBzdHlsZT0ibWFyZ2luLXJpZ2h0OjEwcHg7IiAgaHJl Zj0iaHR0cDovL2NvdW50Lml1cmwud2FuZy8/dj1ocElNUG5yZmN3Uno2bDl5djR1a2RHSmpJZTRZ dVowTWR5TmE4VHRQRW92a0hkaFY4QTBNNFZLN25hck9BYmViWUdNVVAyQXFLbGlLQVpHZmpfelVa bGFKNW91a0dyb0lJUHplekdOQ0xrUkJsV0Rqc0hBenBFRFRjQXIxYnpGQW4tT3NMYjl3YURaN3hz NG8ybnhZc2hSal9meno5RHByZVlhcGNmVVJnVklLSEc1RlhCNHpWV2V1bDZMZmlnZU4yQWZzdmw0 UGJMRE9aazJZanowYkhrMG9iQThGUXViSDRNRzVVZEZEd3FRaXFqVW1MRTZfZHF6anVMRnliT0NJ aXJtVE9rS25FZlRNWkh5QnlKUUJtTllTLXR5YlRwYTNVZEYzZEl1eV93MWloUm9OUjJVSDBTZ2dx YVlrSHNCWkpsZ2JQZXQ0TXZaYXlVbW9HWW5sN1EiIHRhcmdldD0iX2JsYW5rIj7kuL7miqU8L2E+ IDxzcGFuIGlkPSJzaGFyZSI+PGEgY2xhc3M9ImNtdFNoYXJlV3JhcF9pY28iICBocmVmPSJodHRw Oi8vY291bnQuaXVybC53YW5nLz92PWhwSU1QbnJmY3dSejZsOXl2NHVrZEdKakllNFl1WjBNZHlO YThUdFBFb3ZrSGRoVjhBME00Vks3bmFyT0FiZWJZR01VUDJBcUtsaUtBWkdmal96VVpwMVFRM2ht bHZUVVByaEpINVJtZkJLcTdrM1VwWmg5a3NuOEZGZ3ZfWFNpd0RfUHNTWmVDcVpuaG45RTNpMGR3 UldIZjJGV0diUndGNEl5aEdJc3RDeFRVOTNMVnBaWUw4U2pvU1lRNjFOZzIxY0VRV0hFb00wLXBr N3FHZW5BakQ4RGZKelJLSTlTTG9BWmNMTzRlSUxkLUNIR3FDTmJtYjZiTVBCZ09yQmlCU2UyZm10 MzREcEJ0UkZRakQ2VDRCc0wxb3RaTjg0clVheFdUeUNmMzRybUM4cEo5dEZTNEhUdkpWcE5MWDZa UUc5WWZMNDRkVEpFTU1YSDBSV0JudzNKNEFtTG9zSjB3RVMtbjlkLUtnVi1iOHNGYW95Vl9qeGRh YlZvRkR2c2RfVEpWckViOC1IRGFJcEVOOGlKYl9VX0JZcm96aFI4RWtFbVhic3dNN1UiIHRhcmdl dD0iX2JsYW5rIiBkYXRhX3R5cGU9InFxIj48aW1nIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjpib3R0 b207IiBib3JkZXI9IjAiIGFsdD0iUVHlpb3lj4siIHNyYz0iaHR0cDovL2FwcC5pdXJsLndhbmcv dGhlbWVzLzM2MGVtYWlsL2ltYWdlcy9xcS5qcGciIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiI+PC9h PiA8YSBjbGFzcz0iY210U2hhcmVXcmFwX2ljbyIgIGhyZWY9Imh0dHA6Ly9jb3VudC5pdXJsLndh bmcvP3Y9aHBJTVBucmZjd1J6Nmw5eXY0dWtkR0pqSWU0WXVaME1keU5hOFR0UEVvdmtIZGhWOEEw TTRWSzduYXJPQWJlYllHTVVQMkFxS2xpS0FaR2ZqX3pVWm9uakJiZWdjUXd5c1JwUnZlWmZuWHpi UndHNHJ5WTVQdzB6cmR0bjdmSHZPc05scnNQQTAyZnR1WldfeEd6NkZ6b29rclN5OF84Q1hvUXNk bHBBbk8yY3JsWlYyUHkyRmRMNTBBbk0tNnhpZnE1Y203cVhIcVRRcVEtWThHdGRCUk9Rb0ZPdEtN d2ZLeWtLU1lhNFc1a2NydEhjMm1MZXNTbDJ6YmphcF9ZTkNaZ2ZYTk12T0FtaHJGaWViSzJaZ21Z MWprZUgxYVhpTnVUcU1KUzZJVC0yWGw1RE1PZm9oNEllQUh4NzZYcF9yWkQ3NzZNd3drWTgyRTJI dzI3dkdtcG8tRXlwSUFBV25mRzcwa3JUQWRNeW9mUGdxSXJ3aVlLZXdEdjRWM1J0YnB4Uk9UV0xh bDV6N3VlalQyYmlMTjJQV183SXl6cXlYVnQ4V1B2VWJRbyIgdGFyZ2V0PSJfYmxhbmsiIGRhdGFf dHlwZT0ic2luYSI+PGltZyBzdHlsZT0idmVydGljYWwtYWxpZ246Ym90dG9tOyIgYm9yZGVyPSIw IiBhbHQ9IuaWsOa1quW+ruWNmiIgc3JjPSJodHRwOi8vYXBwLml1cmwud2FuZy90aGVtZXMvMzYw ZW1haWwvaW1hZ2VzL3NpbmEuanBnIiB3aWR0aD0iMTYiIGhlaWdodD0iMTYiPjwvYT4gPGEgY2xh c3M9ImNtdFNoYXJlV3JhcF9pY28iICBocmVmPSJodHRwOi8vY291bnQuaXVybC53YW5nLz92PWhw SU1QbnJmY3dSejZsOXl2NHVrZEdKakllNFl1WjBNZHlOYThUdFBFb3ZrSGRoVjhBME00Vks3bmFy T0FiZWJZR01VUDJBcUtsaUtBWkdmal96VVpqZTk0dEFtd3E3WldkeEgxdS1rSFczbm9UOG5tSDNT d2JKOEFWVXpzOG1FUjlocC11eF9RTm9KMEh4LU1XRjY3TGtTR2tKSy1SS3VzTDVTQnpLYkNzcEpm TFk0RFBydy1xQW84LWE1UHk5TkNuM0hSYnpRSnRSWFBNM2xTa3ZkMjJycTdCelQ2SXVpSFA2Qklr VmJ4Zl9YMHEzQVBlSG03dTA4dGdmZ09oSGNaTnNhTnU3dWRlN1JRQjZLckRpZDNObjRYVkJnLUpi eF9yWEZWb2Q0ckMySFM5UW0wNkZVVG9WQlc1Z2FqMlFoR0ttWUhIT1YzRXJhS2liVzByS1NyeWxI S1VfVWtqdl9OYThkdDN0eDB6cXI2Sk5YdW10QWVGeC1IRGRTNDRZczY5WERCamVrWmw5U2hiLUo1 Zy1LaDROOHM0cFkwek1heFlCOUwzc2tyX1kiIHRhcmdldD0iX2JsYW5rIiBkYXRhX3R5cGU9Imth aXhpbiI+PGltZyBzdHlsZT0idmVydGljYWwtYWxpZ246Ym90dG9tOyIgYm9yZGVyPSIwIiBhbHQ9 IuW8gOW/g+e9kSIgc3JjPSJodHRwOi8vYXBwLml1cmwud2FuZy90aGVtZXMvMzYwZW1haWwvaW1h Z2VzL2thaXhpbi5qcGciIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiI+PC9hPiA8YSBjbGFzcz0iY210 U2hhcmVXcmFwX2ljbyIgIGhyZWY9Imh0dHA6Ly9jb3VudC5pdXJsLndhbmcvP3Y9aHBJTVBucmZj d1J6Nmw5eXY0dWtkR0pqSWU0WXVaME1keU5hOFR0UEVvdmtIZGhWOEEwTTRWSzduYXJPQWJlYllH TVVQMkFxS2xpS0FaR2ZqX3pVWm8yMkttWTNwMTdfM2pVTnhKaXZyUlhRWGxESHFKUk50TW1xekZ1 UVRLS0ctVUVweWQwMUxrNklSaEJPZlVwUWJrcklQcVlRbm96cUZYS0xCQnVsQkZvUm1CcVp2Q285 cUhvSkpHcm0xZUtlQUo5TENrV20yMUJzLVQyLTktQWw5dDhCT2dYdXRPT3pDMWxfeWRwd2x0M1pB N2ZGbl9rU2RRaVdWQzNrUDlKQndzbi1WdFBkQ3FZT2p0T3d5TFRZTzVuWjBjaVhRQzZBM3Rxb1M0 N19lbDl0U3Z5bUdUOEFSYVJPcTYyUXRhaTBEOVZfZGdhLVhtT0IzWng5c2YyYmxnQ0U5YVBNWjRV SjBFNnhEN3FfdkYxWnhVMERIbU1nUTl3LXlHTVJQV3p2Y2kzX1lDZVMwU1o2M3FKX293MXBpVHFt bGE3NlhjdE5wbTh2TnllUElaOCIgdGFyZ2V0PSJfYmxhbmsiIGRhdGFfdHlwZT0icmVucmVuIj48 aW1nIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjpib3R0b207IiBib3JkZXI9IjAiIGFsdD0i5Lq65Lq6 572RIiBzcmM9Imh0dHA6Ly9hcHAuaXVybC53YW5nL3RoZW1lcy8zNjBlbWFpbC9pbWFnZXMvcmVu cmVuLmpwZyIgd2lkdGg9IjE2IiBoZWlnaHQ9IjE2Ij48L2E+IDxhIGNsYXNzPSJjbXRTaGFyZVdy YXBfaWNvIiAgaHJlZj0iaHR0cDovL2NvdW50Lml1cmwud2FuZy8/dj1ocElNUG5yZmN3Uno2bDl5 djR1a2RHSmpJZTRZdVowTWR5TmE4VHRQRW92a0hkaFY4QTBNNFZLN25hck9BYmViWUdNVVAyQXFL bGlLQVpHZmpfelVaclpvX05GNU8wODdpbVVfS1cyZUlBQVlOZGV5ZzY2NDFEUFBoQm9vYzAtSFBn SFZFeGhSalZWaDR3S1BOUTQteU9tTzUyOEpqazhiWnJhOXc4bk9MNWJrMndna2s0ZUxfMTA0bzYw RWw3OHkzMzNmTEI0OXZ1RFYtYjJieDZ3bElEMG16Q3Q2eGc4SmkyWlhySDY1NXp3RzF2S1ZHLUQ2 ZTFSNktyeFhfdzdPZjd3elV0ZV9Yd3FWeWlBOVE3bWllNy1CaEVxNUQxSXk5WU1LQjlqcEZtM0Zp NG1vSW55RG9ZaFZtZ29VOGZnVFdpdUo1bHZHY1g4WXVrZU5RUllpNFdJLUVZX2tKeE5vYmwtd1Bf a19CZEtoX1JDWmw2eFVoWnJDa05ydmFydnoiIHRhcmdldD0iX2JsYW5rIiBkYXRhX3R5cGU9ImRv dWJhbiI+PGltZyBzdHlsZT0idmVydGljYWwtYWxpZ246Ym90dG9tOyIgYm9yZGVyPSIwIiBhbHQ9 IuixhueTo+e9kSIgc3JjPSJodHRwOi8vYXBwLml1cmwud2FuZy90aGVtZXMvMzYwZW1haWwvaW1h Z2VzL2RvdWJhbi5qcGciIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiI+PC9hPiA8L3NwYW4+PC90ZD48 L3RyPjwvdGJvZHk+PC90YWJsZT48L3A+PGRpdiBpZD0idGVtcGxhdGUiPjxwPjxicj48L3A+PHA+ PGltZyBzdHlsZT0id2lkdGg6Njg5cHg7aGVpZ2h0OjI0N3B4OyIgYWx0PSIiIHNyYz0iaHR0cDov L2FwcC5pdXJsLndhbmcvYXR0YWNoZWQvdXNlcnMvY2UwMzIwYTUzMTJmMTIyYTVjYzE2NWY2MWE1 OTdiYjAvaW1hZ2VzLzIwMTQwNC8yMDE0MDQwODEwMjgwNF80NDI5MS5qcGciIHdpZHRoPSI0NDAi IGhlaWdodD0iMTUxIiBkYXRhLWtlLXNyYz0iaHR0cDovL2FwcC5pdXJsLndhbmcvYXR0YWNoZWQv dXNlcnMvY2UwMzIwYTUzMTJmMTIyYTVjYzE2NWY2MWE1OTdiYjAvaW1hZ2VzLzIwMTQwNC8yMDE0 MDQwODEwMjgwNF80NDI5MS5qcGciPiA8L3A+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MjFweDtm b250LWZhbWlseTpTaW1TdW47d2hpdGUtc3BhY2U6bm9ybWFsO2NvbG9yOiMyMjIyMjI7Zm9udC1z aXplOjE0cHg7Ij48cD48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDAwMDsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTRweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpzaW1zdW47Ij48c3BhbiBz dHlsZT0id2hpdGUtc3BhY2U6bm9ybWFsO2ZvbnQtZmFtaWx5OuWui+S9kztiYWNrZ3JvdW5kLWNv bG9yOiNGRkZGRkY7Zm9udC1zaXplOjE0cHg7bGluZS1oZWlnaHQ6MjNweDsiPkRlYXIgU2lyIG9y IE1hZGFtLCZuYnNwOzxicj4mbmJzcDs8YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFj ZTpub3JtYWw7YmFja2dyb3VuZC1jb2xvcjojRkZGRkZGO2ZvbnQtZmFtaWx5OuWui+S9kztmb250 LXNpemU6MTRweDtsaW5lLWhlaWdodDoyM3B4OyI+QXJlIHlvdSBpbnRlcmVzdGVkIGluIEZBRy9T S0YvTlNLL1RJTUtFTi9LT1lPL05UTiBiZWFyaW5ncz88L3NwYW4+PHNwYW4gc3R5bGU9IndoaXRl LXNwYWNlOm5vcm1hbDtmb250LWZhbWlseTrlrovkvZM7YmFja2dyb3VuZC1jb2xvcjojRkZGRkZG O2ZvbnQtc2l6ZToxNHB4O2xpbmUtaGVpZ2h0OjIzcHg7Ij48YnI+PC9zcGFuPjxzcGFuIHN0eWxl PSJ3aGl0ZS1zcGFjZTpub3JtYWw7Zm9udC1mYW1pbHk65a6L5L2TO2JhY2tncm91bmQtY29sb3I6 I0ZGRkZGRjtmb250LXNpemU6MTRweDtsaW5lLWhlaWdodDoyM3B4OyI+PGJyPjxicj5XZSBoYXZl IGJlZW4gZXhwb3J0ZXJzIG9mIGJlYXJpbmdzIGZyb20gU2hhbmdoYWkgc2luY2UgMTk5MC4gQWxs IHByb2R1Y3RzIGFyZSBnZW51aW5lIGF0IGFmZm9yZGFibGUgcHJpY2VzLiZuYnNwOzxicj5TdXJm IG9mIG91ciB3ZWI6IGh0dHA6Ly93d3cuYWxsZW4tYmVhcmluZy5jb20gZm9yIG1vcmUgaW5mb3Jt YXRpb24uPGJyPjxicj48YnI+TXkgY29udGFjdCBkZXRhaWxzIGFyZSBiZWxvdyBhbmQgSSB3b3Vs ZCBiZSBnbGFkIHRvIGhlYXIgZnJvbSB5b3UuJm5ic3A7PGJyPjxicj48YnI+PC9zcGFuPjxzcGFu IHN0eWxlPSJ3aGl0ZS1zcGFjZTpub3JtYWw7YmFja2dyb3VuZC1jb2xvcjojRkZGRkZGO2ZvbnQt ZmFtaWx5OuWui+S9kztmb250LXNpemU6MTRweDtsaW5lLWhlaWdodDoyM3B4OyI+UGxlYXNlIGVt YWlsIG1lIGZvciBhbnkgZnVydGhlciBpbmZvcm1hdGlvbiB5b3UgbWlnaHQgbmVlZC48L3NwYW4+ PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOm5vcm1hbDtmb250LWZhbWlseTrlrovkvZM7YmFja2dy b3VuZC1jb2xvcjojRkZGRkZGO2ZvbnQtc2l6ZToxNHB4O2xpbmUtaGVpZ2h0OjIzcHg7Ij48YnI+ PC9zcGFuPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpub3JtYWw7Zm9udC1mYW1pbHk65a6L5L2T O2JhY2tncm91bmQtY29sb3I6I0ZGRkZGRjtmb250LXNpemU6MTRweDtsaW5lLWhlaWdodDoyM3B4 OyI+PGJyPjxicj48L3NwYW4+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOm5vcm1hbDtiYWNrZ3Jv dW5kLWNvbG9yOiNGRkZGRkY7Zm9udC1mYW1pbHk65a6L5L2TO2ZvbnQtc2l6ZToxNHB4O2xpbmUt aGVpZ2h0OjIzcHg7Ij5Ib3BpbmcgZm9yIHlvdXIgZWFybHkgcmVzcG9uc2UuJm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpub3JtYWw7Zm9udC1mYW1pbHk65a6L5L2TO2JhY2tn cm91bmQtY29sb3I6I0ZGRkZGRjtmb250LXNpemU6MTRweDtsaW5lLWhlaWdodDoyM3B4OyI+PGJy Pjwvc3Bhbj48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6bm9ybWFsO2ZvbnQtZmFtaWx5OuWui+S9 kztiYWNrZ3JvdW5kLWNvbG9yOiNGRkZGRkY7Zm9udC1zaXplOjE0cHg7bGluZS1oZWlnaHQ6MjNw eDsiPjxicj48YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpub3JtYWw7YmFja2dy b3VuZC1jb2xvcjojRkZGRkZGO2ZvbnQtZmFtaWx5OuWui+S9kztmb250LXNpemU6MTRweDtsaW5l LWhlaWdodDoyM3B4OyI+VGhhbmsgeW91IGFuZCBiZXN0IHJlZ2FyZHMmbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9IndoaXRlLXNwYWNlOm5vcm1hbDtmb250LWZhbWlseTrlrovkvZM7YmFja2dyb3Vu ZC1jb2xvcjojRkZGRkZGO2ZvbnQtc2l6ZToxNHB4O2xpbmUtaGVpZ2h0OjIzcHg7Ij48YnI+PC9z cGFuPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpub3JtYWw7Zm9udC1mYW1pbHk65a6L5L2TO2Jh Y2tncm91bmQtY29sb3I6I0ZGRkZGRjtmb250LXNpemU6MTRweDtsaW5lLWhlaWdodDoyM3B4OyI+ PGJyPjxicj5BbGxlbiBXYW5nJm5ic3A7PGJyPlNhbGVzIE1hbmFnZXI8YnI+U2hhbmdoYWkgQWxs ZW4gQmVhcmluZyBDby4sTHRkPGJyPkFkZDogQmFvbHYgUm9hZC5CYW9zaGFuIERpc2N0cmljdC5T aGFuZ2hhaS5QLlIuT2YgQ2hpbmE8YnI+VC4gMDA4Ni0yMS02MjM2NjExOTxicj5FbWFpbDphbGxl bmJlYXJpbmdAYWxsZW4tYmVhcmluZy5jb208YnI+U2t5cGU6IGh5bW90b3JjeWNsZSZuYnNwOzxi cj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAwMDAwOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OnNpbXN1bjsiPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpub3JtYWw7Zm9udC1mYW1p bHk65a6L5L2TO2JhY2tncm91bmQtY29sb3I6I0ZGRkZGRjtmb250LXNpemU6MTRweDtsaW5lLWhl aWdodDoyM3B4OyI+V2ViOnd3dy5hbGxlbi1iZWFyaW5nLmNvbSAmbmJzcDsgJm5ic3A7PC9zcGFu Pjwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiNGRkZG RkY7Zm9udC1mYW1pbHk65a6L5L2TO2xpbmUtaGVpZ2h0OjIzcHg7Y29sb3I6IzAwMDAwMDsiPnd3 dy5mYWdpbmFiZWFyaW5ncy5jb208L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAw MDAwOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OnNpbXN1bjsiPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpub3JtYWw7Zm9udC1mYW1pbHk6 5a6L5L2TO2JhY2tncm91bmQtY29sb3I6I0ZGRkZGRjtmb250LXNpemU6MTRweDtsaW5lLWhlaWdo dDoyM3B4OyI+PGJyPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3A+PHAgc3R5bGU9Im1h cmdpbjowcHggMGNtO3doaXRlLXNwYWNlOm5vcm1hbDtjb2xvcjojMjIyMjIyO2ZvbnQtc2l6ZTox NHB4O3BhZGRpbmc6MHB4O2xpbmUtaGVpZ2h0Om5vcm1hbDtmb250LWZhbWlseTondGltZXMgbmV3 IHJvbWFuJzsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpzaW1zdW47Ij48L3NwYW4+PC9wPjwv ZGl2PjxwIHN0eWxlPSJwYWRkaW5nLWJvdHRvbTowcHg7bGluZS1oZWlnaHQ6bm9ybWFsO21hcmdp bjowcHggMGNtO3BhZGRpbmctbGVmdDowcHg7cGFkZGluZy1yaWdodDowcHg7Zm9udC1mYW1pbHk6 J3RpbWVzIG5ldyByb21hbic7d2hpdGUtc3BhY2U6bm9ybWFsO2ZvbnQtc2l6ZToxNHB4O3BhZGRp bmctdG9wOjBweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpzaW1zdW47Ij48L3NwYW4+PC9w PjwvZGl2PjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly9jb3VudC5pdXJsLndhbmcvP3Y9MW8x TDN3SURuLVRqSF9GZG1HZHpWZFRHcjZqaEIzVkJMbmI3VEdrVTAyOWF2Tl83aFhsT1lpWW4xTEI5 U2RMX3dYMGJXNF9xRHVvb0pXcGpiZlRPZEEiIHdpZHRoPSIxIiBoZWlnaHQ9IjEiIC8+ --b1_d4a4c3016b4b399eaac7c610f8889ebb-- From lczerner@redhat.com Wed Sep 16 06:13:31 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id F30817F37 for ; Wed, 16 Sep 2015 06:13:30 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id D3246304051 for ; Wed, 16 Sep 2015 04:13:27 -0700 (PDT) X-ASG-Debug-ID: 1442402006-04cbb005eb175e10001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id LYI83hxmMVt2G1eE (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 16 Sep 2015 04:13:26 -0700 (PDT) X-Barracuda-Envelope-From: lczerner@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 15A2CC0B9195; Wed, 16 Sep 2015 11:13:26 +0000 (UTC) Received: from vpn1-4-248.ams2.redhat.com (vpn1-4-248.ams2.redhat.com [10.36.4.248]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8GBDLXA016270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Sep 2015 07:13:24 -0400 Date: Wed, 16 Sep 2015 13:13:20 +0200 (CEST) From: =?ISO-8859-15?Q?Luk=E1=A8_Czerner?= X-X-Sender: lczerner@localhost.localdomain To: Brian Foster cc: Grant Keller , xfs@oss.sgi.com Subject: Re: rm Tainted warning after kernel update. In-Reply-To: <20150916105022.GA37016@bfoster.bfoster> X-ASG-Orig-Subj: Re: rm Tainted warning after kernel update. Message-ID: References: <55F718A1.10801@sonic.com> <20150915110042.GA21323@bfoster.bfoster> <55F89C76.4090808@sonic.com> <20150916105022.GA37016@bfoster.bfoster> 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.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442402006 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, 16 Sep 2015, Brian Foster wrote: > Date: Wed, 16 Sep 2015 06:50:23 -0400 > From: Brian Foster > To: Grant Keller > Cc: lczerner@redhat.com, xfs@oss.sgi.com > Subject: Re: rm Tainted warning after kernel update. > > cc Lukas > > On Tue, Sep 15, 2015 at 03:32:22PM -0700, Grant Keller wrote: > > On 09/15/2015 04:00 AM, Brian Foster wrote: > > > On Mon, Sep 14, 2015 at 11:57:37AM -0700, Grant Keller wrote: > > >> Hello, > > >> > > >> I have a server running Scientific Linux 6.7, and since updating to > > >> kernel 2.6.32-573.3.1.el6.x86_64 the following error has begun appearing > > >> in our message logs: > > >> > > >> Sep 14 11:43:03 localhost kernel: ------------[ cut here ]------------ > > >> Sep 14 11:43:03 localhost kernel: WARNING: at fs/dcache.c:758 > > >> d_delete+0x260/0x2c0() (Tainted: G W -- ------------ ) > > >> Sep 14 11:43:03 localhost kernel: Hardware name: X7DB8 > > >> Sep 14 11:43:03 localhost kernel: Modules linked in: nfsd nfs_acl > > >> auth_rpcgss autofs4 lockd sunrpc p4_clockmod freq_table speedstep_lib > > >> nf_conntrack_ftp iptable_mangle xt_comment nf_conntrack_ipv4 > > >> nf_defrag_ipv4 xt_multiport iptable_filter ip_tables ip6t_REJECT > > >> nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter > > >> ip6_tables ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm > > >> iw_cm ib_sa ib_mad ib_core ib_addr ipv6 xfs exportfs ppdev parport_pc > > >> parport sg e1000e microcode serio_raw iTCO_wdt iTCO_vendor_support ixgbe > > >> ptp pps_core mdio i2c_i801 lpc_ich mfd_core i5000_edac edac_core i5k_amb > > >> ioatdma dca shpchp ext4 jbd2 mbcache sd_mod crc_t10dif 3w_9xxx pata_acpi > > >> ata_generic ata_piix radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core > > >> dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ipmi_msghandler] > > >> Sep 14 11:43:03 localhost kernel: Pid: 15893, comm: rm Tainted: G > > >> W -- ------------ 2.6.32-573.3.1.el6.x86_64 #1 > > >> Sep 14 11:43:03 localhost kernel: Call Trace: > > >> Sep 14 11:43:03 localhost kernel: [] ? > > >> warn_slowpath_common+0x91/0xe0 > > >> Sep 14 11:43:03 localhost kernel: [] ? > > >> warn_slowpath_null+0x1a/0x20 > > >> Sep 14 11:43:03 localhost kernel: [] ? > > >> d_delete+0x260/0x2c0 > > >> Sep 14 11:43:03 localhost kernel: [] ? vfs_rmdir+0xe8/0xf0 > > >> Sep 14 11:43:03 localhost kernel: [] ? > > >> do_rmdir+0x184/0x1f0 > > >> Sep 14 11:43:03 localhost kernel: [] ? __fput+0x1a1/0x210 > > >> Sep 14 11:43:03 localhost kernel: [] ? > > >> audit_syscall_entry+0x1d7/0x200 > > >> Sep 14 11:43:03 localhost kernel: [] ? > > >> sys_unlinkat+0x2d/0x40 > > >> Sep 14 11:43:03 localhost kernel: [] ? > > >> system_call_fastpath+0x16/0x1b > > >> Sep 14 11:43:03 localhost kernel: ---[ end trace 6080ec4a7ec5ec25 ]--- > > >> > > >> This happens when we are expiring older backups from the archives, so I > > >> have quite a few of these. We have xfsprogs 3.1.1-16.el6.x86_64 > > >> installed. Looking for advice on how to proceed. > > >> > > > This looks like something funky going on in the vfs. The warning is from > > > unhash_offsprings() and it appears to be complaining about a refcount on > > > a dentry that is a child of a directory being removed. It checks a > > > refcount on a dentry in one loop and either drops it or moves it to > > > another list for apparent deletion. The second iteration of the > > > aforementioned list sees a refcount on an object that wasn't there > > > before. > > > > > > I suspect this means something is going from 0->1 unexpectedly, but I'm > > > not familiar enough with that code to grok why that shouldn't happen and > > > how it could without reproducing it and digging into it from there. Have > > > you identified an explicit reproducer? I assume files are simply being > > > removed with 'rm -rf' here..? If so, does anything else have access to > > > this directory structure (e.g., separate commands, a running backup > > > application?) at the the time of removal. > > There could be something else running, but I would have to investigate > > the next time this happens. The rm -rf is called by our backup program > > expiring older backups from the filesystem. The thing is, the > > expirations happen on a nightly basis, but we don't always see these > > warnings in the logs. On the nights we do, there are 1000+ warnings. > > > > > > Also, what kernel were you running before this started to occur? > > 2.6.32-573.el6.x86_64 was the previous kernel. > > Interesting... there are only a few fs changes between this kernel and > the current. One of them is this: > > 959c503 [fs] vfs: Unhash and evict unused children dentries after rmdir > > ... which actually introduces the unhash_offsprings() thing. I've cc'd > Lukas who is probably more familiar with this code. > > FWIW, I suspect the more you can elaborate on what the backup > application might be doing here (beyond just the rm -rf), the more > likely this can be reproduced and resolved. Hi the lockdep warning should be fixed in the recent rhel6 kernel. Sorry about that. -Lukas > > Brian > > > > > > > Brian > > > > > > > > > > -- > > Grant Keller > > System Operations > > 707-237-2451 > > grant.keller@sonic.com > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From bfoster@redhat.com Wed Sep 16 06:42:34 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id B42807F37 for ; Wed, 16 Sep 2015 06:42:34 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 6F205304053 for ; Wed, 16 Sep 2015 04:42:34 -0700 (PDT) X-ASG-Debug-ID: 1442403752-04bdf04db4173250001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id syEZLWjMLkEH0wyi (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 16 Sep 2015 04:42:33 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 8E3298EA2F; Wed, 16 Sep 2015 11:42:32 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8GBgWNA001903; Wed, 16 Sep 2015 07:42:32 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 434A71201EB; Wed, 16 Sep 2015 07:42:31 -0400 (EDT) Date: Wed, 16 Sep 2015 07:42:31 -0400 From: Brian Foster To: =?utf-8?B?THVrw6HFoQ==?= Czerner Cc: Grant Keller , xfs@oss.sgi.com Subject: Re: rm Tainted warning after kernel update. Message-ID: <20150916114230.GB37016@bfoster.bfoster> X-ASG-Orig-Subj: Re: rm Tainted warning after kernel update. References: <55F718A1.10801@sonic.com> <20150915110042.GA21323@bfoster.bfoster> <55F89C76.4090808@sonic.com> <20150916105022.GA37016@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442403753 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 16, 2015 at 01:13:20PM +0200, Lukáš Czerner wrote: > On Wed, 16 Sep 2015, Brian Foster wrote: > > > Date: Wed, 16 Sep 2015 06:50:23 -0400 > > From: Brian Foster > > To: Grant Keller > > Cc: lczerner@redhat.com, xfs@oss.sgi.com > > Subject: Re: rm Tainted warning after kernel update. > > > > cc Lukas > > > > On Tue, Sep 15, 2015 at 03:32:22PM -0700, Grant Keller wrote: > > > On 09/15/2015 04:00 AM, Brian Foster wrote: > > > > On Mon, Sep 14, 2015 at 11:57:37AM -0700, Grant Keller wrote: > > > >> Hello, > > > >> > > > >> I have a server running Scientific Linux 6.7, and since updating to > > > >> kernel 2.6.32-573.3.1.el6.x86_64 the following error has begun appearing > > > >> in our message logs: > > > >> > > > >> Sep 14 11:43:03 localhost kernel: ------------[ cut here ]------------ > > > >> Sep 14 11:43:03 localhost kernel: WARNING: at fs/dcache.c:758 > > > >> d_delete+0x260/0x2c0() (Tainted: G W -- ------------ ) > > > >> Sep 14 11:43:03 localhost kernel: Hardware name: X7DB8 > > > >> Sep 14 11:43:03 localhost kernel: Modules linked in: nfsd nfs_acl > > > >> auth_rpcgss autofs4 lockd sunrpc p4_clockmod freq_table speedstep_lib > > > >> nf_conntrack_ftp iptable_mangle xt_comment nf_conntrack_ipv4 > > > >> nf_defrag_ipv4 xt_multiport iptable_filter ip_tables ip6t_REJECT > > > >> nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter > > > >> ip6_tables ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm > > > >> iw_cm ib_sa ib_mad ib_core ib_addr ipv6 xfs exportfs ppdev parport_pc > > > >> parport sg e1000e microcode serio_raw iTCO_wdt iTCO_vendor_support ixgbe > > > >> ptp pps_core mdio i2c_i801 lpc_ich mfd_core i5000_edac edac_core i5k_amb > > > >> ioatdma dca shpchp ext4 jbd2 mbcache sd_mod crc_t10dif 3w_9xxx pata_acpi > > > >> ata_generic ata_piix radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core > > > >> dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ipmi_msghandler] > > > >> Sep 14 11:43:03 localhost kernel: Pid: 15893, comm: rm Tainted: G > > > >> W -- ------------ 2.6.32-573.3.1.el6.x86_64 #1 > > > >> Sep 14 11:43:03 localhost kernel: Call Trace: > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > >> warn_slowpath_common+0x91/0xe0 > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > >> warn_slowpath_null+0x1a/0x20 > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > >> d_delete+0x260/0x2c0 > > > >> Sep 14 11:43:03 localhost kernel: [] ? vfs_rmdir+0xe8/0xf0 > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > >> do_rmdir+0x184/0x1f0 > > > >> Sep 14 11:43:03 localhost kernel: [] ? __fput+0x1a1/0x210 > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > >> audit_syscall_entry+0x1d7/0x200 > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > >> sys_unlinkat+0x2d/0x40 > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > >> system_call_fastpath+0x16/0x1b > > > >> Sep 14 11:43:03 localhost kernel: ---[ end trace 6080ec4a7ec5ec25 ]--- > > > >> > > > >> This happens when we are expiring older backups from the archives, so I > > > >> have quite a few of these. We have xfsprogs 3.1.1-16.el6.x86_64 > > > >> installed. Looking for advice on how to proceed. > > > >> > > > > This looks like something funky going on in the vfs. The warning is from > > > > unhash_offsprings() and it appears to be complaining about a refcount on > > > > a dentry that is a child of a directory being removed. It checks a > > > > refcount on a dentry in one loop and either drops it or moves it to > > > > another list for apparent deletion. The second iteration of the > > > > aforementioned list sees a refcount on an object that wasn't there > > > > before. > > > > > > > > I suspect this means something is going from 0->1 unexpectedly, but I'm > > > > not familiar enough with that code to grok why that shouldn't happen and > > > > how it could without reproducing it and digging into it from there. Have > > > > you identified an explicit reproducer? I assume files are simply being > > > > removed with 'rm -rf' here..? If so, does anything else have access to > > > > this directory structure (e.g., separate commands, a running backup > > > > application?) at the the time of removal. > > > There could be something else running, but I would have to investigate > > > the next time this happens. The rm -rf is called by our backup program > > > expiring older backups from the filesystem. The thing is, the > > > expirations happen on a nightly basis, but we don't always see these > > > warnings in the logs. On the nights we do, there are 1000+ warnings. > > > > > > > > Also, what kernel were you running before this started to occur? > > > 2.6.32-573.el6.x86_64 was the previous kernel. > > > > Interesting... there are only a few fs changes between this kernel and > > the current. One of them is this: > > > > 959c503 [fs] vfs: Unhash and evict unused children dentries after rmdir > > > > ... which actually introduces the unhash_offsprings() thing. I've cc'd > > Lukas who is probably more familiar with this code. > > > > FWIW, I suspect the more you can elaborate on what the backup > > application might be doing here (beyond just the rm -rf), the more > > likely this can be reproduced and resolved. > > Hi the lockdep warning should be fixed in the recent rhel6 kernel. > Sorry about that. > My understanding is that this patch has been reverted... Grant, If a newer kernel is not yet available, you might want to revert to the previous version until one is and then go straight to that. Lukas, If the patch is indeed reverted, then clearly this problem will go away. That aside, where does lockdep come into play? Note the warning reported above: WARNING: at fs/dcache.c:758 d_delete+0x260/0x2c0() ... is an explicit WARN_ON() in the code added by this commit. Are we referring to the same issue here? Brian > -Lukas > > > > > Brian > > > > > > > > > > Brian > > > > > > > > > > > > > > -- > > > Grant Keller > > > System Operations > > > 707-237-2451 > > > grant.keller@sonic.com > > > > > > > _______________________________________________ > > xfs mailing list > > xfs@oss.sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From lczerner@redhat.com Wed Sep 16 07:22:07 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 8FAB57F37 for ; Wed, 16 Sep 2015 07:22:07 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 7F3D38F8040 for ; Wed, 16 Sep 2015 05:22:04 -0700 (PDT) X-ASG-Debug-ID: 1442406122-04cb6c355b1590f0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id a2JToHCujuqbaTMg (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 16 Sep 2015 05:22:03 -0700 (PDT) X-Barracuda-Envelope-From: lczerner@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id CCB958EA4A; Wed, 16 Sep 2015 12:22:02 +0000 (UTC) Received: from vpn1-4-248.ams2.redhat.com (vpn1-4-248.ams2.redhat.com [10.36.4.248]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8GCLvMH028324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Sep 2015 08:22:00 -0400 Date: Wed, 16 Sep 2015 14:21:57 +0200 (CEST) From: =?ISO-8859-15?Q?Luk=E1=A8_Czerner?= X-X-Sender: lczerner@localhost.localdomain To: Brian Foster cc: Grant Keller , xfs@oss.sgi.com Subject: Re: rm Tainted warning after kernel update. In-Reply-To: <20150916114230.GB37016@bfoster.bfoster> X-ASG-Orig-Subj: Re: rm Tainted warning after kernel update. Message-ID: References: <55F718A1.10801@sonic.com> <20150915110042.GA21323@bfoster.bfoster> <55F89C76.4090808@sonic.com> <20150916105022.GA37016@bfoster.bfoster> <20150916114230.GB37016@bfoster.bfoster> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1519359409-1442405836=:3070" Content-ID: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442406123 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 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-1519359409-1442405836=:3070 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: On Wed, 16 Sep 2015, Brian Foster wrote: > Date: Wed, 16 Sep 2015 07:42:31 -0400 > From: Brian Foster > To: LukᨠCzerner > Cc: Grant Keller , xfs@oss.sgi.com > Subject: Re: rm Tainted warning after kernel update. > > On Wed, Sep 16, 2015 at 01:13:20PM +0200, LukᨠCzerner wrote: > > On Wed, 16 Sep 2015, Brian Foster wrote: > > > > > Date: Wed, 16 Sep 2015 06:50:23 -0400 > > > From: Brian Foster > > > To: Grant Keller > > > Cc: lczerner@redhat.com, xfs@oss.sgi.com > > > Subject: Re: rm Tainted warning after kernel update. > > > > > > cc Lukas > > > > > > On Tue, Sep 15, 2015 at 03:32:22PM -0700, Grant Keller wrote: > > > > On 09/15/2015 04:00 AM, Brian Foster wrote: > > > > > On Mon, Sep 14, 2015 at 11:57:37AM -0700, Grant Keller wrote: > > > > >> Hello, > > > > >> > > > > >> I have a server running Scientific Linux 6.7, and since updating to > > > > >> kernel 2.6.32-573.3.1.el6.x86_64 the following error has begun appearing > > > > >> in our message logs: > > > > >> > > > > >> Sep 14 11:43:03 localhost kernel: ------------[ cut here ]------------ > > > > >> Sep 14 11:43:03 localhost kernel: WARNING: at fs/dcache.c:758 > > > > >> d_delete+0x260/0x2c0() (Tainted: G W -- ------------ ) > > > > >> Sep 14 11:43:03 localhost kernel: Hardware name: X7DB8 > > > > >> Sep 14 11:43:03 localhost kernel: Modules linked in: nfsd nfs_acl > > > > >> auth_rpcgss autofs4 lockd sunrpc p4_clockmod freq_table speedstep_lib > > > > >> nf_conntrack_ftp iptable_mangle xt_comment nf_conntrack_ipv4 > > > > >> nf_defrag_ipv4 xt_multiport iptable_filter ip_tables ip6t_REJECT > > > > >> nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter > > > > >> ip6_tables ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm > > > > >> iw_cm ib_sa ib_mad ib_core ib_addr ipv6 xfs exportfs ppdev parport_pc > > > > >> parport sg e1000e microcode serio_raw iTCO_wdt iTCO_vendor_support ixgbe > > > > >> ptp pps_core mdio i2c_i801 lpc_ich mfd_core i5000_edac edac_core i5k_amb > > > > >> ioatdma dca shpchp ext4 jbd2 mbcache sd_mod crc_t10dif 3w_9xxx pata_acpi > > > > >> ata_generic ata_piix radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core > > > > >> dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ipmi_msghandler] > > > > >> Sep 14 11:43:03 localhost kernel: Pid: 15893, comm: rm Tainted: G > > > > >> W -- ------------ 2.6.32-573.3.1.el6.x86_64 #1 > > > > >> Sep 14 11:43:03 localhost kernel: Call Trace: > > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > > >> warn_slowpath_common+0x91/0xe0 > > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > > >> warn_slowpath_null+0x1a/0x20 > > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > > >> d_delete+0x260/0x2c0 > > > > >> Sep 14 11:43:03 localhost kernel: [] ? vfs_rmdir+0xe8/0xf0 > > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > > >> do_rmdir+0x184/0x1f0 > > > > >> Sep 14 11:43:03 localhost kernel: [] ? __fput+0x1a1/0x210 > > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > > >> audit_syscall_entry+0x1d7/0x200 > > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > > >> sys_unlinkat+0x2d/0x40 > > > > >> Sep 14 11:43:03 localhost kernel: [] ? > > > > >> system_call_fastpath+0x16/0x1b > > > > >> Sep 14 11:43:03 localhost kernel: ---[ end trace 6080ec4a7ec5ec25 ]--- > > > > >> > > > > >> This happens when we are expiring older backups from the archives, so I > > > > >> have quite a few of these. We have xfsprogs 3.1.1-16.el6.x86_64 > > > > >> installed. Looking for advice on how to proceed. > > > > >> > > > > > This looks like something funky going on in the vfs. The warning is from > > > > > unhash_offsprings() and it appears to be complaining about a refcount on > > > > > a dentry that is a child of a directory being removed. It checks a > > > > > refcount on a dentry in one loop and either drops it or moves it to > > > > > another list for apparent deletion. The second iteration of the > > > > > aforementioned list sees a refcount on an object that wasn't there > > > > > before. > > > > > > > > > > I suspect this means something is going from 0->1 unexpectedly, but I'm > > > > > not familiar enough with that code to grok why that shouldn't happen and > > > > > how it could without reproducing it and digging into it from there. Have > > > > > you identified an explicit reproducer? I assume files are simply being > > > > > removed with 'rm -rf' here..? If so, does anything else have access to > > > > > this directory structure (e.g., separate commands, a running backup > > > > > application?) at the the time of removal. > > > > There could be something else running, but I would have to investigate > > > > the next time this happens. The rm -rf is called by our backup program > > > > expiring older backups from the filesystem. The thing is, the > > > > expirations happen on a nightly basis, but we don't always see these > > > > warnings in the logs. On the nights we do, there are 1000+ warnings. > > > > > > > > > > Also, what kernel were you running before this started to occur? > > > > 2.6.32-573.el6.x86_64 was the previous kernel. > > > > > > Interesting... there are only a few fs changes between this kernel and > > > the current. One of them is this: > > > > > > 959c503 [fs] vfs: Unhash and evict unused children dentries after rmdir > > > > > > ... which actually introduces the unhash_offsprings() thing. I've cc'd > > > Lukas who is probably more familiar with this code. > > > > > > FWIW, I suspect the more you can elaborate on what the backup > > > application might be doing here (beyond just the rm -rf), the more > > > likely this can be reproduced and resolved. > > > > Hi the lockdep warning should be fixed in the recent rhel6 kernel. > > Sorry about that. > > > > My understanding is that this patch has been reverted... > > Grant, > > If a newer kernel is not yet available, you might want to revert to the > previous version until one is and then go straight to that. > > Lukas, > > If the patch is indeed reverted, then clearly this problem will go away. > That aside, where does lockdep come into play? Note the warning reported > above: > > WARNING: at fs/dcache.c:758 d_delete+0x260/0x2c0() > > ... is an explicit WARN_ON() in the code added by this commit. Are we > referring to the same issue here? > > Brian Hi Brian, seems like we're not referring to the same issue as I though we're talking about the lockdep problem, but apparently we're not. Can we get a RH bugzilla for this issue so it can be dealt with properly ? Thanks! -Lukas --8323328-1519359409-1442405836=:3070-- From robin.listas@gmail.com Wed Sep 16 07:54:06 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id AC7187F47 for ; Wed, 16 Sep 2015 07:54:06 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 72259304059 for ; Wed, 16 Sep 2015 05:54:06 -0700 (PDT) X-ASG-Debug-ID: 1442408039-04bdf04db5174fa0001-NocioJ Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by cuda.sgi.com with ESMTP id fSikMOCDvU9rBbUo (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 16 Sep 2015 05:54:00 -0700 (PDT) X-Barracuda-Envelope-From: robin.listas@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.212.180 Received: by wicfx3 with SMTP id fx3so71592151wic.1 for ; Wed, 16 Sep 2015 05:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type:content-id; bh=LuJIkzlBklzPaMkGMA9wxAePt6B9pwo3z8qRz2tZc4U=; b=ZZ5SclxCD3Ydxb1j1tTFrhWvKeCqNh6429gQHxTNP2PsGmytVt5vYf+h4w1D+4HAj9 4p68f2Ex4PurFqxoAAYXN/l6Fwh6hbkfjGpNE0cEsWZWzZ+hroLCmgQpQ082tAleku8q SrCAMLZhkNaHM8x3RxGWnvflp0NTMZ+DhQeYTDWosBXMruxUeofLaAQdSkOxxnyZfiRn Rvv0UJSqvDJ0J/RaEXLD7E9h/VUyTwyoahhRJxLtvqdX9cZkXj5wYrKa37WSi4I95hmY eV6XFLFd2cVLZMJqtW1javwWUYmrp3BQcz71XM7AxeTlN2GhsTzi/1G1U2/WWvXALVST ysug== X-Received: by 10.194.121.202 with SMTP id lm10mr9813434wjb.98.1442408039274; Wed, 16 Sep 2015 05:53:59 -0700 (PDT) Received: from minas-tirith.valinor (3.Red-83-42-78.dynamicIP.rima-tde.net. [83.42.78.3]) by smtp.gmail.com with ESMTPSA id mc18sm4357358wic.23.2015.09.16.05.53.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Sep 2015 05:53:58 -0700 (PDT) Sender: Carlos Robinson Received: from localhost (localhost [127.0.0.1]) by minas-tirith.valinor (Postfix) with ESMTP id D0F8118286E for ; Wed, 16 Sep 2015 14:53:56 +0200 (CEST) Date: Wed, 16 Sep 2015 14:53:56 +0200 (CEST) From: "Carlos E. R." X-X-Sender: cer@minas-tirith.valinor To: XFS mailing list Subject: Re: What's up with this list? In-Reply-To: <541AFB60.5030403@sgi.com> X-ASG-Orig-Subj: Re: What's up with this list? Message-ID: References: <541AFB60.5030403@sgi.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463779071-2002901569-1442407685=:25528" Content-ID: X-Barracuda-Connect: mail-wi0-f180.google.com[209.85.212.180] X-Barracuda-Start-Time: 1442408040 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22597 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463779071-2002901569-1442407685=:25528 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: El 2014-09-18 a las 10:33 -0500, Troy McCorkell escribió: > On 09/18/2014 07:46 AM, Carlos E. R. wrote: > > Hi, > > Now an then I get messages like this: > > ++································· > Your membership in the mailing list xfs has been disabled due to > excessive bounces The last bounce received from you was dated > 18-Sep-2014.  You will not get any more messages from this list until > you re-enable your membership.  You will receive 3 more reminders like > this before your membership in the list is deleted. > > To re-enable your membership, you can simply respond to this message > (leaving the Subject: line intact), or visit the confirmation page at > > ... > > ·································++- > > > Bounces? I'm subscribed to several mail lists, and this is the only one "complaining". And as I do not know > what messages bounced, I can not investigate it. > > My guess is that those emails were clear and flagrant spam, and as such were rejected by my ISP. > > The mail list should refuse them on entry and not resend them to the listers. > > - -- Cheers, >        Carlos E. R. >        (from 13.1 x86_64 "Bottle" at Telcontar) > > Carlos, > > I will forward your email to the SGI IT group. Well, I got no further feedback, and the issue continues, a year later. As I see it, it goes like this: Spam is sent to the list. The list forwards it to subscribers. Some mail servers, like my ISP, point blank refuse to accept what is flagrant spam; not a doubt about it, it doesn't reach the spam folder. That spam probably breaks a rule such as having no valid sender domain, breaking SPF, something. I don't know for sure, because I can not see the logs of my ISP. But the oss.sgi.com admin can, surely. The problem for me is that this list server automatically unsubscribes me, and I have to re-subscribe, posibly loosing interveening posts. I suggest that the list server implements filters to remove those spam mails on entry, instead of forwarding them. Alternatively, other mail list servers send a probe email to the subscriber; if the probe bounces, twice, then the subscription is temporarily disabled. But they don't unsubscribe people because some "list" posts bounce, unless it is excesive. - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlX5ZmQACgkQja8UbcUWM1wcxQD7BUPP7V8jRho3G3H0Oz/ZqVVs APLSE6oLIsGW/4GYn54A/0RiNx3Nd5gLhW8hYv6ljyNLqH26aUzYdiw3YO7c3mbb =oF/M -----END PGP SIGNATURE----- ---1463779071-2002901569-1442407685=:25528-- From zhao.mingyue@h3c.com Wed Sep 16 08:34:25 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 13EC77F47 for ; Wed, 16 Sep 2015 08:34:25 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 07016304051 for ; Wed, 16 Sep 2015 06:34:21 -0700 (PDT) X-ASG-Debug-ID: 1442410455-04cbb005ea179950001-NocioJ Received: from h3cmg01-ex.h3c.com (smtp.h3c.com [60.191.123.56]) by cuda.sgi.com with ESMTP id GOCFZMrSXjTQHbQm for ; Wed, 16 Sep 2015 06:34:16 -0700 (PDT) X-Barracuda-Envelope-From: zhao.mingyue@h3c.com X-Barracuda-Apparent-Source-IP: 60.191.123.56 Received: from H3CHUB04-EX.srv.huawei-3com.com (unknown [10.63.20.170]) by h3cmg01-ex.h3c.com with smtp id 30c5_01a2_6f61105d_f835_4d8a_b2a9_dfc551748fd3; Wed, 16 Sep 2015 21:33:51 +0800 Received: from H3CMLB12-EX.srv.huawei-3com.com ([fe80::f091:bd11:f0a9:5cbe]) by H3CHUB04-EX.srv.huawei-3com.com ([fe80::49fa:1f6e:1db1:4f65%11]) with mapi id 14.01.0355.002; Wed, 16 Sep 2015 21:33:42 +0800 From: "zhao.mingyue@h3c.com" To: Brian Foster CC: "xfs@oss.sgi.com" , Xudonghai Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IHVtb3VudCBoYW5naW5nIHByb2JsZW0=?= Thread-Topic: =?utf-8?B?562U5aSNOiB1bW91bnQgaGFuZ2luZyBwcm9ibGVt?= X-ASG-Orig-Subj: =?utf-8?B?562U5aSNOiDnrZTlpI06IHVtb3VudCBoYW5naW5nIHByb2JsZW0=?= Thread-Index: AQHQ76e56DZNxKL5A02KFnsnnd0C4p49i9Gg//+hmQCAAfhXQA== Date: Wed, 16 Sep 2015 13:34:28 +0000 Message-ID: <1CB94550540AE44E9CAAE8CD5AF40BF846CEE1CD@H3CMLB12-EX.srv.huawei-3com.com> References: <1CB94550540AE44E9CAAE8CD5AF40BF846CEDB68@H3CMLB12-EX.srv.huawei-3com.com> <20150915111420.GB21323@bfoster.bfoster> <1CB94550540AE44E9CAAE8CD5AF40BF846CEDD8C@H3CMLB12-EX.srv.huawei-3com.com> <20150915151556.GD21323@bfoster.bfoster> In-Reply-To: <20150915151556.GD21323@bfoster.bfoster> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.70.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Barracuda-Connect: smtp.h3c.com[60.191.123.56] X-Barracuda-Start-Time: 1442410456 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.69 X-Barracuda-Spam-Status: No, SCORE=1.69 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MV0113c, HELO_DYNAMIC_DHCP, HELO_DYNAMIC_DHCP_2, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22598 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP) 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MV0113c BSF_SC0_MV0113c 1.66 HELO_DYNAMIC_DHCP_2 HELO_DYNAMIC_DHCP_2 SSBoYXZlIGRvd25sb2FkZWQga2VybmVsIDQuMyByYzEgYW5kIG1ha2UgaW5zdGFsbCx0aGVuIG15 IG9yYWNsZSBzZXJ2aWNlIGNhbiBub3Qgc3RhcnQgdXAsY2FuIHlvdSBoZWxwIG1lIHRvIGFueWx5 c2UgdGhpcyBwcm9ibGVtID8NCmxvZyBhcyBmb2xsb3dzOg0KVHJhY2UgZmlsZSAvdTAxL2FwcC9k aWFnL3JkYm1zL29yY2wvb3JjbC90cmFjZS9vcmNsX29yYV8xNDg5Ni50cmMNCk9yYWNsZSBEYXRh YmFzZSAxMWcgRW50ZXJwcmlzZSBFZGl0aW9uIFJlbGVhc2UgMTEuMi4wLjQuMCAtIDY0Yml0IFBy b2R1Y3Rpb24NCldpdGggdGhlIFBhcnRpdGlvbmluZywgT0xBUCwgRGF0YSBNaW5pbmcgYW5kIFJl YWwgQXBwbGljYXRpb24gVGVzdGluZyBvcHRpb25zDQpPUkFDTEVfSE9NRSA9IC91MDEvYXBwL29y YWNsZS9wcm9kdWN0LzExLjIuMC9kYmhvbWVfMQ0KU3lzdGVtIG5hbWU6ICAgIExpbnV4DQpOb2Rl IG5hbWU6ICAgICAgdGVzdGluZw0KUmVsZWFzZTogICAgICAgIDQuMy4wLXJjMQ0KVmVyc2lvbjog ICAgICAgICMxIFNNUCBUdWUgU2VwIDE1IDEwOjI4OjIzIEVEVCAyMDE1DQpNYWNoaW5lOiAgICAg ICAgeDg2XzY0DQpJbnN0YW5jZSBuYW1lOiBvcmNsDQpSZWRvIHRocmVhZCBtb3VudGVkIGJ5IHRo aXMgaW5zdGFuY2U6IDAgPG5vbmU+DQpPcmFjbGUgcHJvY2VzcyBudW1iZXI6IDANClVuaXggcHJv Y2VzcyBwaWQ6IDE0ODk2LCBpbWFnZTogb3JhY2xlQHRlc3RpbmcNCg0KDQoqKiogMjAxNS0wOS0x NiAwOToxNzoxOC4xNjYNCkV4Y2VwdGlvbiBbdHlwZTogU0lHQlVTLCBOb24tZXhpc3RlbnQgcGh5 c2ljYWwgYWRkcmVzc10gW0FERFI6MHg3RjJEOEFDMjIwMDBdIFtQQzoweDQ5OTlGQTksIF9faW50 ZWxfbmV3X21lbWNweSgpKzU0OTddIFtmbGFnczogMHgwLCBjb3VudDogMV0NCkRERTogRmxvb2Qg Y29udHJvbCBpcyBub3QgYWN0aXZlDQpJbmNpZGVudCA0ODEwIGNyZWF0ZWQsIGR1bXAgZmlsZTog L3UwMS9hcHAvZGlhZy9yZGJtcy9vcmNsL29yY2wvaW5jaWRlbnQvaW5jZGlyXzQ4MTAvb3JjbF9v cmFfMTQ4OTZfaTQ4MTAudHJjDQpPUkEtMDc0NDU6IGV4Y2VwdGlvbiBlbmNvdW50ZXJlZDogY29y ZSBkdW1wIFtfX2ludGVsX25ld19tZW1jcHkoKSs1NDk3XSBbU0lHQlVTXSBbQUREUjoweDdGMkQ4 QUMyMjAwMF0gW1BDOjB4NDk5OUZBOV0gW05vbi1leGlzdGVudCBwaHlzaWNhbCBhZGRyZXNzXSBb XQ0KDQpzc2V4aGQ6IGNyYXNoaW5nIHRoZSBwcm9jZXNzLi4uDQpTaGFkb3dfQ29yZV9EdW1wID0g UEFSVElBTA0Ka3NkYmdjcmE6IHdyaXRpbmcgY29yZSBmaWxlIHRvIGRpcmVjdG9yeSAnL3UwMS9h cHAvZGlhZy9yZGJtcy9vcmNsL29yY2wvY2R1bXAnDQoNCj09PT09PT09PSBEdW1wIGZvciBpbmNp ZGVudCA0ODEwIChPUkEgNzQ0NSBbX19pbnRlbF9uZXdfbWVtY3B5KCkrNTQ5N10pID09PT09PT09 DQotLS0tLSBCZWdpbm5pbmcgb2YgQ3VzdG9taXplZCBJbmNpZGVudCBEdW1wKHMpIC0tLS0tDQpF eGNlcHRpb24gW3R5cGU6IFNJR0JVUywgTm9uLWV4aXN0ZW50IHBoeXNpY2FsIGFkZHJlc3NdIFtB RERSOjB4N0YyRDhBQzIyMDAwXSBbUEM6MHg0OTk5RkE5LCBfX2ludGVsX25ld19tZW1jcHkoKSs1 NDk3XSBbZmxhZ3M6IDB4MCwgY291bnQ6IDFdDQpSZWdpc3RlcnM6DQolcmF4OiAweDAwMDA3ZjJk OGFjMjIwMDAgJXJieDogMHgwMDAwMDAwMDAwMDA0MDAwICVyY3g6IDB4MDAwMDdmMmQ4YWMyMjAw MA0KJXJkeDogMHgwMDAwN2ZmZmI3NWE4YzYwICVyZGk6IDB4MDAwMDdmMmQ4YWMyMjAwMCAlcnNp OiAweDAwMDA3ZmZmYjc1YThjNjANCiVyc3A6IDB4MDAwMDdmZmZiNzVhOGMxOCAlcmJwOiAweDAw MDA3ZmZmYjc1YWRkZDAgICVyODogMHgwMDAwMDAwMDAwMDA1MTUwDQogJXI5OiAweDAwMDAwMDAw MDA3ODAwMDAgJXIxMDogMHgwMDAwMDAwMDAwMDAwMDEyICVyMTE6IDB4MDAwMDAwMDAwNDk5OGJk MA0KJXIxMjogMHgwMDAwN2YyZDhhYzIyMDAwICVyMTM6IDB4MDAwMDdmZmZiNzVhZGRmMCAlcjE0 OiAweDAwMDAwMDAwMDAwMDAwMDMNCiVyMTU6IDB4MDAwMDAwMDAwMDAxMDAwMCAlcmlwOiAweDAw MDAwMDAwMDQ5OTlmYTkgJWVmbDogMHgwMDAwMDAwMDAwMDEwMjQ2DQogIF9faW50ZWxfbmV3X21l bWNweSgpKzU0ODMgKDB4NDk5OWY5Yikgam1wIColcjEwZA0KICBfX2ludGVsX25ld19tZW1jcHko KSs1NDg2ICgweDQ5OTlmOWUpIG5vcA0KICBfX2ludGVsX25ld19tZW1jcHkoKSs1NDg4ICgweDQ5 OTlmYTApIG1vdmRxYSAoJXJkeCksJXhtbTANCiAgX19pbnRlbF9uZXdfbWVtY3B5KCkrNTQ5MiAo MHg0OTk5ZmE0KSBtb3ZkcWEgMHgxMCglcmR4KSwleG1tMQ0KPiBfX2ludGVsX25ld19tZW1jcHko KSs1NDk3ICgweDQ5OTlmYTkpIG1vdmRxYSAleG1tMCwoJXJjeCkNCiAgX19pbnRlbF9uZXdfbWVt Y3B5KCkrNTUwMSAoMHg0OTk5ZmFkKSBtb3ZkcWEgJXhtbTEsMHgxMCglcmN4KQ0KICBfX2ludGVs X25ld19tZW1jcHkoKSs1NTA2ICgweDQ5OTlmYjIpIGxlYSAtMHg4MCglcjgpLCVyOA0KICBfX2lu dGVsX25ld19tZW1jcHkoKSs1NTEwICgweDQ5OTlmYjYpIG1vdmRxYSAweDIwKCVyZHgpLCV4bW0y DQogIF9faW50ZWxfbmV3X21lbWNweSgpKzU1MTUgKDB4NDk5OWZiYikgbW92ZHFhIDB4MzAoJXJk eCksJXhtbTMNCg0KKioqIDIwMTUtMDktMTYgMDk6MTc6MTguMjQwDQpkYmtlZERlZkR1bXAoKTog U3RhcnRpbmcgYSBub24taW5jaWRlbnQgZGlhZ25vc3RpYyBkdW1wIChmbGFncz0weDMsIGxldmVs PTMsIG1hc2s9MHgwKQ0KLS0tLS0gU1FMIFN0YXRlbWVudCAoTm9uZSkgLS0tLS0NCkN1cnJlbnQg U1FMIGluZm9ybWF0aW9uIHVuYXZhaWxhYmxlIC0gbm8gc2Vzc2lvbi4NCg0KLS0tLS0gQ2FsbCBT dGFjayBUcmFjZSAtLS0tLQ0KY2FsbGluZyAgICAgICAgICAgICAgY2FsbCAgICAgZW50cnkgICAg ICAgICAgICAgICAgYXJndW1lbnQgdmFsdWVzIGluIGhleA0KbG9jYXRpb24gICAgICAgICAgICAg dHlwZSAgICAgcG9pbnQgICAgICAgICAgICAgICAgKD8gbWVhbnMgZHViaW91cyB2YWx1ZSkNCi0t LS0tLS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0tIC0tLS0tLS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCnNrZHN0ZHN0KCkrNDEgICAgICAgIGNhbGwgICAgIGtnZHNk c3QoKSAgICAgICAgICAgIDAwMDAwMDAwMCA/IDAwMDAwMDAwMCA/DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3RjJEOEFFQTdDNDAgPyA3RjJEOEFF QTdEMTggPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgN0YyRDhBRUFDN0MwID8gMDAwMDAwMDAzID8NCmtzZWRzdDEoKSsxMDMgICAgICAgIGNhbGwg ICAgIHNrZHN0ZHN0KCkgICAgICAgICAgIDAwMDAwMDAwMCA/IDAwMDAwMDAwMCA/DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3RjJEOEFFQTdDNDAg PyA3RjJEOEFFQTdEMTggPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgN0YyRDhBRUFDN0MwID8gMDAwMDAwMDAzID8NCmtzZWRzdCgpKzM5ICAgICAg ICAgIGNhbGwgICAgIGtzZWRzdDEoKSAgICAgICAgICAgIDAwMDAwMDAwMSA/IDAwMDAwMDAwMSA/ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3RjJE OEFFQTdDNDAgPyA3RjJEOEFFQTdEMTggPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgN0YyRDhBRUFDN0MwID8gMDAwMDAwMDAzID8NCmRia2VkRGVm RHVtcCgpKzI3NDYgIGNhbGwgICAgIGtzZWRzdCgpICAgICAgICAgICAgIDAwMDAwMDAwMSA/IDAw MDAwMDAwMSA/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA3RjJEOEFFQTdDNDAgPyA3RjJEOEFFQTdEMTggPw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgN0YyRDhBRUFDN0MwID8gMDAwMDAwMDAzID8N CmtzZWRtcCgpKzQxICAgICAgICAgIGNhbGwgICAgIGRia2VkRGVmRHVtcCgpICAgICAgIDAwMDAw MDAwMyA/IDAwMDAwMDAwMyA/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA3RjJEOEFFQTdDNDAgPyA3RjJEOEFFQTdEMTggPw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgN0YyRDhBRUFDN0MwID8gMDAw MDAwMDAzID8NCnNzZXhoZCgpKzI0NjIgICAgICAgIGNhbGwgICAgIGtzZWRtcCgpICAgICAgICAg ICAgIDAwMDAwMDAwMyA/IDAwMDAwMDAwMyA/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA3RjJEOEFFQTdDNDAgPyA3RjJEOEFFQTdEMTggPw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgN0YyRDhBRUFD N0MwID8gMDAwMDAwMDAzID8NCl9fc2lnaGFuZGxlcigpICAgICAgIGNhbGwgICAgIHNzZXhoZCgp ICAgICAgICAgICAgIDAwMDAwMDAwNyA/IDdGMkQ4QUVBREJGMCA/DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3RjJEOEFFQURBRTggPyA3RjJEOEFF QTdEMTggPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgN0YyRDhBRUFDN0MwID8gMDAwMDAwMDAzID8NCl9faW50ZWxfbmV3X21lbWNweSggIHNpZ25h bCAgIF9fc2lnaGFuZGxlcigpICAgICAgIDdGMkQ4QUMyMjAwMCA/IDdGRkZCNzVBOEM2MCA/DQop KzU0OTcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3RkZGQjc1 QThDNjAgPyA3RjJEOEFDMjIwMDAgPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMDAwMDA1MTUwID8gMDAwNzgwMDAwID8NCl9pbnRlbF9mYXN0X21l bWNweS4gIGNhbGwgICAgIF9faW50ZWxfbmV3X21lbWNweSggIDdGMkQ4QUMyMjAwMCA/IDdGRkZC NzVBOEM2MCA/DQpKKCkrNiAgICAgICAgICAgICAgICAgICAgICAgICApICAgICAgICAgICAgICAg ICAgICA3RkZGQjc1QThDNjAgPyA3RjJEOEFDMjIwMDAgPw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDA1MTUwID8gMDAwNzgwMDAwID8NCnNr Z21yZl9jcmVhdGUoKSs0NDAgIGNhbGwgICAgIF9pbnRlbF9mYXN0X21lbWNweS4gIDdGMkQ4QUMy MjAwMCA/IDdGRkZCNzVBOEM2MCA/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKKCkg ICAgICAgICAgICAgICAgICA3RkZGQjc1QThDNjAgPyA3RjJEOEFDMjIwMDAgPw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDA1MTUwID8gMDAw NzgwMDAwID8NCmtzbXJmX2luaXRfYWxsb2MoKSsgIGNhbGwgICAgIHNrZ21yZl9jcmVhdGUoKSAg ICAgIDdGRkZCNzVBRERGMCA/IDAwMDAxMDAwMCA/DQoxNDQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA3RjJEOEFDMjIwMDAgPyAwMDAwMDAwMDMgPw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDA1MTUw ID8gMDAwNzgwMDAwID8NCmtzbWFyZmcoKSsyMDEgICAgICAgIGNhbGwgICAgIGtzbXJmX2luaXRf YWxsb2MoKSAgIDAwMDAxMDAwMCA/IDAwMDAxMDAwMCA/DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3RjJEOEFDMjIwMDAgPyAwMDAwMDAwMDMgPw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDA1 MTUwID8gMDAwNzgwMDAwID8NCmtnaGdleCgpKzE0MTEgICAgICAgIGNhbGwgICAgIGtzbWFyZmco KSAgICAgICAgICAgIDAwMDAxMDAwMCA/IDAwMDAxMDAwMCA/DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDIwNjAgPyAwMDAwMTAwMDAgPw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDBDMEI3 ODQ4ID8gMDBDMEI3ODQwID8NCmtnaGZuZCgpKzM2ODcgICAgICAgIGNhbGwgICAgIGtnaGdleCgp ICAgICAgICAgICAgIDAwQzBCMjJDMCA/IDAwMDAwMDAwMCA/DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMEMwQjc4MDAgPyAwMDlBRTc5QTAgPw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDBDMEI3 ODQ4ID8gMDBDMEI3ODQwID8NCmtnaHBybWFsbygpKzU5MyAgICAgIGNhbGwgICAgIGtnaGZuZCgp ICAgICAgICAgICAgIDAwQzBCMjJDMCA/IDAwMDAwMDAwMCA/DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMEMwQjc4MDAgPyAwMDlBRTc5QTAgPw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDAw MDUwID8gMDBDMEI3ODQwID8NCmtnaGFscCgpKzEwNzMgICAgICAgIGNhbGwgICAgIGtnaHBybWFs bygpICAgICAgICAgIDAwQzBCMjJDMCA/IDAwMDAwMDA1MCA/DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMEMwQjc4MDAgPyAwMDAwMDAwMzAgPw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDAw MDUwID8gMDBDMEI3ODQwID8NCmtnaHhocmcoKSs1NyAgICAgICAgIGNhbGwgICAgIGtnaGFscCgp ICAgICAgICAgICAgIDAwQzBCMjJDMCA/IDAwQzBCMjJDMCA/DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMEMwQjc4MDAgPyAwMDAwMDAwMDAgPw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAwMDAw MDUwID8gMDBDMEI3ODQwID8NCmt4c25meSgpKzEyNiAgICAgICAgIGNhbGwgICAgIGtnaHhocmco KSAgICAgICAgICAgIDAwQzBCMjJDMCA/IDAwQzBCNzgwMCA/DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwNjAwNDQxNDAgPyAwMDAwMDAxMTggPw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDBBM0JD NTg4ID8gMDBDMEI3ODQwID8NCmtzY25meSgpKzg2MiAgICAgICAgIGNhbGwgICAgIGt4c25meSgp ICAgICAgICAgICAgIDAwQzBCMjJDMCA/IDAwQzBCNzgwMCA/DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwNjAwNDQxNDAgPyAwMDAwMDAxMTggPw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDBBM0JD NTg4ID8gMDBDMEI3ODQwID8NCmtzbWNwZygpKzY0ICAgICAgICAgIGNhbGwgICAgIGtzY25meSgp ICAgICAgICAgICAgIDAwMDAwMDAwNSA/IDAwQzBCMUZDMCA/DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDAwMDAgPyAwMDAwMDAxMTggPw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDBBM0JD NTg4ID8gMDBDMEI3ODQwID8NCmtzdWNycCgpKzI2MiAgICAgICAgIGNhbGwgICAgIGtzbWNwZygp ICAgICAgICAgICAgIDAwMDAwMDAwNSA/IDAwQzBCMUZDMCA/DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDAwMDAgPyAwMDAwMDAxMTggPw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDBBM0JD NTg4ID8gMDBDMEI3ODQwID8NCmtzdWNyZXNnKCkrMTEwICAgICAgIGNhbGwgICAgIGtzdWNycCgp ICAgICAgICAgICAgIDAwMDAwMDAwNCA/IDAwQzBCMUZDMCA/DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDAwMDAgPyAwMDAwMDAxMTggPw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDBBM0JD NTg4ID8gMDBDMEI3ODQwID8NCmtwb2xuYSgpKzQ0OSAgICAgICAgIGNhbGwgICAgIGtzdWNyZXNn KCkgICAgICAgICAgIDAwMDAwMDAwMCA/IDAwMDAwMDAwMCA/DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDAwMDAgPyA3RjJEOEFFQUZCQjAg Pw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMDAw MDAwMDFCID8gMDBDMEI3ODQwID8NCmtwb2F1dGgoKSsxOTE1MSAgICAgIGNhbGwgICAgIGtwb2xu YSgpICAgICAgICAgICAgIDAwMDAwMDAzQSA/IDAwMDAwMDAwMCA/DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDAwMDAgPyA3RjJEOEFFQUZC QjAgPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MDAwMDAwMDFCID8gMDBDMEI3ODQwID8NCm9waW9kcigpKzkxNyAgICAgICAgIGNhbGwgICAgIGtw b2F1dGgoKSAgICAgICAgICAgIDAwMDAwMDA3MyA/IDAwMDAwMDAwNyA/DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3RkZGQjc1QjNERjAgPyA3RjJE OEFFQUZCQjAgPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMDAwMDAwMDFCID8gMDBDMEI3ODQwID8NCnR0Y3BpcCgpKzIxODMgICAgICAgIGNhbGwg ICAgIG9waW9kcigpICAgICAgICAgICAgIDAwMDAwMDA3MyA/IDAwMDAwMDAwNyA/DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3RkZGQjc1QjNERjAg PyA3RjJEOEFFQUZCQjAgPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMDAwMDAwMDFCID8gMDBDMEI3ODQwID8NCm9waXRzaygpKzE3MTAgICAgICAg IGNhbGwgICAgIHR0Y3BpcCgpICAgICAgICAgICAgIDAwQzBDRkYxMCA/IDAwOTk4NjU1MCA/DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3RkZGQjc1 QjNERjAgPyAwMDAwMDAwMDAgPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgN0ZGRkI3NUIzODQ4ID8gN0ZGRkI3NUIzREVDID8NCm9waWlubygpKzk2 OSAgICAgICAgIGNhbGwgICAgIG9waXRzaygpICAgICAgICAgICAgIDAwQzBDRkYxOCA/IDAwMDAw MDAwMCA/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA3RkZGQjc1QjNERjAgPyAwMDAwMDAwMDAgPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgN0ZGRkI3NUIzODQ4ID8gN0ZGRkI3NUIzREVDID8NCm9w aW9kcigpKzkxNyAgICAgICAgIGNhbGwgICAgIG9waWlubygpICAgICAgICAgICAgIDAwMDAwMDAz QyA/IDAwMDAwMDAwNCA/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA3RkZGQjc1QjU1RTggPyAwMDAwMDAwMDAgPw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgN0ZGRkI3NUIzODQ4ID8gN0ZGRkI3NUIz REVDID8NCm9waWRydigpKzU3MCAgICAgICAgIGNhbGwgICAgIG9waW9kcigpICAgICAgICAgICAg IDAwMDAwMDAzQyA/IDAwMDAwMDAwNCA/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA3RkZGQjc1QjU1RTggPyAwMDAwMDAwMDAgPw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgN0ZGRkI3NUIzODQ4ID8g N0ZGRkI3NUIzREVDID8NCnNvdTJvKCkrMTAzICAgICAgICAgIGNhbGwgICAgIG9waWRydigpICAg ICAgICAgICAgIDAwMDAwMDAzQyA/IDAwMDAwMDAwNCA/DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA3RkZGQjc1QjU1RTggPyAwMDAwMDAwMDAgPw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgN0ZGRkI3 NUIzODQ4ID8gN0ZGRkI3NUIzREVDID8NCm9waW1haV9yZWFsKCkrMTMzICAgIGNhbGwgICAgIHNv dTJvKCkgICAgICAgICAgICAgIDdGRkZCNzVCNTVDMCA/IDAwMDAwMDAzQyA/DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAwMDAwMDQgPyA3RkZG Qjc1QjU1RTggPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgN0ZGRkI3NUIzODQ4ID8gN0ZGRkI3NUIzREVDID8NCnNzdGhyZG1haW4oKSsyNjUgICAg IGNhbGwgICAgIG9waW1haV9yZWFsKCkgICAgICAgIDAwMDAwMDAwMiA/IDdGRkZCNzVCNTdCMCA/ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMDAw MDAwMDQgPyA3RkZGQjc1QjU1RTggPw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgN0ZGRkI3NUIzODQ4ID8gN0ZGRkI3NUIzREVDID8NCm1haW4oKSsy MDEgICAgICAgICAgIGNhbGwgICAgIHNzdGhyZG1haW4oKSAgICAgICAgIDAwMDAwMDAwMiA/IDdG RkZCNzVCNTdCMCA/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAwMDAwMDAwMDEgPyAwMDAwMDAwMDAgPw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgN0ZGRkI3NUIzODQ4ID8gN0ZGRkI3NUIzREVDID8N Cl9fbGliY19zdGFydF9tYWluKCkgIGNhbGwgICAgIG1haW4oKSAgICAgICAgICAgICAgIDAwMDAw MDAwMiA/IDdGRkZCNzVCNTk1OCA/DQorMjQ1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAwMDAwMDAwMDEgPyAwMDAwMDAwMDAgPw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgN0ZGRkI3NUIzODQ4ID8gN0ZGRkI3 NUIzREVDID8NCl9zdGFydCgpKzQxICAgICAgICAgIGNhbGwgICAgIF9fbGliY19zdGFydF9tYWlu KCkgIDAwMEExNEVEMCA/IDAwMDAwMDAwMiA/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA3RkZGQjc1QjU5NDggPyAwMDAwMDAwMDAgPw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgN0ZGRkI3NUIzODQ4 ID8gN0ZGRkI3NUIzREVDID8NCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBC cmlhbiBGb3N0ZXIgW21haWx0bzpiZm9zdGVyQHJlZGhhdC5jb21dIA0K5Y+R6YCB5pe26Ze0OiAy MDE15bm0OeaciDE15pelIDIzOjE2DQrmlLbku7bkuro6IHpoYW9taW5neXVlIDA5NDQwIChSRCkN CuaKhOmAgTogeGZzQG9zcy5zZ2kuY29tOyB4dWRvbmdoYWkgMTE1MDcgKFJEKQ0K5Li76aKYOiBS ZTog562U5aSNOiB1bW91bnQgaGFuZ2luZyBwcm9ibGVtDQoNCk9uIFR1ZSwgU2VwIDE1LCAyMDE1 IGF0IDEyOjU5OjI3UE0gKzAwMDAsIHpoYW8ubWluZ3l1ZUBoM2MuY29tIHdyb3RlOg0KPiBIaSBC cmlhbiwNCj4gIFRoYW5rcyBmb3IgeW91ciBleHBsYWluYXRpb24hDQo+IA0KPiBrZXJuZWwgdmVy c2lvbu+8mjMuMTAuMC0yMjkuZTE3Lng4Ni02NA0KPiANCj4gIkZpeGVzIGZvciAoaG9wZWZ1bGx5 KSBtb3N0IG9mIHRoZXNlIHByb2JsZW1zIGFyZSBwZW5kaW5nIGluIDQuMyItLS0tTm93IDQuM3Jj MSBoYXMgYWxyZWFkeSBmaXggdGhpcyBwcm9ibGVtPw0KPiANCg0KWWVzLCBhcyBvZiByb3VnaGx5 IGNvbW1pdHMgNWU0YjUzOCB0aHJvdWdoIGQ0YTk3YTAgb3Igc28uDQoNCkJyaWFuDQoNCj4gLS0t LS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IEJyaWFuIEZvc3RlciBbbWFpbHRvOmJm b3N0ZXJAcmVkaGF0LmNvbV0NCj4g5Y+R6YCB5pe26Ze0OiAyMDE15bm0OeaciDE15pelIDE5OjE0 DQo+IOaUtuS7tuS6ujogemhhb21pbmd5dWUgMDk0NDAgKFJEKQ0KPiDmioTpgIE6IHhmc0Bvc3Mu c2dpLmNvbTsgeHVkb25naGFpIDExNTA3IChSRCkNCj4g5Li76aKYOiBSZTogdW1vdW50IGhhbmdp bmcgcHJvYmxlbQ0KPiANCj4gT24gVHVlLCBTZXAgMTUsIDIwMTUgYXQgMDI6NTk6NTNBTSArMDAw MCwgemhhby5taW5neXVlQGgzYy5jb20gd3JvdGU6DQo+ID4gSGksZXZlcnlvbmUNCj4gPiANCj4g PiAgSSBoYXZlIHNvbWUgcXVlc3Rpb24gYWJvdXQgWEZTIEZJTEVzeXN0ZW3vvIxjYW4gc29tZW9u ZSBoZWxwIG1lIHNvdmxlIA0KPiA+IG15IHByb2JsZW0g77yfDQo+ID4gDQo+IA0KPiBXaGF0IGtl cm5lbD8NCj4gDQo+ID4gIEkgYnVpbHQgYSBPcmFjbGUgZGF0YWJhc2Ugb24gYSByYmQgYmxvY2sg d2hpY2ggaGFkIGJlZW4gY3JlYXRlZCB4ZnMgDQo+ID4gZmlsZXN5c3RlbSDvvIx0aGVuIEkgcmVt b3ZlZCB0aGUgcmJkIGJsb2NrIO+8jHRoZW4gdGhlIGZpbGUgZGlyZWN0b3J5IG9mIA0KPiA+IHRo ZSBvcmFjbGUgd2FzIGJyb2tlbiBhbmQgY291bGRu4oCZdCBiZSB1c2Vk77yMbmV4dO+8jEkgcmVj b3ZlciB0aGUgcmJkIA0KPiA+IGJsb2NrDQo+ID4gDQo+ID4gYW5kIHVtb3VudCB0aGUgZmlsZSBk aXJlY3Rvcnkgb2YgdGhlIG9yYWNsZSDvvIx3aGF0IGhhcHBlZCBuZXh0IGlzIHRoZSANCj4gPiBx dWVzdGlvbiB3aGljaCBJIHdhcyBjb25mdXNlZCDvvIx0aGUgcHJvY2VzcyBvZiB0aGUgdW1vdW50 IGlzIGh1bmdpbmcgDQo+ID4gdGhlcmUgYW5kIGNvdWxkbuKAmXQgYmUga2lsbGVk77yMaG93IHRv IHNvbHZlIHRoZSBwcm9ibGVtIO+8n++8nw0KPiA+IA0KPiANCj4gSXQncyB3YWl0aW5nIHRvIGZs dXNoIGV2ZXJ5dGhpbmcgb3V0IHRoYXQgd2FzIHByZXZpb3VzbHkgd3JpdHRlbiB0byB0aGUgbG9n IGFuZCBzaXR0aW5nIGluIHRoZSBBSUwgbGlzdC4gSXQgc291bmRzIGxpa2UgdGhlIGZpbGVzeXN0 ZW0gc2h1dGRvd24gYmVjYXVzZSB0aGUgdW5kZXJseWluZyBibG9jayBkZXZpY2Ugd2FzIHRvcm4g ZG93biBiZWZvcmUgdGhlIGZpbGVzeXN0ZW0gd2FzIHVubW91bnRlZCwgd2hpY2ggaXMgbm90IHRo ZSB3YXkgdG8gZG8gdGhpbmdzLiA7KSBSZWNlbnQga2VybmVscyBoYXZlIGhhZCBpc3N1ZXMgd2l0 aCBleHRlbnQgZnJlZWluZyBsb2dnaW5nIHN1Y2ggdGhhdCBFRkkvRUZEIG9iamVjdHMgYXJlIG5v dCByZWZlcmVuY2UgY291bnRlZCBjb3JyZWN0bHkgYW5kIGNhbiBzaXQgaW4gdGhlIEFJTCBhbmQg cGluIGl0IGluZGVmaW5pdGVseSwgcGFydGljdWxhcmx5IG9uIHJhY2VzIHdpdGggZnMgc2h1dGRv d24uDQo+IA0KPiBGaXhlcyBmb3IgKGhvcGVmdWxseSkgbW9zdCBvZiB0aGVzZSBwcm9ibGVtcyBh cmUgcGVuZGluZyBpbiA0LjMuIEZvciB0aGUgdGltZSBiZWluZyB5b3UnbGwgcHJvYmFibHkgaGF2 ZSB0byByZWJvb3QgdG8gcmVjb3Zlci4gQWxzbyBub3RlIHRoYXQgdGhpcyBzaG91bGQgbmV2ZXIg aGFwcGVuIGV4Y2VwdCBkdWUgdG8gc29tZSBvdGhlciBjcmFzaCwgY2F1c2VkIGluIHRoaXMgY2Fz ZSBieSBicmVha2luZyBkb3duIHRoZSBibG9jayBkZXZpY2UgYmVmb3JlIHVubW91bnRpbmcgdGhl IGZzLg0KPiANCj4gQnJpYW4NCj4gDQo+ID4gdGhhbmtz77yBDQo+ID4gDQo+ID4gDQo+ID4gDQo+ ID4gDQo+ID4gcGFydCBvZiB0aGUgbG9nIGlzIGFzIGZvbGxvd3PvvJoNCj4gPiANCj4gPiBTZXAg MTEgMTA6MjI6MjkgbG9jYWxob3N0IHN5c3RlbWQ6IFN0YXJ0ZWQgRmluZ2VycHJpbnQgQXV0aGVu dGljYXRpb24gRGFlbW9uLg0KPiA+IFNlcCAxMSAxMDoyMjoyOSBsb2NhbGhvc3QgZnByaW50ZDog TGF1bmNoaW5nIEZwcmludE9iamVjdCBTZXAgMTENCj4gPiAxMDoyMjoyOSBsb2NhbGhvc3QgZnBy aW50ZDogKiogTWVzc2FnZTogRC1CdXMgc2VydmljZSBsYXVuY2hlZCB3aXRoDQo+ID4gbmFtZTog bmV0LnJlYWN0aXZhdGVkLkZwcmludCBTZXAgMTEgMTA6MjI6MjkgbG9jYWxob3N0IGZwcmludGQ6 ICoqDQo+ID4gTWVzc2FnZTogZW50ZXJpbmcgbWFpbiBsb29wIFNlcCAxMSAxMDoyMjozOSBsb2Nh bGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVk Lg0KPiA+IFNlcCAxMSAxMDoyMjo0NyBsb2NhbGhvc3Qgc3lzdGVtZC1sb2dpbmQ6IFJlbW92ZWQg c2Vzc2lvbiAxLg0KPiA+IFNlcCAxMSAxMDoyMjo1OSBsb2NhbGhvc3QgZnByaW50ZDogKiogTWVz c2FnZTogTm8gZGV2aWNlcyBpbiB1c2UsIA0KPiA+IGV4aXQgU2VwIDExIDEwOjIzOjA5IGxvY2Fs aG9zdCBrZXJuZWw6IFhGUyAoZG0tMik6IHhmc19sb2dfZm9yY2U6IGVycm9yIDUgcmV0dXJuZWQu DQo+ID4gU2VwIDExIDEwOjIzOjE5IGxvY2FsaG9zdCBzeXN0ZW1kLWxvZ2luZDogUmVtb3ZlZCBz ZXNzaW9uIDEzNi4NCj4gPiBTZXAgMTEgMTA6MjM6MzkgbG9jYWxob3N0IGtlcm5lbDogWEZTIChk bS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NCj4gPiBTZXAgMTEgMTA6MjM6 NDQgbG9jYWxob3N0IGtlcm5lbDogSU5GTzogdGFzayB1bW91bnQ6Mjc5NTAgYmxvY2tlZCBmb3Ig bW9yZSB0aGFuIDEyMCBzZWNvbmRzLg0KPiA+IFNlcCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qga2Vy bmVsOiAiZWNobyAwID4gL3Byb2Mvc3lzL2tlcm5lbC9odW5nX3Rhc2tfdGltZW91dF9zZWNzIiBk aXNhYmxlcyB0aGlzIG1lc3NhZ2UuDQo+ID4gU2VwIDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJu ZWw6IHVtb3VudCAgICAgICAgICBEIGZmZmY4ODBlMWZhZjM2ODAgICAgIDAgMjc5NTAgIDI3Nzc1 IDB4MDAwMDAwODQNCj4gPiBTZXAgMTEgMTA6MjM6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4 MGRkMzI0N2Q5MCAwMDAwMDAwMDAwMDAwMDg2DQo+ID4gZmZmZjg4MDZmNzMwZGIwMCBmZmZmODgw ZGQzMjQ3ZmQ4IFNlcCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gPiBmZmZmODgw ZGQzMjQ3ZmQ4IGZmZmY4ODBkZDMyNDdmZDggZmZmZjg4MDZmNzMwZGIwMCBmZmZmODgwNmU3Y2Vh ZTgwIA0KPiA+IFNlcCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qga2VybmVsOiBmZmZmODgwNmNiODg4 YjQ4IGZmZmY4ODA2ZTdjZWFlYzAgZmZmZjg4MDZlN2NlYWVlOCBmZmZmODgwNmU3Y2VhZTkwIFNl cCAxMSAxMDoyMzo0NCBsb2NhbGhvc3Qga2VybmVsOiBDYWxsIFRyYWNlOg0KPiA+IFNlcCAxMSAx MDoyMzo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODE2MDkyNTk+XQ0KPiA+IHNjaGVk dWxlKzB4MjkvMHg3MCBTZXAgMTEgMTA6MjM6NDQgbG9jYWxob3N0IGtlcm5lbDogDQo+ID4gWzxm ZmZmZmZmZmEwMmYxYWMxPl0geGZzX2FpbF9wdXNoX2FsbF9zeW5jKzB4YzEvMHgxMTAgW3hmc10g U2VwIDExDQo+ID4gMTA6MjM6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMDk4MjMw Pl0gPyANCj4gPiB3YWtlX3VwX2JpdCsweDMwLzB4MzAgU2VwIDExIDEwOjIzOjQ0IGxvY2FsaG9z dCBrZXJuZWw6IA0KPiA+IFs8ZmZmZmZmZmZhMDJhMWM0OD5dIHhmc191bm1vdW50ZnMrMHg2OC8w eDE2MCBbeGZzXSBTZXAgMTEgMTA6MjM6NDQgDQo+ID4gbG9jYWxob3N0IGtlcm5lbDogWzxmZmZm ZmZmZmEwMmEyNGViPl0gPw0KPiA+IHhmc19tcnVfY2FjaGVfZGVzdHJveSsweDZiLzB4OTAgW3hm c10gU2VwIDExIDEwOjIzOjQ0IGxvY2FsaG9zdA0KPiA+IGtlcm5lbDogWzxmZmZmZmZmZmEwMmEz NzAxPl0geGZzX2ZzX3B1dF9zdXBlcisweDIxLzB4NjAgW3hmc10gU2VwIDExDQo+ID4gMTA6MjM6 NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM4OTM2Pl0NCj4gPiBnZW5lcmljX3No dXRkb3duX3N1cGVyKzB4NTYvMHhlMCBTZXAgMTEgMTA6MjM6NDQgbG9jYWxob3N0IGtlcm5lbDog DQo+ID4gWzxmZmZmZmZmZjgxMWM4YzE3Pl0ga2lsbF9ibG9ja19zdXBlcisweDI3LzB4NzAgU2Vw IDExIDEwOjIzOjQ0IA0KPiA+IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFjOGY0ZD5d DQo+ID4gZGVhY3RpdmF0ZV9sb2NrZWRfc3VwZXIrMHgzZC8weDYwIFNlcCAxMSAxMDoyMzo0NCBs b2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExYzk1NTY+XSBkZWFjdGl2YXRlX3N1cGVyKzB4 NDYvMHg2MCBTZXAgMTEgMTA6MjM6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWU2 MjY1Pl0gbW50cHV0X25vX2V4cGlyZSsweGM1LzB4MTIwIFNlcCAxMSAxMDoyMzo0NCBsb2NhbGhv c3Qga2VybmVsOiBbPGZmZmZmZmZmODExZTczOWY+XSBTeVNfdW1vdW50KzB4OWYvMHgzYzAgU2Vw IDExIDEwOjIzOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTYxM2RhOT5dIHN5c3Rl bV9jYWxsX2Zhc3RwYXRoKzB4MTYvMHgxYiBTZXAgMTEgMTA6MjM6NTcgbG9jYWxob3N0IHN5c3Rl bWQtbG9naW5kOiBSZW1vdmVkIHNlc3Npb24gMTMzLg0KPiA+IFNlcCAxMSAxMDoyNDowOSBsb2Nh bGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVk Lg0KPiA+IFNlcCAxMSAxMDoyNDozOSBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNf bG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0KPiA+IFNlcCAxMSAxMDoyNTowOSBsb2NhbGhv c3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0K PiA+IFNlcCAxMSAxMDoyNTozOSBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9n X2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0KPiA+IFNlcCAxMSAxMDoyNTo0NCBsb2NhbGhvc3Qg a2VybmVsOiBJTkZPOiB0YXNrIHVtb3VudDoyNzk1MCBibG9ja2VkIGZvciBtb3JlIHRoYW4gMTIw IHNlY29uZHMuDQo+ID4gU2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6ICJlY2hvIDAg PiAvcHJvYy9zeXMva2VybmVsL2h1bmdfdGFza190aW1lb3V0X3NlY3MiIGRpc2FibGVzIHRoaXMg bWVzc2FnZS4NCj4gPiBTZXAgMTEgMTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogdW1vdW50ICAg ICAgICAgIEQgZmZmZjg4MGUxZmFmMzY4MCAgICAgMCAyNzk1MCAgMjc3NzUgMHgwMDAwMDA4NA0K PiA+IFNlcCAxMSAxMDoyNTo0NCBsb2NhbGhvc3Qga2VybmVsOiBmZmZmODgwZGQzMjQ3ZDkwIDAw MDAwMDAwMDAwMDAwODYNCj4gPiBmZmZmODgwNmY3MzBkYjAwIGZmZmY4ODBkZDMyNDdmZDggU2Vw IDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiA+IGZmZmY4ODBkZDMyNDdmZDggZmZm Zjg4MGRkMzI0N2ZkOCBmZmZmODgwNmY3MzBkYjAwIGZmZmY4ODA2ZTdjZWFlODAgDQo+ID4gU2Vw IDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IGZmZmY4ODA2Y2I4ODhiNDggZmZmZjg4MDZl N2NlYWVjMCBmZmZmODgwNmU3Y2VhZWU4IGZmZmY4ODA2ZTdjZWFlOTAgU2VwIDExIDEwOjI1OjQ0 IGxvY2FsaG9zdCBrZXJuZWw6IENhbGwgVHJhY2U6DQo+ID4gU2VwIDExIDEwOjI1OjQ0IGxvY2Fs aG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTYwOTI1OT5dDQo+ID4gc2NoZWR1bGUrMHgyOS8weDcw IFNlcCAxMSAxMDoyNTo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gPiBbPGZmZmZmZmZmYTAyZjFh YzE+XSB4ZnNfYWlsX3B1c2hfYWxsX3N5bmMrMHhjMS8weDExMCBbeGZzXSBTZXAgMTENCj4gPiAx MDoyNTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODEwOTgyMzA+XSA/IA0KPiA+IHdh a2VfdXBfYml0KzB4MzAvMHgzMCBTZXAgMTEgMTA6MjU6NDQgbG9jYWxob3N0IGtlcm5lbDogDQo+ ID4gWzxmZmZmZmZmZmEwMmExYzQ4Pl0geGZzX3VubW91bnRmcysweDY4LzB4MTYwIFt4ZnNdIFNl cCAxMSAxMDoyNTo0NCANCj4gPiBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmYTAyYTI0ZWI+ XSA/DQo+ID4geGZzX21ydV9jYWNoZV9kZXN0cm95KzB4NmIvMHg5MCBbeGZzXSBTZXAgMTEgMTA6 MjU6NDQgbG9jYWxob3N0DQo+ID4ga2VybmVsOiBbPGZmZmZmZmZmYTAyYTM3MDE+XSB4ZnNfZnNf cHV0X3N1cGVyKzB4MjEvMHg2MCBbeGZzXSBTZXAgMTENCj4gPiAxMDoyNTo0NCBsb2NhbGhvc3Qg a2VybmVsOiBbPGZmZmZmZmZmODExYzg5MzY+XQ0KPiA+IGdlbmVyaWNfc2h1dGRvd25fc3VwZXIr MHg1Ni8weGUwIFNlcCAxMSAxMDoyNTo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gPiBbPGZmZmZm ZmZmODExYzhjMTc+XSBraWxsX2Jsb2NrX3N1cGVyKzB4MjcvMHg3MCBTZXAgMTEgMTA6MjU6NDQg DQo+ID4gbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM4ZjRkPl0NCj4gPiBkZWFjdGl2 YXRlX2xvY2tlZF9zdXBlcisweDNkLzB4NjAgU2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJu ZWw6IFs8ZmZmZmZmZmY4MTFjOTU1Nj5dIGRlYWN0aXZhdGVfc3VwZXIrMHg0Ni8weDYwIFNlcCAx MSAxMDoyNTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExZTYyNjU+XSBtbnRwdXRf bm9fZXhwaXJlKzB4YzUvMHgxMjAgU2VwIDExIDEwOjI1OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8 ZmZmZmZmZmY4MTFlNzM5Zj5dIFN5U191bW91bnQrMHg5Zi8weDNjMCBTZXAgMTEgMTA6MjU6NDQg bG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxNjEzZGE5Pl0gc3lzdGVtX2NhbGxfZmFzdHBh dGgrMHgxNi8weDFiIFNlcCAxMSAxMDoyNjowNSBsb2NhbGhvc3Qgc3lzdGVtZC1sb2dpbmQ6IE5l dyBzZXNzaW9uIDEzOCBvZiB1c2VyIHJvb3QuDQo+ID4gU2VwIDExIDEwOjI2OjA1IGxvY2FsaG9z dCBzeXN0ZW1kOiBTdGFydGluZyBTZXNzaW9uIDEzOCBvZiB1c2VyIHJvb3QuDQo+ID4gU2VwIDEx IDEwOjI2OjA1IGxvY2FsaG9zdCBzeXN0ZW1kOiBTdGFydGVkIFNlc3Npb24gMTM4IG9mIHVzZXIg cm9vdC4NCj4gPiBTZXAgMTEgMTA6MjY6MDkgbG9jYWxob3N0IGtlcm5lbDogWEZTIChkbS0yKTog eGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NCj4gPiBTZXAgMTEgMTA6MjY6MjkgbG9j YWxob3N0IHN5c3RlbWQtbG9naW5kOiBOZXcgc2Vzc2lvbiAxMzkgb2YgdXNlciByb290Lg0KPiA+ IFNlcCAxMSAxMDoyNjoyOSBsb2NhbGhvc3Qgc3lzdGVtZDogU3RhcnRpbmcgU2Vzc2lvbiAxMzkg b2YgdXNlciByb290Lg0KPiA+IFNlcCAxMSAxMDoyNjoyOSBsb2NhbGhvc3Qgc3lzdGVtZDogU3Rh cnRlZCBTZXNzaW9uIDEzOSBvZiB1c2VyIHJvb3QuDQo+ID4gU2VwIDExIDEwOjI2OjMyIGxvY2Fs aG9zdCBzeXN0ZW1kLWxvZ2luZDogUmVtb3ZlZCBzZXNzaW9uIDEzOS4NCj4gPiBTZXAgMTEgMTA6 MjY6MzkgbG9jYWxob3N0IGtlcm5lbDogWEZTIChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3Ig NSByZXR1cm5lZC4NCj4gPiBTZXAgMTEgMTA6Mjc6MDkgbG9jYWxob3N0IGtlcm5lbDogWEZTIChk bS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NCj4gPiBTZXAgMTEgMTA6Mjc6 MzggbG9jYWxob3N0IGdvYVsyODc3NV06IGdvYS1kYWVtb24gdmVyc2lvbiAzLjguNSANCj4gPiBz dGFydGluZyBbbWFpbi5jOjExMywgbWFpbigpXSBTZXAgMTEgMTA6Mjc6MzggbG9jYWxob3N0IGdv YVsyODc4Ml06DQo+ID4gR29hS2VyYmVyb3NJZGVudGl0eU1hbmFnZXI6IFVzaW5nIHBvbGxpbmcg Zm9yIGNoYW5nZSBub3RpZmljYXRpb24gZm9yIGNyZWRlbnRpYWwgY2FjaGUgdHlwZSAnS0VZUklO RycgW2dvYWtlcmJlcm9zaWRlbnRpdHltYW5hZ2VyLmM6MTM5NCwgbW9uaXRvcl9jcmVkZW50aWFs c19jYWNoZSgpXSBTZXAgMTEgMTA6Mjc6NDAgbG9jYWxob3N0IGtlcm5lbDogWEZTIChkbS0yKTog eGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NCj4gPiBTZXAgMTEgMTA6Mjc6NDQgbG9j YWxob3N0IGtlcm5lbDogSU5GTzogdGFzayB1bW91bnQ6Mjc5NTAgYmxvY2tlZCBmb3IgbW9yZSB0 aGFuIDEyMCBzZWNvbmRzLg0KPiA+IFNlcCAxMSAxMDoyNzo0NCBsb2NhbGhvc3Qga2VybmVsOiAi ZWNobyAwID4gL3Byb2Mvc3lzL2tlcm5lbC9odW5nX3Rhc2tfdGltZW91dF9zZWNzIiBkaXNhYmxl cyB0aGlzIG1lc3NhZ2UuDQo+ID4gU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IHVt b3VudCAgICAgICAgICBEIGZmZmY4ODBlMWZhZjM2ODAgICAgIDAgMjc5NTAgIDI3Nzc1IDB4MDAw MDAwODQNCj4gPiBTZXAgMTEgMTA6Mjc6NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4MGRkMzI0 N2Q5MCAwMDAwMDAwMDAwMDAwMDg2DQo+ID4gZmZmZjg4MDZmNzMwZGIwMCBmZmZmODgwZGQzMjQ3 ZmQ4IFNlcCAxMSAxMDoyNzo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gPiBmZmZmODgwZGQzMjQ3 ZmQ4IGZmZmY4ODBkZDMyNDdmZDggZmZmZjg4MDZmNzMwZGIwMCBmZmZmODgwNmU3Y2VhZTgwIA0K PiA+IFNlcCAxMSAxMDoyNzo0NCBsb2NhbGhvc3Qga2VybmVsOiBmZmZmODgwNmNiODg4YjQ4IGZm ZmY4ODA2ZTdjZWFlYzAgZmZmZjg4MDZlN2NlYWVlOCBmZmZmODgwNmU3Y2VhZTkwIFNlcCAxMSAx MDoyNzo0NCBsb2NhbGhvc3Qga2VybmVsOiBDYWxsIFRyYWNlOg0KPiA+IFNlcCAxMSAxMDoyNzo0 NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODE2MDkyNTk+XQ0KPiA+IHNjaGVkdWxlKzB4 MjkvMHg3MCBTZXAgMTEgMTA6Mjc6NDQgbG9jYWxob3N0IGtlcm5lbDogDQo+ID4gWzxmZmZmZmZm ZmEwMmYxYWMxPl0geGZzX2FpbF9wdXNoX2FsbF9zeW5jKzB4YzEvMHgxMTAgW3hmc10gU2VwIDEx DQo+ID4gMTA6Mjc6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMDk4MjMwPl0gPyAN Cj4gPiB3YWtlX3VwX2JpdCsweDMwLzB4MzAgU2VwIDExIDEwOjI3OjQ0IGxvY2FsaG9zdCBrZXJu ZWw6IA0KPiA+IFs8ZmZmZmZmZmZhMDJhMWM0OD5dIHhmc191bm1vdW50ZnMrMHg2OC8weDE2MCBb eGZzXSBTZXAgMTEgMTA6Mjc6NDQgDQo+ID4gbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZmEw MmEyNGViPl0gPw0KPiA+IHhmc19tcnVfY2FjaGVfZGVzdHJveSsweDZiLzB4OTAgW3hmc10gU2Vw IDExIDEwOjI3OjQ0IGxvY2FsaG9zdA0KPiA+IGtlcm5lbDogWzxmZmZmZmZmZmEwMmEzNzAxPl0g eGZzX2ZzX3B1dF9zdXBlcisweDIxLzB4NjAgW3hmc10gU2VwIDExDQo+ID4gMTA6Mjc6NDQgbG9j YWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM4OTM2Pl0NCj4gPiBnZW5lcmljX3NodXRkb3du X3N1cGVyKzB4NTYvMHhlMCBTZXAgMTEgMTA6Mjc6NDQgbG9jYWxob3N0IGtlcm5lbDogDQo+ID4g WzxmZmZmZmZmZjgxMWM4YzE3Pl0ga2lsbF9ibG9ja19zdXBlcisweDI3LzB4NzAgU2VwIDExIDEw OjI3OjQ0IA0KPiA+IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFjOGY0ZD5dDQo+ID4g ZGVhY3RpdmF0ZV9sb2NrZWRfc3VwZXIrMHgzZC8weDYwIFNlcCAxMSAxMDoyNzo0NCBsb2NhbGhv c3Qga2VybmVsOiBbPGZmZmZmZmZmODExYzk1NTY+XSBkZWFjdGl2YXRlX3N1cGVyKzB4NDYvMHg2 MCBTZXAgMTEgMTA6Mjc6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWU2MjY1Pl0g bW50cHV0X25vX2V4cGlyZSsweGM1LzB4MTIwIFNlcCAxMSAxMDoyNzo0NCBsb2NhbGhvc3Qga2Vy bmVsOiBbPGZmZmZmZmZmODExZTczOWY+XSBTeVNfdW1vdW50KzB4OWYvMHgzYzAgU2VwIDExIDEw OjI3OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTYxM2RhOT5dIHN5c3RlbV9jYWxs X2Zhc3RwYXRoKzB4MTYvMHgxYiBTZXAgMTEgMTA6Mjg6MTAgbG9jYWxob3N0IGtlcm5lbDogWEZT IChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NCj4gPiBTZXAgMTEgMTA6 Mjg6NDAgbG9jYWxob3N0IGtlcm5lbDogWEZTIChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3Ig NSByZXR1cm5lZC4NCj4gPiBTZXAgMTEgMTA6Mjk6MTAgbG9jYWxob3N0IGtlcm5lbDogWEZTIChk bS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSByZXR1cm5lZC4NCj4gPiBTZXAgMTEgMTA6Mjk6 NDAgbG9jYWxob3N0IGtlcm5lbDogWEZTIChkbS0yKTogeGZzX2xvZ19mb3JjZTogZXJyb3IgNSBy ZXR1cm5lZC4NCj4gPiBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogSU5GTzogdGFz ayB1bW91bnQ6Mjc5NTAgYmxvY2tlZCBmb3IgbW9yZSB0aGFuIDEyMCBzZWNvbmRzLg0KPiA+IFNl cCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiAiZWNobyAwID4gL3Byb2Mvc3lzL2tlcm5l bC9odW5nX3Rhc2tfdGltZW91dF9zZWNzIiBkaXNhYmxlcyB0aGlzIG1lc3NhZ2UuDQo+ID4gU2Vw IDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IHVtb3VudCAgICAgICAgICBEIGZmZmY4ODBl MWZhZjM2ODAgICAgIDAgMjc5NTAgIDI3Nzc1IDB4MDAwMDAwODQNCj4gPiBTZXAgMTEgMTA6Mjk6 NDQgbG9jYWxob3N0IGtlcm5lbDogZmZmZjg4MGRkMzI0N2Q5MCAwMDAwMDAwMDAwMDAwMDg2DQo+ ID4gZmZmZjg4MDZmNzMwZGIwMCBmZmZmODgwZGQzMjQ3ZmQ4IFNlcCAxMSAxMDoyOTo0NCBsb2Nh bGhvc3Qga2VybmVsOiANCj4gPiBmZmZmODgwZGQzMjQ3ZmQ4IGZmZmY4ODBkZDMyNDdmZDggZmZm Zjg4MDZmNzMwZGIwMCBmZmZmODgwNmU3Y2VhZTgwIA0KPiA+IFNlcCAxMSAxMDoyOTo0NCBsb2Nh bGhvc3Qga2VybmVsOiBmZmZmODgwNmNiODg4YjQ4IGZmZmY4ODA2ZTdjZWFlYzAgZmZmZjg4MDZl N2NlYWVlOCBmZmZmODgwNmU3Y2VhZTkwIFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVs OiBDYWxsIFRyYWNlOg0KPiA+IFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZm ZmZmZmZmODE2MDkyNTk+XQ0KPiA+IHNjaGVkdWxlKzB4MjkvMHg3MCBTZXAgMTEgMTA6Mjk6NDQg bG9jYWxob3N0IGtlcm5lbDogDQo+ID4gWzxmZmZmZmZmZmEwMmYxYWMxPl0geGZzX2FpbF9wdXNo X2FsbF9zeW5jKzB4YzEvMHgxMTAgW3hmc10gU2VwIDExDQo+ID4gMTA6Mjk6NDQgbG9jYWxob3N0 IGtlcm5lbDogWzxmZmZmZmZmZjgxMDk4MjMwPl0gPyANCj4gPiB3YWtlX3VwX2JpdCsweDMwLzB4 MzAgU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiA+IFs8ZmZmZmZmZmZhMDJh MWM0OD5dIHhmc191bm1vdW50ZnMrMHg2OC8weDE2MCBbeGZzXSBTZXAgMTEgMTA6Mjk6NDQgDQo+ ID4gbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZmEwMmEyNGViPl0gPw0KPiA+IHhmc19tcnVf Y2FjaGVfZGVzdHJveSsweDZiLzB4OTAgW3hmc10gU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdA0K PiA+IGtlcm5lbDogWzxmZmZmZmZmZmEwMmEzNzAxPl0geGZzX2ZzX3B1dF9zdXBlcisweDIxLzB4 NjAgW3hmc10gU2VwIDExDQo+ID4gMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZm ZjgxMWM4OTM2Pl0NCj4gPiBnZW5lcmljX3NodXRkb3duX3N1cGVyKzB4NTYvMHhlMCBTZXAgMTEg MTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogDQo+ID4gWzxmZmZmZmZmZjgxMWM4YzE3Pl0ga2ls bF9ibG9ja19zdXBlcisweDI3LzB4NzAgU2VwIDExIDEwOjI5OjQ0IA0KPiA+IGxvY2FsaG9zdCBr ZXJuZWw6IFs8ZmZmZmZmZmY4MTFjOGY0ZD5dDQo+ID4gZGVhY3RpdmF0ZV9sb2NrZWRfc3VwZXIr MHgzZC8weDYwIFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODEx Yzk1NTY+XSBkZWFjdGl2YXRlX3N1cGVyKzB4NDYvMHg2MCBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxo b3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWU2MjY1Pl0gbW50cHV0X25vX2V4cGlyZSsweGM1LzB4 MTIwIFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExZTczOWY+ XSBTeVNfdW1vdW50KzB4OWYvMHgzYzAgU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6 IFs8ZmZmZmZmZmY4MTYxM2RhOT5dIHN5c3RlbV9jYWxsX2Zhc3RwYXRoKzB4MTYvMHgxYiBTZXAg MTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogSU5GTzogdGFzayBtb3VudDoyODY2OSBibG9j a2VkIGZvciBtb3JlIHRoYW4gMTIwIHNlY29uZHMuDQo+ID4gU2VwIDExIDEwOjI5OjQ0IGxvY2Fs aG9zdCBrZXJuZWw6ICJlY2hvIDAgPiAvcHJvYy9zeXMva2VybmVsL2h1bmdfdGFza190aW1lb3V0 X3NlY3MiIGRpc2FibGVzIHRoaXMgbWVzc2FnZS4NCj4gPiBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxo b3N0IGtlcm5lbDogbW91bnQgICAgICAgICAgIEQgZmZmZjg4MDcwM2NmMzY4MCAgICAgMCAyODY2 OSAgMjc5OTAgMHgwMDAwMDA4NA0KPiA+IFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVs OiBmZmZmODgwNmNhNTlmYzQ4IDAwMDAwMDAwMDAwMDAwODINCj4gPiBmZmZmODgwZGVhODc3MWMw IGZmZmY4ODA2Y2E1OWZmZDggU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiA+ IGZmZmY4ODA2Y2E1OWZmZDggZmZmZjg4MDZjYTU5ZmZkOCBmZmZmODgwZGVhODc3MWMwIGZmZmY4 ODBkZWE4NzcxYzAgDQo+ID4gU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IGZmZmY4 ODBkZWM4MWYwNjggZmZmZjg4MGRlYzgxZjA3MCBmZmZmZmZmZjAwMDAwMDAwIGZmZmY4ODBkZWM4 MWYwNzggU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IENhbGwgVHJhY2U6DQo+ID4g U2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTYwOTI1OT5dDQo+ ID4gc2NoZWR1bGUrMHgyOS8weDcwIFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiAN Cj4gPiBbPGZmZmZmZmZmODE2MGFiMzU+XSByd3NlbV9kb3duX3dyaXRlX2ZhaWxlZCsweDExNS8w eDIyMA0KPiA+IFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODEy MDE0ODE+XSA/IA0KPiA+IF9fYmxrZGV2X2dldCsweDIyMS8weDRkMCBTZXAgMTEgMTA6Mjk6NDQg bG9jYWxob3N0IGtlcm5lbDogDQo+ID4gWzxmZmZmZmZmZjgxMWM4ODMwPl0gPyBzZXRfYmRldl9z dXBlcisweDQwLzB4NDAgU2VwIDExIDEwOjI5OjQ0IA0KPiA+IGxvY2FsaG9zdCBrZXJuZWw6IFs8 ZmZmZmZmZmY4MTJlMjlhMz5dDQo+ID4gY2FsbF9yd3NlbV9kb3duX3dyaXRlX2ZhaWxlZCsweDEz LzB4MjANCj4gPiBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtlcm5lbDogWzxmZmZmZmZmZjgx NjA4NjRkPl0gPyANCj4gPiBkb3duX3dyaXRlKzB4MmQvMHgzMCBTZXAgMTEgMTA6Mjk6NDQgbG9j YWxob3N0IGtlcm5lbDogDQo+ID4gWzxmZmZmZmZmZjgxMWM5MTdlPl0gZ3JhYl9zdXBlcisweDJl LzB4YTAgU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdA0KPiA+IGtlcm5lbDogWzxmZmZmZmZmZjgx MWM5ODEwPl0gc2dldCsweDJhMC8weDNkMCBTZXAgMTEgMTA6Mjk6NDQgDQo+ID4gbG9jYWxob3N0 IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM4N2YwPl0gPyBuc190ZXN0X3N1cGVyKzB4MjAvMHgyMCBT ZXANCj4gPiAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExYzliOTI+ XQ0KPiA+IG1vdW50X2JkZXYrMHhlMi8weDFmMCBTZXAgMTEgMTA6Mjk6NDQgbG9jYWxob3N0IGtl cm5lbDogDQo+ID4gWzxmZmZmZmZmZmEwMmE0NTgwPl0gPyB4ZnNfcGFyc2VhcmdzKzB4YmYwLzB4 YmYwIFt4ZnNdIFNlcCAxMSANCj4gPiAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZm ZmZmODEyZDYyMzA+XSA/IA0KPiA+IGlkYV9nZXRfbmV3X2Fib3ZlKzB4MjMwLzB4MmEwIFNlcCAx MSAxMDoyOTo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gPiBbPGZmZmZmZmZmYTAyYTI3NzU+XQ0K PiA+IHhmc19mc19tb3VudCsweDE1LzB4MjAgW3hmc10gU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9z dCBrZXJuZWw6IA0KPiA+IFs8ZmZmZmZmZmY4MTFjYTU5OT5dIG1vdW50X2ZzKzB4MzkvMHgxYjAg U2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdA0KPiA+IGtlcm5lbDogWzxmZmZmZmZmZjgxMTc4NDIw Pl0gPyBfX2FsbG9jX3BlcmNwdSsweDEwLzB4MjAgU2VwIDExDQo+ID4gMTA6Mjk6NDQgbG9jYWxo b3N0IGtlcm5lbDogWzxmZmZmZmZmZjgxMWU1YTZmPl0NCj4gPiB2ZnNfa2Vybl9tb3VudCsweDVm LzB4ZjAgU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IA0KPiA+IFs8ZmZmZmZmZmY4 MTFlN2ZiZT5dIGRvX21vdW50KzB4MjRlLzB4YTQwIFNlcCAxMSAxMDoyOTo0NCBsb2NhbGhvc3Qg a2VybmVsOiBbPGZmZmZmZmZmODExNzMxN2I+XSA/IHN0cm5kdXBfdXNlcisweDRiLzB4ZjAgU2Vw IDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFlODg0Nj5dIFN5U19t b3VudCsweDk2LzB4ZjAgU2VwIDExIDEwOjI5OjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZm ZmY4MTYxM2RhOT5dIHN5c3RlbV9jYWxsX2Zhc3RwYXRoKzB4MTYvMHgxYiBTZXAgMTEgMTA6MzA6 MDEgbG9jYWxob3N0IHN5c3RlbWQ6IFN0YXJ0aW5nIFNlc3Npb24gMTQwIG9mIHVzZXIgcm9vdC4N Cj4gPiBTZXAgMTEgMTA6MzA6MDEgbG9jYWxob3N0IHN5c3RlbWQ6IFN0YXJ0ZWQgU2Vzc2lvbiAx NDAgb2YgdXNlciByb290Lg0KPiA+IFNlcCAxMSAxMDozMDoxMCBsb2NhbGhvc3Qga2VybmVsOiBY RlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0KPiA+IFNlcCAxMSAx MDozMDo0MCBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJv ciA1IHJldHVybmVkLg0KPiA+IFNlcCAxMSAxMDozMToxMCBsb2NhbGhvc3Qga2VybmVsOiBYRlMg KGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1IHJldHVybmVkLg0KPiA+IFNlcCAxMSAxMDoz MTo0MCBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNlOiBlcnJvciA1 IHJldHVybmVkLg0KPiA+IFNlcCAxMSAxMDozMTo0NCBsb2NhbGhvc3Qga2VybmVsOiBJTkZPOiB0 YXNrIHVtb3VudDoyNzk1MCBibG9ja2VkIGZvciBtb3JlIHRoYW4gMTIwIHNlY29uZHMuDQo+ID4g U2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6ICJlY2hvIDAgPiAvcHJvYy9zeXMva2Vy bmVsL2h1bmdfdGFza190aW1lb3V0X3NlY3MiIGRpc2FibGVzIHRoaXMgbWVzc2FnZS4NCj4gPiBT ZXAgMTEgMTA6MzE6NDQgbG9jYWxob3N0IGtlcm5lbDogdW1vdW50ICAgICAgICAgIEQgZmZmZjg4 MGUxZmFmMzY4MCAgICAgMCAyNzk1MCAgMjc3NzUgMHgwMDAwMDA4NA0KPiA+IFNlcCAxMSAxMDoz MTo0NCBsb2NhbGhvc3Qga2VybmVsOiBmZmZmODgwZGQzMjQ3ZDkwIDAwMDAwMDAwMDAwMDAwODYN Cj4gPiBmZmZmODgwNmY3MzBkYjAwIGZmZmY4ODBkZDMyNDdmZDggU2VwIDExIDEwOjMxOjQ0IGxv Y2FsaG9zdCBrZXJuZWw6IA0KPiA+IGZmZmY4ODBkZDMyNDdmZDggZmZmZjg4MGRkMzI0N2ZkOCBm ZmZmODgwNmY3MzBkYjAwIGZmZmY4ODA2ZTdjZWFlODAgDQo+ID4gU2VwIDExIDEwOjMxOjQ0IGxv Y2FsaG9zdCBrZXJuZWw6IGZmZmY4ODA2Y2I4ODhiNDggZmZmZjg4MDZlN2NlYWVjMCBmZmZmODgw NmU3Y2VhZWU4IGZmZmY4ODA2ZTdjZWFlOTAgU2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJu ZWw6IENhbGwgVHJhY2U6DQo+ID4gU2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8 ZmZmZmZmZmY4MTYwOTI1OT5dDQo+ID4gc2NoZWR1bGUrMHgyOS8weDcwIFNlcCAxMSAxMDozMTo0 NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gPiBbPGZmZmZmZmZmYTAyZjFhYzE+XSB4ZnNfYWlsX3B1 c2hfYWxsX3N5bmMrMHhjMS8weDExMCBbeGZzXSBTZXAgMTENCj4gPiAxMDozMTo0NCBsb2NhbGhv c3Qga2VybmVsOiBbPGZmZmZmZmZmODEwOTgyMzA+XSA/IA0KPiA+IHdha2VfdXBfYml0KzB4MzAv MHgzMCBTZXAgMTEgMTA6MzE6NDQgbG9jYWxob3N0IGtlcm5lbDogDQo+ID4gWzxmZmZmZmZmZmEw MmExYzQ4Pl0geGZzX3VubW91bnRmcysweDY4LzB4MTYwIFt4ZnNdIFNlcCAxMSAxMDozMTo0NCAN Cj4gPiBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmYTAyYTI0ZWI+XSA/DQo+ID4geGZzX21y dV9jYWNoZV9kZXN0cm95KzB4NmIvMHg5MCBbeGZzXSBTZXAgMTEgMTA6MzE6NDQgbG9jYWxob3N0 DQo+ID4ga2VybmVsOiBbPGZmZmZmZmZmYTAyYTM3MDE+XSB4ZnNfZnNfcHV0X3N1cGVyKzB4MjEv MHg2MCBbeGZzXSBTZXAgMTENCj4gPiAxMDozMTo0NCBsb2NhbGhvc3Qga2VybmVsOiBbPGZmZmZm ZmZmODExYzg5MzY+XQ0KPiA+IGdlbmVyaWNfc2h1dGRvd25fc3VwZXIrMHg1Ni8weGUwIFNlcCAx MSAxMDozMTo0NCBsb2NhbGhvc3Qga2VybmVsOiANCj4gPiBbPGZmZmZmZmZmODExYzhjMTc+XSBr aWxsX2Jsb2NrX3N1cGVyKzB4MjcvMHg3MCBTZXAgMTEgMTA6MzE6NDQgDQo+ID4gbG9jYWxob3N0 IGtlcm5lbDogWzxmZmZmZmZmZjgxMWM4ZjRkPl0NCj4gPiBkZWFjdGl2YXRlX2xvY2tlZF9zdXBl cisweDNkLzB4NjAgU2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4 MTFjOTU1Nj5dIGRlYWN0aXZhdGVfc3VwZXIrMHg0Ni8weDYwIFNlcCAxMSAxMDozMTo0NCBsb2Nh bGhvc3Qga2VybmVsOiBbPGZmZmZmZmZmODExZTYyNjU+XSBtbnRwdXRfbm9fZXhwaXJlKzB4YzUv MHgxMjAgU2VwIDExIDEwOjMxOjQ0IGxvY2FsaG9zdCBrZXJuZWw6IFs8ZmZmZmZmZmY4MTFlNzM5 Zj5dIFN5U191bW91bnQrMHg5Zi8weDNjMCBTZXAgMTEgMTA6MzE6NDQgbG9jYWxob3N0IGtlcm5l bDogWzxmZmZmZmZmZjgxNjEzZGE5Pl0gc3lzdGVtX2NhbGxfZmFzdHBhdGgrMHgxNi8weDFiIFNl cCAxMSAxMDozMjoxMCBsb2NhbGhvc3Qga2VybmVsOiBYRlMgKGRtLTIpOiB4ZnNfbG9nX2ZvcmNl OiBlcnJvciA1IHJldHVybmVkLg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gLS0NCj4gPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPiDmnKzpgq7ku7blj4rlhbbpmYTku7blkKvmnInmna3lt57ljY7kuInpgJrkv6HmioDmnK/m nInpmZDlhazlj7jnmoTkv53lr4bkv6Hmga/vvIzku4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLlnLDl nYDkuK3liJflh7oNCj4gPiDnmoTkuKrkurrmiJbnvqTnu4TjgILnpoHmraLku7vkvZXlhbbku5bk urrku6Xku7vkvZXlvaLlvI/kvb/nlKjvvIjljIXmi6zkvYbkuI3pmZDkuo7lhajpg6jmiJbpg6jl iIblnLDms4TpnLLjgIHlpI3liLbjgIENCj4gPiDmiJbmlaPlj5HvvInmnKzpgq7ku7bkuK3nmoTk v6Hmga/jgILlpoLmnpzmgqjplJnmlLbkuobmnKzpgq7ku7bvvIzor7fmgqjnq4vljbPnlLXor53m iJbpgq7ku7bpgJrnn6Xlj5Hku7bkurrlubbliKDpmaTmnKwNCj4gPiDpgq7ku7bvvIENCj4gPiBU aGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9y bWF0aW9uIA0KPiA+IGZyb20gSDNDLCB3aGljaCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVy c29uIG9yIGVudGl0eSB3aG9zZSANCj4gPiBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVz ZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiANCj4gPiBpbiBhbnkgd2F5IChp bmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCANCj4gPiBkaXNj bG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIg dGhhbiANCj4gPiB0aGUgaW50ZW5kZWQNCj4gPiByZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4g SWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIA0KPiA+IHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBieSBwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0K PiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IHhmcyBtYWlsaW5nIGxpc3QNCj4gPiB4ZnNAb3NzLnNnaS5jb20NCj4gPiBodHRwOi8vb3Nz LnNnaS5jb20vbWFpbG1hbi9saXN0aW5mby94ZnMNCj4gDQo= From bfoster@redhat.com Wed Sep 16 11:31:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id E0A5C7F47 for ; Wed, 16 Sep 2015 11:31:40 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id C55EB304051 for ; Wed, 16 Sep 2015 09:31:37 -0700 (PDT) X-ASG-Debug-ID: 1442421096-04cbb005ea17e630001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id mvBWDbUGVelXjQyL (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 16 Sep 2015 09:31:36 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 06E16461E7 for ; Wed, 16 Sep 2015 16:31:36 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8GGVZZb006580 for ; Wed, 16 Sep 2015 12:31:35 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 695E51201EB; Wed, 16 Sep 2015 12:31:34 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH] xfs: log local to remote symlink conversions correctly on v5 supers Date: Wed, 16 Sep 2015 12:31:34 -0400 X-ASG-Orig-Subj: [PATCH] xfs: log local to remote symlink conversions correctly on v5 supers Message-Id: <1442421094-15791-1-git-send-email-bfoster@redhat.com> 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: 1442421096 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 A local format symlink inode is converted to extent format when an extended attribute is set on an inode as part of the attribute fork creation. This means a block is allocated, the local symlink target name is copied to the block and the block is logged. Currently, xfs_bmap_local_to_extents() handles logging the remote block data based on the size of the data fork prior to the conversion. This is not correct on v5 superblock filesystems, which add an additional header to remote symlink blocks that is nonexistent in local format inodes. As a result, the full length of the remote symlink block content is not logged. This can lead to corruption should a crash occur and log recovery replay this transaction. Since a callout is already used to initialize the new remote symlink block, update the local-to-extents conversion mechanism to make the callout also responsible for logging the block. It is already required to set the log buffer type and format the block appropriately based on the superblock version. This ensures the remote symlink is always logged correctly. Note that xfs_bmap_local_to_extents() is only called for symlinks so there are no other callouts that require modification. Signed-off-by: Brian Foster --- fs/xfs/libxfs/xfs_bmap.c | 10 ++++++---- fs/xfs/libxfs/xfs_symlink_remote.c | 3 +++ 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c index 8e2010d..b5cb61e 100644 --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -948,14 +948,16 @@ xfs_bmap_local_to_extents( bp = xfs_btree_get_bufl(args.mp, tp, args.fsbno, 0); /* - * Initialise the block and copy the data + * Initialize the block, copy the data and log the remote buffer. * - * Note: init_fn must set the buffer log item type correctly! + * The callout is responsible for logging because the remote format + * might differ from the local format and thus we don't know how much to + * log here. Note that init_fn must also set the buffer log item type + * correctly. */ init_fn(tp, bp, ip, ifp); - /* account for the change in fork size and log everything */ - xfs_trans_log_buf(tp, bp, 0, ifp->if_bytes - 1); + /* account for the change in fork size */ xfs_idata_realloc(ip, -ifp->if_bytes, whichfork); xfs_bmap_local_to_extents_empty(ip, whichfork); flags |= XFS_ILOG_CORE; diff --git a/fs/xfs/libxfs/xfs_symlink_remote.c b/fs/xfs/libxfs/xfs_symlink_remote.c index 8f8af05..b9884aa 100644 --- a/fs/xfs/libxfs/xfs_symlink_remote.c +++ b/fs/xfs/libxfs/xfs_symlink_remote.c @@ -183,6 +183,7 @@ xfs_symlink_local_to_remote( if (!xfs_sb_version_hascrc(&mp->m_sb)) { bp->b_ops = NULL; memcpy(bp->b_addr, ifp->if_u1.if_data, ifp->if_bytes); + xfs_trans_log_buf(tp, bp, 0, ifp->if_bytes - 1); return; } @@ -198,4 +199,6 @@ xfs_symlink_local_to_remote( buf = bp->b_addr; buf += xfs_symlink_hdr_set(mp, ip->i_ino, 0, ifp->if_bytes, bp); memcpy(buf, ifp->if_u1.if_data, ifp->if_bytes); + xfs_trans_log_buf(tp, bp, 0, sizeof(struct xfs_dsymlink_hdr) + + ifp->if_bytes - 1); } -- 2.1.0 From prvs=77018c8472=joshua.earl@drexelmed.edu Wed Sep 16 11:50:42 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 0CF6D7F47 for ; Wed, 16 Sep 2015 11:50:42 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 4665DAC002 for ; Wed, 16 Sep 2015 09:50:41 -0700 (PDT) X-ASG-Debug-ID: 1442422234-04cbb005eb17ee60001-NocioJ Received: from pp-mta2.drexelmed.edu ([198.17.30.173]) by cuda.sgi.com with ESMTP id Zqg7TIJl7Jf3qsjg (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 16 Sep 2015 09:50:35 -0700 (PDT) X-Barracuda-Envelope-From: prvs=77018c8472=joshua.earl@drexelmed.edu X-Barracuda-Apparent-Source-IP: 198.17.30.173 Received: from pps.filterd (pp-mta2.drexelmed.edu [127.0.0.1]) by pp-mta2.drexelmed.edu (8.15.0.59/8.14.7) with SMTP id t8GGnrI7032503 for ; Wed, 16 Sep 2015 12:50:34 -0400 Received: from ncb-sv-103.ducom.edu ([10.16.20.136]) by pp-mta2.drexelmed.edu with ESMTP id 1wyb6sr4sv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 16 Sep 2015 12:50:33 -0400 Received: from NCB-SV-117.DUCOM.edu ([fe80::6519:3ee7:4c6f:f2df]) by NCB-SV-103.DUCOM.edu ([::1]) with mapi id 14.03.0248.002; Wed, 16 Sep 2015 12:50:30 -0400 From: "Earl, Joshua P" To: "xfs@oss.sgi.com" Subject: RE: xfsxyncd in 'D' state Thread-Topic: xfsxyncd in 'D' state X-ASG-Orig-Subj: RE: xfsxyncd in 'D' state Thread-Index: AdDwn8phEmHFJRKXQuG/nBBkF7izjQ== Date: Wed, 16 Sep 2015 16:50:29 +0000 Message-ID: <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2CA0@NCB-SV-117.DUCOM.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.15.69] Content-Type: multipart/alternative; boundary="_000_2CC86DBF85FEEC41A2DFE1647B40613D5DAF2CA0NCBSV117DUCOMed_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-09-16_04:2015-09-16,2015-09-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=ducom_outbound_notspam policy=ducom_outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1509160210 X-Barracuda-Connect: UNKNOWN[198.17.30.173] X-Barracuda-Start-Time: 1442422235 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE, RDNS_NONE, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22604 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS --_000_2CC86DBF85FEEC41A2DFE1647B40613D5DAF2CA0NCBSV117DUCOMed_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was also able to get the xfs_info after finally getting the drive remount= ed: [root@ncb-sv-016 ~]# xfs_info /home meta-data=3D/dev/sdb1 isize=3D256 agcount=3D70, agsize=3D26= 8435455 blks =3D sectsz=3D512 attr=3D2, projid32bit=3D0 data =3D bsize=3D4096 blocks=3D18554637056, ima= xpct=3D1 =3D sunit=3D0 swidth=3D0 blks naming =3Dversion 2 bsize=3D4096 ascii-ci=3D0 log =3Dinternal bsize=3D4096 blocks=3D521728, version= =3D2 =3D sectsz=3D512 sunit=3D0 blks, lazy-coun= t=3D1 realtime =3Dnone extsz=3D4096 blocks=3D0, rtextents=3D0 From: Earl, Joshua P Sent: Tuesday, September 15, 2015 1:53 PM To: 'xfs@oss.sgi.com' Subject: xfsxyncd in 'D' state Hello, I hope I'm writing to the correct list. I've recently run into a pr= oblem, which has me stumped. I'm running a cluster which shares an xfs fil= esystem to 10 nodes via nfs. This has been working for almost two years. = However, I've been running into trouble with the drive where if anything tr= ies to write to it at certain times it will simply hang, and every process = trying to write will also hang and go into the 'D' state. For example (jus= t editing a text file with emacs): [root@ncb-sv-016 ~]# ps aux|grep D USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2216 0.0 0.0 0 0 ? D 11:28 0:00 [xfssyncd/= sdb1] archana 7708 0.0 0.0 249700 13352 pts/0 D 11:35 0:00 emacs thin= gs root 11453 0.0 0.0 103312 868 pts/1 S+ 12:47 0:00 grep D This will remain like this for hours. Can't remount/unmount drive (sends t= he unmount command into 'D' state) I have no idea what's going on or how to fix it, but I'm hoping you guys mi= ght be able to point me in the right direction. Here is the info that's req= uested in the FAQ: ? kernel version (uname -a) Linux ncb-sv-016.ducom.edu 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:= 37:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ? xfsprogs version (xfs_repair -V) xfs_repair version 3.1.1 ? number of CPUs 16 ? contents of /proc/meminfo ? contents of /proc/mounts ? contents of /proc/partitions Attached except for mounts (not currently in the /proc directory, attached = the fstab instead (hopefully helpful?) ? RAID layout (hardware and/or software) The RAID-6 is the problem one Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVr= fy ---------------------------------------------------------------------------= --- u0 RAID-1 OK - - - 3725.28 RiW ON u1 RAID-6 OK - - 64K 70780.3 RiW ON u2 SPARE OK - - - 3726.01 - OFF VPort Status Unit Size Type Phy Encl-Slot Model ---------------------------------------------------------------------------= --- p8 OK u0 3.63 TB SATA - /c0/e0/slt0 WDC WD4000FYYZ-0= 1UL p9 OK u1 3.63 TB SATA - /c0/e0/slt4 WDC WD4000FYYZ-0= 1UL p10 OK u1 3.63 TB SATA - /c0/e0/slt8 WDC WD4000FYYZ-0= 1UL p11 OK u1 3.63 TB SATA - /c0/e0/slt12 WDC WD4000FYYZ-0= 1UL p12 OK u1 3.63 TB SATA - /c0/e0/slt16 WDC WD4000FYYZ-0= 1UL p13 OK u1 3.63 TB SATA - /c0/e0/slt20 WDC WD4000FYYZ-0= 1UL p14 OK u0 3.63 TB SATA - /c0/e0/slt1 WDC WD4000FYYZ-0= 1UL p15 OK u1 3.63 TB SATA - /c0/e0/slt5 WDC WD4000FYYZ-0= 1UL p16 OK u1 3.63 TB SATA - /c0/e0/slt9 WDC WD4000FYYZ-0= 1UL p17 OK u1 3.63 TB SATA - /c0/e0/slt13 WDC WD4000FYYZ-0= 1UL p18 OK u1 3.63 TB SATA - /c0/e0/slt17 WDC WD4000FYYZ-0= 1UL p19 OK u1 3.63 TB SATA - /c0/e0/slt21 WDC WD4000FYYZ-0= 1UL p20 OK u1 3.63 TB SATA - /c0/e0/slt2 WDC WD4000FYYZ-0= 1UL p21 OK u1 3.63 TB SATA - /c0/e0/slt6 WDC WD4000FYYZ-0= 1UL p22 OK u1 3.63 TB SATA - /c0/e0/slt10 WDC WD4000FYYZ-0= 1UL p23 OK u1 3.63 TB SATA - /c0/e0/slt14 WDC WD4000FYYZ-0= 1UL p24 OK u1 3.63 TB SATA - /c0/e0/slt18 WDC WD4000FYYZ-0= 1UL p25 OK u1 3.63 TB SATA - /c0/e0/slt22 WDC WD4000FYYZ-0= 1UL p26 OK u1 3.63 TB SATA - /c0/e0/slt3 WDC WD4000FYYZ-0= 1UL p27 OK u1 3.63 TB SATA - /c0/e0/slt7 WDC WD4000FYYZ-0= 1UL p28 OK u1 3.63 TB SATA - /c0/e0/slt11 WDC WD4000FYYZ-0= 1UL p29 OK u1 3.63 TB SATA - /c0/e0/slt15 WDC WD4000FYYZ-0= 1UL p30 OK u1 3.63 TB SATA - /c0/e0/slt19 WDC WD4000FYYZ-0= 1UL p31 OK u2 3.63 TB SATA - /c0/e0/slt23 WDC WD4000FYYZ-0= 1UL ? LVM configuration I don't *think* these are in an LVM.. I could be wrong. ? type of disks you are using Models included above in raid config. ? write cache status of drives ? size of BBWC and mode it is running in ? xfs_info output on the filesystem in question For the above three questions I'm not sure how to get the the cache status = of the drives, or what the BBWC is? xfs_info won't currently run (I'm waiti= ng on the drive to unmount) but I ran an xfs_check and an xfs_repair -n and= no errors were shown. ? dmesg output showing all error messages and stack traces Then you need to describe your workload that is causing the problem, and a = demonstration of the bad behaviour that is occurring. If it is a performanc= e problem, then 30s - 1 minute samples of: 1. iostat -x -d -m 5 [root@ncb-sv-016 ~]# iostat -x -d -m 5 Linux 2.6.32-358.23.2.el6.x86_64 (ncb-sv-016.ducom.edu) 09/15/2015 = _x86_64_ (16 CPU) Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.29 3.61 5.78 3.58 0.10 0.03 28.27 = 0.05 5.19 2.39 2.24 sdb 1.02 8.66 31.50 3.91 0.33 0.12 26.14 = 5.94 167.54 27.47 97.25 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 1.60 0.00 2.00 0.00 0.01 14.40 = 0.01 4.30 4.30 0.86 sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 = 6.46 6332.75 1250.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 3.60 0.00 7.00 0.00 0.04 12.11 = 0.02 0.60 1.77 1.24 sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 = 6.28 6256.60 1000.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.40 0.00 0.00 8.00 = 0.00 42.50 12.00 0.48 sdb 0.00 0.00 0.00 1.20 0.00 0.04 64.00 = 5.86 5846.33 833.33 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.60 0.00 0.60 0.00 0.00 16.00 = 0.01 12.67 12.67 0.76 sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 = 6.86 5725.20 1000.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 = 0.00 0.00 0.00 0.00 sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 = 6.06 5459.00 1000.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 4.00 0.00 1.60 0.00 0.02 26.00 = 0.01 6.75 6.50 1.04 sdb 0.00 0.00 0.00 1.00 0.00 0.03 51.20 = 7.05 5670.40 1000.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 29.40 0.00 2.60 0.00 0.12 98.46 = 0.01 4.54 4.08 1.06 sdb 0.00 0.00 0.00 1.20 0.00 0.03 53.33 = 6.54 7428.50 833.33 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 9.60 0.00 15.80 0.00 0.10 12.86 = 0.57 35.82 3.37 5.32 sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 = 6.30 5889.20 1000.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 7.80 0.00 12.80 0.00 0.08 12.38 = 0.74 58.09 15.06 19.28 sdb 0.00 0.00 0.00 1.20 0.00 0.04 64.00 = 6.49 6140.83 833.33 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 4.80 0.00 3.20 0.00 0.03 20.00 = 0.01 0.06 3.12 1.00 sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 = 5.10 6489.25 1250.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.20 0.00 0.00 8.00 = 0.02 152.00 103.00 2.06 sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 = 6.75 5791.00 1000.20 100.02 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 61.20 0.00 11.80 0.00 0.29 49.49 = 0.01 0.88 0.69 0.82 sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 = 6.37 5569.71 714.14 99.98 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.40 0.00 0.60 0.00 0.00 13.33 = 0.01 24.33 24.33 1.46 sdb 0.00 0.00 0.00 1.60 0.00 0.05 64.00 = 5.77 5162.00 625.12 100.02 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.40 0.00 0.00 8.00 = 0.00 3.00 1.50 0.06 sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 = 5.08 3428.50 1250.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 1.60 0.00 0.80 0.00 0.01 24.00 = 0.01 10.75 10.75 0.86 sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 = 5.86 3932.14 714.29 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 2.00 0.00 4.80 0.00 0.03 11.33 = 0.01 2.21 2.08 1.00 sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 = 5.60 3992.71 714.29 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 5.00 0.00 18.20 0.00 0.09 10.20 = 0.02 1.13 0.03 0.06 sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 = 5.44 4208.86 714.29 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 1.40 0.00 0.60 0.00 0.01 26.67 = 0.02 27.00 27.00 1.62 sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 = 5.22 4325.43 714.29 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.60 0.00 0.40 0.00 0.00 20.00 = 0.01 15.50 15.50 0.62 sdb 0.00 0.00 0.00 1.60 0.00 0.05 64.00 = 5.06 4022.75 625.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 = 0.00 0.00 0.00 0.00 sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 = 5.08 3495.50 1250.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 1.60 0.00 1.60 0.00 0.01 12.00 = 0.07 42.88 42.50 6.80 sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 = 5.82 3894.71 714.29 100.00 2. vmstat 5 [root@ncb-sv-016 ~]# vmstat 5 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu= ----- r b swpd free buff cache si so bi bo in cs us sy id w= a st 0 0 0 126125768 19456 405396 0 0 28 10 421 150 0 0 9= 9 0 0 0 0 0 126125520 19464 405396 0 0 0 34 6679 13281 0 0 = 100 0 0 1 0 0 126124896 19472 405392 0 0 0 38 6718 13310 0 0 = 100 0 0 0 0 0 126125312 19472 405400 0 0 0 74 6658 13256 0 0 = 100 0 0 0 0 0 126125440 19480 405392 0 0 0 60 6664 13291 0 0 = 100 0 0 2 0 0 126125440 19480 405400 0 0 0 26 6660 13272 0 0 = 100 0 0 0 0 0 126125680 19488 405400 0 0 0 30 6659 13282 0 0 = 100 0 0 2 0 0 126125696 19496 405396 0 0 0 117 6686 13298 0 0 = 100 0 0 1 0 0 126125568 19496 405400 0 0 0 33 6661 13287 0 0 = 100 0 0 0 0 0 126125816 19504 405400 0 0 0 30 6663 13271 0 0 = 100 0 0 1 0 0 126125816 19504 405400 0 0 0 27 6659 13285 0 0 = 100 0 0 0 0 0 126125696 19512 405400 0 0 0 75 6670 13269 0 0 = 100 0 0 0 0 0 126125816 19520 405400 0 0 0 55 6671 13286 0 0 = 100 0 0 2 0 0 126125696 19528 405396 0 0 0 34 6670 13284 0 0 = 100 0 0 0 0 0 126125272 19528 405400 0 0 0 26 6700 13298 0 0 = 100 0 0 0 0 0 126125408 19536 405400 0 0 0 61 6660 13277 0 0 = 100 0 0 1 0 0 126125536 19544 405392 0 0 0 98 6677 13281 0 0 = 100 0 0 can give us insight into the IO and memory utilisation of your machine at t= he time of the problem. If the filesystem is hanging, then capture the output of the dmesg command = after running: # echo w > /proc/sysrq-trigger # dmesg will tell us all the hung processes in the machine, often pointing us direc= tly to the cause of the hang. Attached Thanks! Josh Earl, MS Research Instructor Drexel College of Medicine Center for Advanced Microbial Processing (CAMP) Institute of Molecular Medicine and Infectious Disease (215) 762-8133 ________________________________ This email and any accompanying attachments are confidential. The informati= on is intended solely for the use of the individual to whom it is addressed= . Any review, disclosure, copying, distribution, or use of this email commu= nication by others is strictly prohibited. If you are not the intended reci= pient, please notify the sender immediately and delete all copies. Thank yo= u for your cooperation. --_000_2CC86DBF85FEEC41A2DFE1647B40613D5DAF2CA0NCBSV117DUCOMed_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was also able to get= the xfs_info after finally getting the drive remounted:<= /p>

 

[= root@ncb-sv-016 ~]# xfs_info /home

m= eta-data=3D/dev/sdb1         &= nbsp;    isize=3D256    agcount=3D70, agsize= =3D268435455 blks

&= nbsp;        =3D    =             &nb= sp;      sectsz=3D512   attr=3D2, projid= 32bit=3D0

d= ata     =3D       &n= bsp;            = ;   bsize=3D4096   blocks=3D18554637056, imaxpct=3D1

&= nbsp;        =3D    =             &nb= sp;      sunit=3D0      s= width=3D0 blks

n= aming   =3Dversion 2       &nb= sp;      bsize=3D4096   ascii-ci=3D0

l= og      =3Dinternal     &= nbsp;         bsize=3D4096 &nb= sp; blocks=3D521728, version=3D2

&= nbsp;        =3D    =             &nb= sp;      sectsz=3D512   sunit=3D0 blks, = lazy-count=3D1

r= ealtime =3Dnone          =          extsz=3D4096   b= locks=3D0, rtextents=3D0

 

From: Earl, Joshua P
Sent: Tuesday, September 15, 2015 1:53 PM
To: 'xfs@oss.sgi.com' <xfs@oss.sgi.com>
Subject: xfsxyncd in 'D' state

 

Hello, I hope I’m writing to the correct list.=   I’ve recently run into a problem, which has me stumped.  = I’m running a cluster which shares an xfs filesystem to 10 nodes via = nfs.  This has been working for almost two years.  However, IR= 17;ve been running into trouble with the drive where if anything tries to write = to it at certain times it will simply hang, and every process trying to wri= te will also hang and go into the ‘D’ state.  For example = (just editing a text file with emacs):

 

[root@ncb-sv-01= 6 ~]# ps aux|grep D

USER  = ;     PID %CPU %MEM    VSZ   R= SS TTY      STAT START   TIME COMMAND

root  = ;    2216  0.0  0.0      = 0     0 ?        D&n= bsp;   11:28   0:00 [xfssyncd/sdb1]

archana &n= bsp; 7708  0.0  0.0 249700 13352 pts/0    D &= nbsp;  11:35   0:00 emacs things

root  = ;   11453  0.0  0.0 103312   868 pts/1 &= nbsp;  S+   12:47   0:00 grep D

 

This will remain like this for hours.  Can̵= 7;t remount/unmount drive (sends the unmount command into ‘D’ s= tate)

 

I have no idea what’s going on or how to fix i= t, but I’m hoping you guys might be able to point me in the right dir= ection. Here is the info that’s requested in the FAQ:

§  kernel version (uname -a)

Linux ncb-sv-016.ducom.edu 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed = Oct 16 18:37:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

§  xfsprogs version (xfs_repair -V)

xfs_repair version 3.1.1

§  number of CPUs

16

§  contents of /proc/meminfo

§  contents of /proc/mounts

§  contents of /proc/partitions<= /o:p>

Attached except for mounts (not currently in the /proc directory,= attached the fstab instead (hopefully helpful?)

§  RAID layout (hardware and/or softw= are) The RAID-6 is the problem one

Unit = UnitType  Status         %RCm= pl  %V/I/M  Stripe  Size(GB)  Cache  AVrfy

----------= --------------------------------------------------------------------

u0 &n= bsp;  RAID-1    OK      &= nbsp;      -       -=        -       = 3725.28   RiW    ON    

u1 &n= bsp;  RAID-6    OK      &= nbsp;      -       -=        64K     70780.3&nb= sp;  RiW    ON    

u2 &n= bsp;  SPARE     OK     &n= bsp;       -     &nb= sp; -       -     &n= bsp; 3726.01   -      OFF  &nb= sp;

 = ;

VPort Stat= us         Unit Size  &nb= sp;   Type  Phy Encl-Slot    Model=

----------= --------------------------------------------------------------------

p8 &n= bsp;  OK          &n= bsp;  u0   3.63 TB   SATA  -   /c0/= e0/slt0  WDC WD4000FYYZ-01UL

p9 &n= bsp;  OK          &n= bsp;  u1   3.63 TB   SATA  -   /c0/= e0/slt4  WDC WD4000FYYZ-01UL

p10 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t8  WDC WD4000FYYZ-01UL

p11 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t12 WDC WD4000FYYZ-01UL

p12 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t16 WDC WD4000FYYZ-01UL

p13 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t20 WDC WD4000FYYZ-01UL

p14 &= nbsp; OK           &= nbsp; u0   3.63 TB   SATA  -   /c0/e0/sl= t1  WDC WD4000FYYZ-01UL

p15 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t5  WDC WD4000FYYZ-01UL

p16 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t9  WDC WD4000FYYZ-01UL

p17 &= nbsp; OK            =  u1   3.63 TB   SATA  -   /c0/e0/sl= t13 WDC WD4000FYYZ-01UL

p18 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t17 WDC WD4000FYYZ-01UL

p19 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t21 WDC WD4000FYYZ-01UL

p20 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t2  WDC WD4000FYYZ-01UL

p21 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t6  WDC WD4000FYYZ-01UL

p22 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t10 WDC WD4000FYYZ-01UL

p23 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t14 WDC WD4000FYYZ-01UL

p24 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t18 WDC WD4000FYYZ-01UL

p25 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t22 WDC WD4000FYYZ-01UL

p26 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t3  WDC WD4000FYYZ-01UL

p27 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t7  WDC WD4000FYYZ-01UL

p28 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t11 WDC WD4000FYYZ-01UL

p29 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t15 WDC WD4000FYYZ-01UL

p30 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t19 WDC WD4000FYYZ-01UL

p31 &= nbsp; OK           &= nbsp; u2   3.63 TB   SATA  -   /c0/e0/sl= t23 WDC WD4000FYYZ-01UL

§  LVM configuration

I don’t *think* these are in an LVM.. I could be wro= ng.

§  type of disks you are using

Models included above in raid config.

§  write cache status of drives<= /o:p>

§  size of BBWC and mode it is runnin= g in

§  xfs_info output on the filesystem = in question

For the above three questions I’m not sure how to get the t= he cache status of the drives, or what the BBWC is? xfs_info won’t cu= rrently run (I’m waiting on the drive to unmount) but I ran an xfs_check and an xfs_repair –n and no errors were shown.=

§  dmesg output showing all error mes= sages and stack traces

Then you need to describe your workload that is causing the probl= em, and a demonstration of the bad behaviour that is occurring. If it is a = performance problem, then 30s - 1 minute samples of:

1.    iostat -x -d -m 5

[root@ncb-sv-016 ~]# iostat -x -d -m 5

Linux 2.6.= 32-358.23.2.el6.x86_64 (ncb-sv-016.ducom.edu)      = ; 09/15/2015    _x86_64_      (16 CPU)

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.29     3.61    5.78  &nbs= p; 3.58     0.10     0.03 &nbs= p;  28.27     0.05    5.19 &nb= sp; 2.39   2.24

sdb &= nbsp;            &nb= sp;1.02     8.66   31.50    3.= 91     0.33     0.12  &nb= sp; 26.14     5.94  167.54  27.47  97.25=

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     1.60    0.00  &nbs= p; 2.00     0.00     0.01 &nbs= p;  14.40     0.01    4.30 &nb= sp; 4.30   0.86

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.80     0.00     0.03 &nbs= p;  64.00     6.46 6332.75 1250.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     3.60    0.00  &nbs= p; 7.00     0.00     0.04 &nbs= p;  12.11     0.02    0.60 &nb= sp; 1.77   1.24

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.00     0.00     0.03 &nbs= p;  64.00     6.28 6256.60 1000.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.40     0.00     0.00 &nbs= p;   8.00     0.00   42.50  12= .00   0.48

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.20     0.00     0.04 &nbs= p;  64.00     5.86 5846.33 833.33 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.60    0.00  &nbs= p; 0.60     0.00     0.00 &nbs= p;  16.00     0.01   12.67  12.67&n= bsp;  0.76

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.00     0.00     0.03 &nbs= p;  64.00     6.86 5725.20 1000.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.00     0.00     0.00 &nbs= p;   0.00     0.00    0.00&nbs= p;  0.00   0.00

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.00     0.00     0.03 &nbs= p;  64.00     6.06 5459.00 1000.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     4.00    0.00  &nbs= p; 1.60     0.00     0.02 &nbs= p;  26.00     0.01    6.75 &nb= sp; 6.50   1.04

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.00     0.00     0.03 &nbs= p;  51.20     7.05 5670.40 1000.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00    29.40    0.00    2.= 60     0.00     0.12  &nb= sp; 98.46     0.01    4.54   4= .08   1.06

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.20     0.00     0.03 &nbs= p;  53.33     6.54 7428.50 833.33 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     9.60    0.00   15.= 80     0.00     0.10  &nb= sp; 12.86     0.57   35.82   3.37&n= bsp;  5.32

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.00     0.00     0.03 &nbs= p;  64.00     6.30 5889.20 1000.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     7.80    0.00   12.= 80     0.00     0.08  &nb= sp; 12.38     0.74   58.09  15.06  = 19.28

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.20     0.00     0.04 &nbs= p;  64.00     6.49 6140.83 833.33 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     4.80    0.00  &nbs= p; 3.20     0.00     0.03 &nbs= p;  20.00     0.01    0.06 &nb= sp; 3.12   1.00

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.80     0.00     0.03 &nbs= p;  64.00     5.10 6489.25 1250.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.20     0.00     0.00 &nbs= p;   8.00     0.02  152.00 103.00 &= nbsp; 2.06

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.00     0.00     0.03 &nbs= p;  64.00     6.75 5791.00 1000.20 100.02

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00    61.20    0.00   11.80&nb= sp;    0.00     0.29    4= 9.49     0.01    0.88   0.69&n= bsp;  0.82

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.40     0.00     0.04 &nbs= p;  64.00     6.37 5569.71 714.14  99.98=

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.40    0.00  &nbs= p; 0.60     0.00     0.00 &nbs= p;  13.33     0.01   24.33  24.33&n= bsp;  1.46

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.60     0.00     0.05 &nbs= p;  64.00     5.77 5162.00 625.12 100.02

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.40     0.00     0.00 &nbs= p;   8.00     0.00    3.00&nbs= p;  1.50   0.06

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.80     0.00     0.03 &nbs= p;  64.00     5.08 3428.50 1250.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     1.60    0.00  &nbs= p; 0.80     0.00     0.01 &nbs= p;  24.00     0.01   10.75  10.75&n= bsp;  0.86

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.40     0.00     0.04 &nbs= p;  64.00     5.86 3932.14 714.29 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     2.00    0.00  &nbs= p; 4.80     0.00     0.03 &nbs= p;  11.33     0.01    2.21 &nb= sp; 2.08   1.00

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.40     0.00     0.04 &nbs= p;  64.00     5.60 3992.71 714.29 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     5.00    0.00   18.= 20     0.00     0.09  &nb= sp; 10.20     0.02    1.13   0= .03   0.06

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.40     0.00     0.04 &nbs= p;  64.00     5.44 4208.86 714.29 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     1.40    0.00  &nbs= p; 0.60     0.00     0.01 &nbs= p;  26.67     0.02   27.00  27.00&n= bsp;  1.62

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.40     0.00     0.04 &nbs= p;  64.00     5.22 4325.43 714.29 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.60    0.00  &nbs= p; 0.40     0.00     0.00 &nbs= p;  20.00     0.01   15.50  15.50&n= bsp;  0.62

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.60     0.00     0.05 &nbs= p;  64.00     5.06 4022.75 625.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.00     0.00     0.00 &nbs= p;   0.00     0.00    0.00&nbs= p;  0.00   0.00

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.80     0.00     0.03 &nbs= p;  64.00     5.08 3495.50 1250.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     1.60    0.00  &nbs= p; 1.60     0.00     0.01 &nbs= p;  12.00     0.07   42.88  42.50&n= bsp;  6.80

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.40     0.00     0.04 &nbs= p;  64.00     5.82 3894.71 714.29 100.00

2.    vmstat 5

[root@ncb-sv-016 ~]# vmstat 5

procs ----= -------memory---------- ---swap-- -----io---- --system-- -----cpu-----=

r  b&= nbsp;  swpd   free   buff  cache   = si   so    bi    bo   in&= nbsp;  cs us sy id wa st

0  0&= nbsp;     0 126125768  19456 405396  &nb= sp; 0    0    28    10  4= 21  150  0  0 99  0  0    &nbs= p;

0  0&= nbsp;     0 126125520  19464 405396  &nb= sp; 0    0     0    34 66= 79 13281  0  0 100  0  0   

1  0&= nbsp;     0 126124896  19472 405392  &nb= sp; 0    0     0    38 67= 18 13310  0  0 100  0  0   

0  0&= nbsp;     0 126125312  19472 405400  &nb= sp; 0    0     0    74 66= 58 13256  0  0 100  0  0   

0  0&= nbsp;     0 126125440  19480 405392  &nb= sp; 0    0     0    60 66= 64 13291  0  0 100  0  0   

2  0&= nbsp;     0 126125440  19480 405400  &nb= sp; 0    0     0    26 66= 60 13272  0  0 100  0  0   

0  0&= nbsp;     0 126125680  19488 405400  &nb= sp; 0    0     0    30 66= 59 13282  0  0 100  0  0   

2  0&= nbsp;     0 126125696  19496 405396  &nb= sp; 0    0     0   117 6686 13= 298  0  0 100  0  0   

1  0&= nbsp;     0 126125568  19496 405400  &nb= sp; 0    0     0    33 66= 61 13287  0  0 100  0  0   

0  0&= nbsp;     0 126125816  19504 405400  &nb= sp; 0    0     0    30 66= 63 13271  0  0 100  0  0   

1  0&= nbsp;     0 126125816  19504 405400  &nb= sp; 0    0     0    27 66= 59 13285  0  0 100  0  0   

0  0&= nbsp;     0 126125696  19512 405400  &nb= sp; 0    0     0    75 66= 70 13269  0  0 100  0  0   

0  0&= nbsp;     0 126125816  19520 405400  &nb= sp; 0    0     0    55 66= 71 13286  0  0 100  0  0   

2  0&= nbsp;     0 126125696  19528 405396  &nb= sp; 0    0     0    34 66= 70 13284  0  0 100  0  0   

0  0&= nbsp;     0 126125272  19528 405400  &nb= sp; 0    0     0    26 67= 00 13298  0  0 100  0  0   

0  0&= nbsp;     0 126125408  19536 405400  &nb= sp; 0    0     0    61 66= 60 13277  0  0 100  0  0   

1  0&= nbsp;     0 126125536  19544 405392  &nb= sp; 0    0     0    98 66= 77 13281  0  0 100  0  0   

can give us insight into the IO and memory utilisation of your ma= chine at the time of the problem.

If the filesystem is hanging, then capture the output of the dmes= g command after running:

# echo w > /proc/sysrq-trigger

# dmesg

will tell us all the hung processes in the machine, often pointin= g us directly to the cause of the hang.

Attached

 

Thanks!

 

Josh Earl, MS

Research Instructor

Drexel College of Medici= ne

Center for Advanced Microbial Processing (CAMP)<= /o:p>

Institute of Molecular Medicine and Infectious Diseas= e

(215) 762-8133

 

This email and any accompanying attachments are confidential. The informati= on is intended solely for the use of the individual to whom it is addressed= . Any review, disclosure, copying, distribution, or use of this email commu= nication by others is strictly prohibited. If you are not the intended recipient, please notify the sender immediatel= y and delete all copies. Thank you for your cooperation.

--_000_2CC86DBF85FEEC41A2DFE1647B40613D5DAF2CA0NCBSV117DUCOMed_-- From lp-xfs=oss.sgi.com@cheloman.com Wed Sep 16 13:50:54 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id AFD607F47 for ; Wed, 16 Sep 2015 13:50:54 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 81E8C304059 for ; Wed, 16 Sep 2015 11:50:54 -0700 (PDT) X-ASG-Debug-ID: 1442429450-04bdf04db317efc0002-NocioJ Received: from name.cheloman.com (name.cheloman.com [107.181.178.27]) by cuda.sgi.com with ESMTP id 1kudZDGcPLzun88v for ; Wed, 16 Sep 2015 11:50:53 -0700 (PDT) X-Barracuda-Envelope-From: lp-xfs=oss.sgi.com@cheloman.com X-Barracuda-Apparent-Source-IP: 107.181.178.27 Received: by name.cheloman.com id hv6t0q0001gu for ; Wed, 16 Sep 2015 11:41:01 -0700 (envelope-from ) MIME-Version: 1.0 From: "Life-Policy" To: xfs@oss.sgi.com Subject: Only $15 for Fidelity Life Coverage Date: Wed, 16 Sep 2015 11:41:01 -0700 X-ASG-Orig-Subj: Only $15 for Fidelity Life Coverage Content-Type: text/plain; Message-ID: <0.0.0.65.1D0F0AF3C188DF6.A2C283@name.cheloman.com> X-Barracuda-Connect: name.cheloman.com[107.181.178.27] X-Barracuda-Start-Time: 1442429453 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-Spam-Score: 1.50 X-Barracuda-Spam-Status: No, SCORE=1.50 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MV0702 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22607 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.50 BSF_SC0_MV0702 Custom rule MV0702 How much do you love your family? Get piece of mind for only $15 a month. Protect your loved ones and know they will always be cared for. Get a free quote from the top-rated life insurance companies at http://cheloman.com/y2vOQQKjEnyw0z8cFAl4/FidelityLife . . . . . . . . . . . . . . To remove yourself go to : http://cheloman.com/n8pA0uzysXpmP8Yow5K7/RemoveFidelity 4412 Gladwell Street, Munford, TN 38058 From lp-xfs=oss.sgi.com@cheloman.com Wed Sep 16 13:50:57 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2FE0C7F54 for ; Wed, 16 Sep 2015 13:50:57 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id F0498304053 for ; Wed, 16 Sep 2015 11:50:53 -0700 (PDT) X-ASG-Debug-ID: 1442429450-04bdf04db317efc0001-NocioJ Received: from name.cheloman.com (name.cheloman.com [107.181.178.27]) by cuda.sgi.com with ESMTP id nSMnhAqq5wIaNbmX for ; Wed, 16 Sep 2015 11:50:51 -0700 (PDT) X-Barracuda-Envelope-From: lp-xfs=oss.sgi.com@cheloman.com X-Barracuda-Apparent-Source-IP: 107.181.178.27 Received: by name.cheloman.com id hv6t0q0001gu for ; Wed, 16 Sep 2015 11:37:00 -0700 (envelope-from ) MIME-Version: 1.0 From: "Life-Policy" To: xfs@oss.sgi.com Subject: Only $15 for Fidelity Life Coverage Date: Wed, 16 Sep 2015 11:37:00 -0700 X-ASG-Orig-Subj: Only $15 for Fidelity Life Coverage Content-Type: text/plain; Message-ID: <0.0.0.11.1D0F0AEACB500B8.5FE878@name.cheloman.com> X-Barracuda-Connect: name.cheloman.com[107.181.178.27] X-Barracuda-Start-Time: 1442429450 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.50 X-Barracuda-Spam-Status: No, SCORE=1.50 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MV0702 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22607 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.50 BSF_SC0_MV0702 Custom rule MV0702 How much do you love your family? Get piece of mind for only $15 a month. Protect your loved ones and know they will always be cared for. Get a free quote from the top-rated life insurance companies at http://cheloman.com/y2vOQQKjEnyw0z8cFAl4/FidelityLife . . . . . . . . . . . . . . To remove yourself go to : http://cheloman.com/n8pA0uzysXpmP8Yow5K7/RemoveFidelity 4412 Gladwell Street, Munford, TN 38058 From david@fromorbit.com Wed Sep 16 17:35:27 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 368A97F47 for ; Wed, 16 Sep 2015 17:35:27 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id B6F64AC004 for ; Wed, 16 Sep 2015 15:35:26 -0700 (PDT) X-ASG-Debug-ID: 1442442923-04cbb005ec189cf0001-NocioJ Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id WN0oJRbbp8DFFCMn for ; Wed, 16 Sep 2015 15:35:24 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.129 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CNEgAf7vlVPOV8LHlegyOBPYZZokEBAQEBAQEGimuRHQICAQECgUJNAQEBAQEBBwEBAQFBP4QjAQEBAwE6HCMFCwgDDgoJJQ8FJQMHGhOIJgfKGAEBCAIBHxmGE4VEhQ0HhCwFkjaDKI0AgVGHVpFuhHYsM4oqAQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail06.adl2.internode.on.net with ESMTP; 17 Sep 2015 08:04:36 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZcLHf-0003Nm-MZ; Thu, 17 Sep 2015 08:34:35 +1000 Date: Thu, 17 Sep 2015 08:34:35 +1000 From: Dave Chinner To: Brian Foster Cc: David Jeffery , xfs@oss.sgi.com Subject: Re: [PATCH] xfs: add missing ilock around dio write last extent alignment Message-ID: <20150916223435.GW26895@dastard> X-ASG-Orig-Subj: Re: [PATCH] xfs: add missing ilock around dio write last extent alignment References: <1441809812-60175-1-git-send-email-bfoster@redhat.com> <20150913235835.GV26895@dastard> <20150914132455.GA22770@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150914132455.GA22770@bfoster.bfoster> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1442442923 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22614 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Mon, Sep 14, 2015 at 09:24:55AM -0400, Brian Foster wrote: > On Mon, Sep 14, 2015 at 09:58:35AM +1000, Dave Chinner wrote: > > On Wed, Sep 09, 2015 at 10:43:32AM -0400, Brian Foster wrote: > > > The iomap codepath (via get_blocks()) acquires and release the inode > > > lock in the case of a direct write that requires block allocation. This > > > is because xfs_iomap_write_direct() allocates a transaction, which means > > > the ilock must be dropped and reacquired after the transaction is > > > allocated and reserved. > > > > > > xfs_iomap_write_direct() invokes xfs_iomap_eof_align_last_fsb() before > > > the transaction is created and thus before the ilock is reacquired. This > > > can lead to calls to xfs_iread_extents() and reads of the in-core extent > > > list without any synchronization (via xfs_bmap_eof() and > > > xfs_bmap_last_extent()). xfs_iread_extents() assert fails if the ilock > > > is not held, but this is not currently seen in practice as the current > > > callers had already invoked xfs_bmapi_read(). > > > > > > What has been seen in practice are reports of crashes down in the > > > xfs_bmap_eof() codepath on direct writes due to seemingly bogus pointer > > > references from xfs_iext_get_ext(). While an explicit reproducer is not > > > currently available to confirm the cause of the problem, crash analysis > > > and code inspection from David Jeffrey had identified the insufficient > > > locking. > > > > > > xfs_iomap_eof_align_last_fsb() is called from other contexts with the > > > inode lock already held. __xfs_get_blocks() acquires and drops the ilock > > > with variable flags. Therefore, take the simple approach to cycle ilock > > > around the last extent alignment call from xfs_iomap_write_direct(). > > > > > > Reported-by: David Jeffery > > > Signed-off-by: Brian Foster > > > --- > > > fs/xfs/xfs_iomap.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c > > > index 1f86033..4d7534e 100644 > > > --- a/fs/xfs/xfs_iomap.c > > > +++ b/fs/xfs/xfs_iomap.c > > > @@ -142,7 +142,9 @@ xfs_iomap_write_direct( > > > offset_fsb = XFS_B_TO_FSBT(mp, offset); > > > last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); > > > if ((offset + count) > XFS_ISIZE(ip)) { > > > + xfs_ilock(ip, XFS_ILOCK_EXCL); > > > error = xfs_iomap_eof_align_last_fsb(mp, ip, extsz, &last_fsb); > > > + xfs_iunlock(ip, XFS_ILOCK_EXCL); > > > > XFS_ILOCK_SHARED? > > > > I suspect that is technically sufficient in this particular call path > given that we've called xfs_bmapi_read(). The problem is that there is a > call to xfs_iread_extents() buried a few calls deep in > xfs_bmap_last_extent(). Sure. > My understanding is that we need the exclusive > lock because it's not safe for multiple threads to populate the in-core > extent list at the same time, so I don't really want to replace the > existing race with a landmine should the context happen to change in the > future. yes, but that can't happen here because we are guaranteed to have the extent list in memory because we've alreay called xfs_bmapi_read() and that will populate the extent list with the appropriate lock held. > > Also, looking at __xfs_get_blocks(), we drop the ilock immediately > > before calling xfs_iomap_write_direct(), which we already hold in > > shared mode for the xfs_bmapi_read() for direct IO. > > > > Can we push that lock dropping into xfs_iomap_write_direct() after > > we've done the xfs_iomap_eof_align_last_fsb() call and before we do > > transaction reservations so we don't need an extra lock round-trip > > here? e.g. xfs_iomap_write_delay() is called under the lock context > > held by __xfs_get_blocks().... > > > > That was my initial thought when looking at this code... e.g., to just > carry the lock over and drop it prior to transaction setup. I didn't go > that route because __xfs_get_blocks() uses a variable locking mode and > it seemed ugly to pass along the lock mode to xfs_iomap_direct_write(). > Further, given the above it also looked like we'd have to check and > cycle the ilock EXCL if it were ILOCK_SHARED. Finally, No, because the __xfs_get_blocks code calls xfs_ilock_data_map_shared() for direct IO, so already holds the correct lock for populating the extent list (not that this matters here). > xfs_iomap_direct_write() has a call to xfs_qm_dqattach() which itself > acquires ILOCK_EXCL. Looking at xfs_iomap_write_delay(), we do have a > dqattach_locked() variant but it also expects to have ILOCK_EXCL. That can be moved to after we've calculated the last extent. i.e. to just before we start the transaction.... > The only thing I'm not sure about is the shared lock safe version of > xfs_iomap_eof_align_last_fsb(). All the callers are guaranteed to have first populated the extent list, so this should be safe. If you are really worried, add an assert that verifies either ILOCK_EXCL or (ILOCK_SHARED && extents read in) > xfs_iread_extents() if it were called). Also, I take it we can safely > assume the in-core extent list is still around if we still hold the lock > from the xfs_bmapi_read() call. Thoughts? I guess I'll float another > patch... Once the extents are read in, they are in memory until the inode is reclaimed. That won't happen while we have active references to it. :) Cheers, Dave. -- Dave Chinner david@fromorbit.com From viktor@troja.ch Wed Sep 16 19:37:02 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 65B607F47 for ; Wed, 16 Sep 2015 19:37:02 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 37C148F804B for ; Wed, 16 Sep 2015 17:36:58 -0700 (PDT) X-ASG-Debug-ID: 1442450210-04bdf04db418b750001-NocioJ Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by cuda.sgi.com with ESMTP id y8bGuMJvaCqwPQRZ (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 16 Sep 2015 17:36:51 -0700 (PDT) X-Barracuda-Envelope-From: viktor@troja.ch X-Barracuda-Apparent-Source-IP: 209.85.212.180 Received: by wicgb1 with SMTP id gb1so96318409wic.1 for ; Wed, 16 Sep 2015 17:36:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=9cL61/egd8cU508P+drx9+UXtPrIKX30dhOHTMrA3xE=; b=fRZs5xGerLd/KaoAIfUnY2K8rf9NOw3sQGaXzMq8JQ6Ms3WeYFCW9NKdIlU8iZXaHl y/vZkFIFaivAgSN/tC7ZgDBG8LJJnmE/8/H2gkjOG2rKPJkKUkK5HxrKZG8KGLqyA5um lVqoI6JAjuZXOnJkheKCGxhyYqMHkAIBuwCHqzScIp76g1/xh4BnEsHtNRnzgpaH21en l5i2PoenBB35hiLJDM941KIcu9ZO4ypLVB1i2uSFBx2FBBz6sT3MLwdXn5MrOrnqjbdA T5r7A3wV/V8w782SDPdHt6PmLJnW3nfXLUSEFUxsAzqPIPwbPcCGDuKZZL15NuGML3ls xhzw== X-Gm-Message-State: ALoCoQkogsG9HPxFRKA/i3dUiNl5lUP4ug2fXfQxJJx/8tKZmueEAWIZ6VtioiG2srvMqswLoJ4K X-Received: by 10.180.99.232 with SMTP id et8mr22922314wib.80.1442450209847; Wed, 16 Sep 2015 17:36:49 -0700 (PDT) Received: from [192.168.0.234] (84-73-90-113.dclient.hispeed.ch. [84.73.90.113]) by smtp.googlemail.com with ESMTPSA id p3sm7039950wib.16.2015.09.16.17.36.48 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Sep 2015 17:36:49 -0700 (PDT) To: xfs@oss.sgi.com From: Viktor Trojanovic Subject: XFS FAQ - out of date? Message-ID: <55FA0B1D.8000905@troja.ch> X-ASG-Orig-Subj: XFS FAQ - out of date? Date: Thu, 17 Sep 2015 02:36:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-wi0-f180.google.com[209.85.212.180] X-Barracuda-Start-Time: 1442450210 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22619 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Hi, I just tried to do a fresh install of Arch Linux using XFS for my root system. According to the xfs.org FAQ, this is supported. But it didn't work. I later found (very few) sources that confirmed that Grub is not compatible with the current XFS level 5, that SuSE created a patch for the problem but it wasn't adopted upstream. If this is true, consider updating the FAQ. If it is not true, I would very much appreciate some hints how to do it properly. Thank you. Best regards, Viktor From robin.listas@gmail.com Wed Sep 16 19:47:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 24C0C7F47 for ; Wed, 16 Sep 2015 19:47:40 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id EC32E30404E for ; Wed, 16 Sep 2015 17:47:36 -0700 (PDT) X-ASG-Debug-ID: 1442450853-04bdf04db618be40001-NocioJ Received: from mail-wi0-f193.google.com (mail-wi0-f193.google.com [209.85.212.193]) by cuda.sgi.com with ESMTP id AxEHc9yrooC9ugtB (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 16 Sep 2015 17:47:34 -0700 (PDT) X-Barracuda-Envelope-From: robin.listas@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.212.193 Received: by wicxq10 with SMTP id xq10so1276071wic.2 for ; Wed, 16 Sep 2015 17:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=MZ+G5b5USJvctuhdDwKKcQ5lhZMA8cXfur5ilKq8W5I=; b=QbUk0DM/wwTCPF+aoZ9z57XDgNdtlrNgOeOyrNc/5avlK1FeyYPQB1yK+6kP05zWTd c0kh+EBU1JN4rXUtA3NKmBtOCUkGRFaNQZCXzVs7NUt5rqyaNLjHflKjORgxbKwbLEG0 dj4mp5l73bt85DgJpt8CerroV8b2i/YyRL/kCJGpY2cWdJMWCWXg2cTFqOJ94tlZEKvv d1pmim7YHFuPsQCanAF1/Z4Wn5aqCuO4Wbtl2l2iFndyT/l1idyV65ATiZkYX3D1osDT bPVMFeqR49I56wKL6xHheAHHTwlmHrjzJmwPGBLXRm8ifZYTmNA/fWB1wJUD8XUX8mYz NA2w== X-Received: by 10.194.63.5 with SMTP id c5mr26584182wjs.127.1442450853240; Wed, 16 Sep 2015 17:47:33 -0700 (PDT) Received: from Telcontar.valinor (3.Red-83-42-78.dynamicIP.rima-tde.net. [83.42.78.3]) by smtp.gmail.com with ESMTPSA id lh11sm7070156wic.18.2015.09.16.17.47.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Sep 2015 17:47:32 -0700 (PDT) Sender: Carlos Robinson Received: from localhost (localhost [127.0.0.1]) by Telcontar.valinor (Postfix) with ESMTP id 62BB960E7E for ; Thu, 17 Sep 2015 02:47:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at valinor Received: from Telcontar.valinor ([127.0.0.1]) by localhost (Telcontar.valinor [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sML0khlo4tL0 for ; Thu, 17 Sep 2015 02:47:30 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by Telcontar.valinor (Postfix) with ESMTP id 9D32B606CF for ; Thu, 17 Sep 2015 02:47:30 +0200 (CEST) Subject: Re: XFS FAQ - out of date? To: XFS mail list X-ASG-Orig-Subj: Re: XFS FAQ - out of date? References: <55FA0B1D.8000905@troja.ch> From: "Carlos E. R." Message-ID: <55FA0DA2.5050609@opensuse.org> Date: Thu, 17 Sep 2015 02:47:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FA0B1D.8000905@troja.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-wi0-f193.google.com[209.85.212.193] X-Barracuda-Start-Time: 1442450854 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22619 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-09-17 02:36, Viktor Trojanovic wrote: > Hi, > > I just tried to do a fresh install of Arch Linux using XFS for my > root system. According to the xfs.org FAQ, this is supported. But > it didn't work. > > I later found (very few) sources that confirmed that Grub is not > compatible with the current XFS level 5, that SuSE created a patch > for the problem but it wasn't adopted upstream. If this is true, > consider updating the FAQ. If it is not true, I would very much > appreciate some hints how to do it properly. I don't know if it is true or not, and I use openSUSE, so I'd have that patch. However, in the past there have been problems with XFS and grub, so my routine is to use a separate /boot partition and install grub there. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlX6DaAACgkQtTMYHG2NR9UlKQCbB4lfGsxqm/Niq6isjNqGn/Bi n4EAn3t5NgIumeMwgrEnDxd18rPSoOGY =Jufm -----END PGP SIGNATURE----- From fanael4@gmail.com Wed Sep 16 23:06:21 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,T_DKIM_INVALID autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 1FE417F47 for ; Wed, 16 Sep 2015 23:06:21 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id AC40CAC002 for ; Wed, 16 Sep 2015 21:06:17 -0700 (PDT) X-ASG-Debug-ID: 1442462774-04cbb005eb19a760001-NocioJ Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by cuda.sgi.com with ESMTP id LwI3GMbiaNvR5Lbj (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 16 Sep 2015 21:06:14 -0700 (PDT) X-Barracuda-Envelope-From: fanael4@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.214.175 Received: by obbzf10 with SMTP id zf10so4641144obb.2 for ; Wed, 16 Sep 2015 21:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZdD3n0La7iYuBVMYz/Ru5YjnS7EHb3k++uLWwQZ8XKc=; b=SlnBULJp9OgwsgVeG/hb0NH0Gz89JsiHWIhu4vS6rYpxn/W0dhE6WeaeWOXgFOx0iI b/MmlOIsZN3D4ibcp5BedT91qMb6Oc1ADuho8+In07MMnAlpG69sEv1QRBUhH3ezOvtX H8cwrEN8r9hkDdkNrOc0gyzpFoeNRXPbTU4mcrrLn8hYDSr8fMWVeg9eWd/t3GLH4YeI O2eXSbGC/JDpNYrTgRIzN4mFTfNtAtAIclHuPZ3OuOJ4IxgTQDLi5NpR3qtwyOGKAjcy X4MH49f2FU+pxZ8IuEEQhbk3OSlgXJWLi0/oWI6mnqPw2g0+BFuMeEND8I4ShuNjtl5C HCHQ== MIME-Version: 1.0 X-Received: by 10.60.178.99 with SMTP id cx3mr28008669oec.50.1442462773850; Wed, 16 Sep 2015 21:06:13 -0700 (PDT) Received: by 10.202.171.196 with HTTP; Wed, 16 Sep 2015 21:06:13 -0700 (PDT) In-Reply-To: <55FA0B1D.8000905@troja.ch> References: <55FA0B1D.8000905@troja.ch> Date: Thu, 17 Sep 2015 06:06:13 +0200 Message-ID: Subject: Re: XFS FAQ - out of date? From: Fanael Linithien X-ASG-Orig-Subj: Re: XFS FAQ - out of date? To: Viktor Trojanovic Cc: xfs@oss.sgi.com Content-Type: text/plain; charset=UTF-8 X-Barracuda-Connect: mail-ob0-f175.google.com[209.85.214.175] X-Barracuda-Start-Time: 1442462774 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22622 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 2015-09-17 2:36 GMT+02:00 Viktor Trojanovic : > I later found (very few) sources that confirmed that Grub is not compatible > with the current XFS level 5, that SuSE created a patch for the problem but > it wasn't adopted upstream. It is merged upstream[1], but last GRUB release was 2.02 beta 2, which is almost two years old. If you have no qualms about using grub-git from AUR, there will be no problems with XFS, even with v5 superblock. [1] http://git.savannah.gnu.org/cgit/grub.git/commit/grub-core/fs/xfs.c?id=b6e80c7778b708c1632d957d00507aad60d9e255 From chingimleong@yahoo.com.sg Thu Sep 17 00:02:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE, T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 84AFD7F47 for ; Thu, 17 Sep 2015 00:02:22 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 66A3B8F8035 for ; Wed, 16 Sep 2015 22:02:19 -0700 (PDT) X-ASG-Debug-ID: 1442466135-04cbb005eb19c4c0001-NocioJ Received: from nm7-vm10.bullet.mail.sg3.yahoo.com (nm7-vm10.bullet.mail.sg3.yahoo.com [106.10.148.185]) by cuda.sgi.com with ESMTP id TxXDY56pXbSyrvi8 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128 verify=NO) for ; Wed, 16 Sep 2015 22:02:17 -0700 (PDT) X-Barracuda-Envelope-From: chingimleong@yahoo.com.sg X-ASG-Whitelist: Sender X-Barracuda-Apparent-Source-IP: 106.10.148.185 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.sg; s=s2048; t=1442466134; bh=A3VbVqcF37/4Q5AwlLRsgJbjTSQPU8xoUvx/qofLXWQ=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=VrVHqXQ35Y4fkVw1RJUEKkqog3O1MGDKSYjuiwJ3HaQdkdBf47r7x3evmotcGBzZ7L0O8uDJjH0ubwPsf0hFUHG8c+DoMdvG6y5zrSPVB0sw+e8BA2fWOxxT2T95IysRocbXuYoj5VPM4Ls9jJsccPS4IAx1QhEyOiKZ/f4Cmxc1XLNOnPDS/sCzzwAzUoaMpwQFX2K4KRRtTVAZt/B7RDX+tDiZHnCcjE73a6BuKDDG3fwmY/jKBjCJ5ThqKmOg3yQNu/eWQPKoioZ1UsqyABs2VxN5ojV9xw0tNFK7Pwo67IxGSGTBzAMSJxu0mC289gyn4IFBn3Qb534/Xrmv7Q== Received: from [106.10.166.113] by nm7.bullet.mail.sg3.yahoo.com with NNFMP; 17 Sep 2015 05:02:14 -0000 Received: from [106.10.151.218] by tm2.bullet.mail.sg3.yahoo.com with NNFMP; 17 Sep 2015 05:02:14 -0000 Received: from [127.0.0.1] by omp1016.mail.sg3.yahoo.com with NNFMP; 17 Sep 2015 05:02:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 930026.24891.bm@omp1016.mail.sg3.yahoo.com X-YMail-OSG: _a0BjLUVM1m9mGRo_kD0O1EBN08LdfGFogJC5LL78vbSGfVYodog9OEy5oEDn.Y qqJrk6aQnpImTZPrD9.E7lUev8hnjbFio.CBv4iGerNrAaFxwn0GK4lVyd6zQS0Fu8v13K3rV67L Qv.8MQvqkIB3E0Eh7qlQOaqDbUOAwE0Vv4J32v1qTsnP9EeDvxF9MyzJeZP1yNQmPnmjurjN2M2m oaFjMdbb6oFA3HaySBTocDC6BKkHmWcIvze06GfNkzWlKDJI6IXfm_nR.mJp_0REQnJ9LLIgJHI7 Nn8nlvBR41t7gj2ioIAe3fyFwno7wnwUbDmVWgj3OdzkSWtzVQudhehxlslnLnmVzkfZ7GOGdRJ5 WFmi1Jz9T9siZKGFySLtiUH9vxhbfevBaoIa3MqKb5NM6zzwMQUGKQuCBPPtK51UDtf2YouN.6lL 62om2UXjcTidrSDzJWEzkMB03aRfJAu0LStFoCsIt6hU.fNj.w5vyZ1ygCb5ac9zl1q9eE1roZzb QpI625246Ob.DStU- Received: by 106.10.197.98; Thu, 17 Sep 2015 05:02:14 +0000 Date: Thu, 17 Sep 2015 05:02:10 +0000 (UTC) From: Gim Leong Chin Reply-To: Gim Leong Chin To: "Carlos E. R." , XFS mail list Message-ID: <206349252.651888.1442466130259.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <55FA0DA2.5050609@opensuse.org> References: <55FA0DA2.5050609@opensuse.org> Subject: Re: XFS FAQ - out of date? MIME-Version: 1.0 X-ASG-Orig-Subj: Re: XFS FAQ - out of date? Content-Type: multipart/alternative; boundary="----=_Part_651887_860286939.1442466130254" X-Barracuda-Connect: nm7-vm10.bullet.mail.sg3.yahoo.com[106.10.148.185] X-Barracuda-Start-Time: 1442466136 X-Barracuda-Encrypted: ECDHE-RSA-RC4-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 ------=_Part_651887_860286939.1442466130254 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have openSUSE 13.2 on two computers, both have XFS V5 with CRC enabled on= the root partition and home partition.=C2=A0 There are no other partitions= other than swap and vFAT for UEFI boot on one of them.=C2=A0 GRUB is in MB= R on one and in vFAT for UEFI boot for the new desktop. Gim Leong From: Carlos E. R. To: XFS mail list =20 Sent: Thursday, 17 September 2015, 8:47 Subject: Re: XFS FAQ - out of date? =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-09-17 02:36, Viktor Trojanovic wrote: > Hi, >=20 > I just tried to do a fresh install of Arch Linux using XFS for my > root system. According to the xfs.org FAQ, this is supported. But > it didn't work. >=20 > I later found (very few) sources that confirmed that Grub is not=20 > compatible with the current XFS level 5, that SuSE created a patch > for the problem but it wasn't adopted upstream. If this is true, > consider updating the FAQ. If it is not true, I would very much > appreciate some hints how to do it properly. I don't know if it is true or not, and I use openSUSE, so I'd have that patch. However, in the past there have been problems with XFS and grub, so my routine is to use a separate /boot partition and install grub there. - --=20 Cheers / Saludos, =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Carlos E. R. =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 (from 13.1 x86_64 "Bottle" at Telcont= ar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlX6DaAACgkQtTMYHG2NR9UlKQCbB4lfGsxqm/Niq6isjNqGn/Bi n4EAn3t5NgIumeMwgrEnDxd18rPSoOGY =3DJufm -----END PGP SIGNATURE----- _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ------=_Part_651887_860286939.1442466130254 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have openSUSE 13.2 on two computers, both have X= FS V5 with CRC enabled on the root partition and home partition.  Ther= e are no other partitions other than swap and vFAT for UEFI boot on one of = them.  GRUB is in MBR on one and in vFAT for UEFI boot for the new des= ktop.

<= div id=3D"yui_3_16_0_1_1442460038059_14711" dir=3D"ltr">Gim Leong
=

From: Carlos E. R. = <carlos.e.r@opensuse.org>
T= o: XFS mail list <xfs@oss.sgi.com>
Sent: Thursday, 17 September 2015, 8:47
= Subject: Re: XFS FAQ - out= of date?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-09-17 02:36,= Viktor Trojanovic wrote:
> Hi,
>=
> I just tried to do a fresh install of Arch Linux u= sing XFS for my
> root system. According to the xfs.or= g FAQ, this is supported. But
> it didn't work.
>
> I later found (very few) sources t= hat confirmed that Grub is not
> compatible with the = current XFS level 5, that SuSE created a patch
> for t= he problem but it wasn't adopted upstream. If this is true,
> consider updating the FAQ. If it is not true, I would very much
> appreciate some hints how to do it properly.

I don't know if it is true or not, and I use o= penSUSE, so I'd have
that patch. However, in the past the= re have been problems with XFS and
grub, so my routine is= to use a separate /boot partition and install
grub there= .

- --
Cheers / Sal= udos,

      &= nbsp; Carlos E. R.
        = (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP S= IGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlX6DaAACgkQtTMYHG2NR9UlKQCbB4lfGs= xqm/Niq6isjNqGn/Bi
n4EAn3t5NgIumeMwgrEnDxd18rPSoOGY
=3DJufm
-----END PGP SIGNATURE-----




_______________________________= ________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mai= lman/listinfo/xfs


=
------=_Part_651887_860286939.1442466130254-- From eflorac@intellique.com Thu Sep 17 01:17:53 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 2BB157F47 for ; Thu, 17 Sep 2015 01:17:53 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 255768F8035 for ; Wed, 16 Sep 2015 23:17:50 -0700 (PDT) X-ASG-Debug-ID: 1442470666-04cbb005ea19f510001-NocioJ Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by cuda.sgi.com with ESMTP id q8gCMWjXtvDIe9lA (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 16 Sep 2015 23:17:47 -0700 (PDT) X-Barracuda-Envelope-From: eflorac@intellique.com X-Barracuda-Apparent-Source-IP: 212.27.42.5 Received: from galadriel.home (unknown [82.235.234.79]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0974FD4807D; Thu, 17 Sep 2015 08:17:46 +0200 (CEST) Date: Thu, 17 Sep 2015 08:17:57 +0200 From: Emmanuel Florac To: Ferenc Kovacs , xfs@oss.sgi.com Subject: Re: easily reproducible filesystem crash on rebuilding array Message-ID: <20150917081757.48aaf891@galadriel.home> X-ASG-Orig-Subj: Re: easily reproducible filesystem crash on rebuilding array In-Reply-To: References: Organization: Intellique X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.20; i486-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp5-g21.free.fr[212.27.42.5] X-Barracuda-Start-Time: 1442470667 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22624 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Le Wed, 16 Sep 2015 15:50:13 +0200 vous =C3=A9criviez: > Hi, >=20 > have you found a resolution to your problem? > we are facing a similar issue(fs corruption every time when > rebuilding the array) with an Adaptec Series 8 Raid controller. The problem didn't occur anymore after I deactivated individual disks write caching in the "controller settings". This is only adjustable through the RAID BIOS though, not through arcconf apparently. This seems to apply to all of 5xx5, 6xx5, 7xx5 series. I never rebuilt an array with a 8xx5 yet (though I have some). I don't know why this is not the default settings (default keeps the disks write cache active instead). Adaptec support and engineering deny that the problem exists, though I've sent many logs and defined a test procedure that allow to reproduce the problem reliably enough. Thanks god for XFS. ext4 is completely unaware of the corruptions, but they're present nonetheless (md5summing files before, during and after rebuild)... BTW I'm curious, where did you find this address? This isn't the one I'm using on the XFS mailing list... cheers --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From tyra3l@gmail.com Thu Sep 17 02:21:15 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE, T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 92E257F47 for ; Thu, 17 Sep 2015 02:21:15 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 908E1304051 for ; Thu, 17 Sep 2015 00:21:12 -0700 (PDT) X-ASG-Debug-ID: 1442474468-04cb6c355a17bc40001-NocioJ Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by cuda.sgi.com with ESMTP id PNY3aJUb6edZZmOe (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 17 Sep 2015 00:21:09 -0700 (PDT) X-Barracuda-Envelope-From: tyra3l@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.212.178 Received: by wicgb1 with SMTP id gb1so104688855wic.1 for ; Thu, 17 Sep 2015 00:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uaZhqEZBflBgwGTNzUIEDeL/al7JhahRepYPje/2TEE=; b=zV9CfXKPT4EhV0GpwmQyBJgaGtO+3tUPAnhx/1qqhfAgms+JiKt+LFsDZDSwe3vjjF HCKWYL7O1gRgUci7DdNm/fS7gCGeJGHV7y9Pgxu96HqhqKKjAIE6vgQGCw4/TOwFQ4tB m5SJDzQ0Yw2sMSpfegSvy/PzOaSqNpPjZFbs4zUe7xPRPb2LJ5q2rr1e9fgIQcRr7Dyj 81qx+4R8Q8wppmnCIXwP1+wd1u0uypg/qCtXXGtdymCr+2vfkaPfh2ShE6ewvRo8LPFE 9s0qNo0W5WUvqCNjHvwTZRQYdvcOcI8zHxD9V4t05psguj0piuEl7jkQCr46TyCMA9Ra 163Q== MIME-Version: 1.0 X-Received: by 10.194.117.5 with SMTP id ka5mr57900353wjb.50.1442474468529; Thu, 17 Sep 2015 00:21:08 -0700 (PDT) Received: by 10.28.180.85 with HTTP; Thu, 17 Sep 2015 00:21:07 -0700 (PDT) Received: by 10.28.180.85 with HTTP; Thu, 17 Sep 2015 00:21:07 -0700 (PDT) In-Reply-To: <20150917081757.48aaf891@galadriel.home> References: <20150917081757.48aaf891@galadriel.home> Date: Thu, 17 Sep 2015 09:21:07 +0200 Message-ID: Subject: Re: easily reproducible filesystem crash on rebuilding array From: Ferenc Kovacs X-ASG-Orig-Subj: Re: easily reproducible filesystem crash on rebuilding array To: Emmanuel Florac Cc: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=001a1130cbae4b5f1a051fec42ad X-Barracuda-Connect: mail-wi0-f178.google.com[209.85.212.178] X-Barracuda-Start-Time: 1442474469 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22626 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 --001a1130cbae4b5f1a051fec42ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2015. szept. 17. 8:17 ezt =C3=ADrta ("Emmanuel Florac" ): > > Le Wed, 16 Sep 2015 15:50:13 +0200 vous =C3=A9criviez: > > > Hi, > > > > have you found a resolution to your problem? > > we are facing a similar issue(fs corruption every time when > > rebuilding the array) with an Adaptec Series 8 Raid controller. > > The problem didn't occur anymore after I deactivated > individual disks write caching in the "controller settings". This is > only adjustable through the RAID BIOS though, not through arcconf > apparently. > This seems to apply to all of 5xx5, 6xx5, 7xx5 series. I never rebuilt > an array with a 8xx5 yet (though I have some). I don't know why this is > not the default settings (default keeps the disks write cache active > instead). Adaptec support and engineering deny that the problem exists, > though I've sent many logs and defined a test procedure that allow to > reproduce the problem reliably enough. > Thanks god for XFS. ext4 is completely unaware of the corruptions, but > they're present nonetheless (md5summing files before, during and > after rebuild)... > Thanks for the info! > BTW I'm curious, where did you find this address? This isn't the one > I'm using on the XFS mailing list... I was using the gmane archives to read your thread and the there the domain part is truncated for privacy(even from your signature) so I googled your mail handle with your full name and this address was the first result. --001a1130cbae4b5f1a051fec42ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015. szept. 17. 8:17 ezt =C3=ADrta ("Emmanuel Florac" <eflorac@intellique.com>):
>
> Le Wed, 16 Sep 2015 15:50:13 +0200 vous =C3=A9criviez:
>
> > Hi,
> >
> > have you found a resolution to your problem?
> > we are facing a similar issue(fs corruption every time when
> > rebuilding the array) with an Adaptec Series 8 Raid controller. >
> The problem didn't occur anymore after I deactivated
> individual disks write caching in the "controller settings".= This is
> only adjustable through the RAID BIOS though, not through arcconf
> apparently.
> This seems to apply to all of 5xx5, 6xx5, 7xx5 series. I never rebuilt=
> an array with a 8xx5 yet (though I have some). I don't know why th= is is
> not the default settings (default keeps the disks write cache active > instead). Adaptec support and engineering deny that the problem exists= ,
> though I've sent many logs and defined a test procedure that allow= to
> reproduce the problem reliably enough.
> Thanks god for XFS. ext4 is completely unaware of the corruptions, but=
> they're present nonetheless (md5summing files before, during and > after rebuild)...
>

Thanks for the info!

> BTW I'm curious, where did you find this address? T= his isn't the one
> I'm using on the XFS mailing list...

I was using the gmane archives to read your thread and the t= here the domain part is truncated for privacy(even from your signature) so = I googled your mail handle with your full name and this address was the fir= st result.

--001a1130cbae4b5f1a051fec42ad-- From 3xHT6VQgJA00xsxIIFFKv1px0.r31Cu7377.7vx.r31@trix.bounces.google.com Thu Sep 17 03:07:37 2015 Return-Path: <3xHT6VQgJA00xsxIIFFKv1px0.r31Cu7377.7vx.r31@trix.bounces.google.com> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE, T_DKIM_INVALID,T_REMOTE_IMAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 4C2F27F47 for ; Thu, 17 Sep 2015 03:07:37 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 31C908F8035 for ; Thu, 17 Sep 2015 01:07:34 -0700 (PDT) X-ASG-Debug-ID: 1442477252-04cb6c355a17d3a0001-NocioJ Received: from mail-qk0-f198.google.com (mail-qk0-f198.google.com [209.85.220.198]) by cuda.sgi.com with ESMTP id 6qZgFsnJeeYRvEO0 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 17 Sep 2015 01:07:32 -0700 (PDT) X-Barracuda-Envelope-From: 3xHT6VQgJA00xsxIIFFKv1px0.r31Cu7377.7vx.r31@trix.bounces.google.com X-Barracuda-Apparent-Source-IP: 209.85.220.198 X-ASG-Whitelist: EmailCat (listserver) Received: by qkey1 with SMTP id y1so15910069qke.0 for ; Thu, 17 Sep 2015 01:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:message-id:date:subject:from:to:content-type; bh=zSHNzVgFaX245wxmMQWjVkFIwECKNFNPEQWQVpGigfQ=; b=olgNCE8VT7TIiilCbRUA6AzWw2FwqjX83H3VDOXuze/pNzHSJGTM5+kKUi/U1vg/q7 sXMT+RfcdwspXLJncjazal5EMnBnNkaO+rQGV0NbRbITHGAICcco0HA9Om1Fi9y+XnZ/ oTHP/ThftrKHJSZ64Lk3DgDGidvsemRdr2kyayI0sFYV2cDvIOaYyOx0eYVhNHI0jjTA O+o+8WYF7m5h2MBbjL//esmz707m0K+P/ag7IBMB/VRoie0fB+pivCSBzG47EP5Le8ww 0g17sSBsJzFGlP26SZpilAD5DprkVkMvUHtt22/wG/2rVvxOgyGm8x0IR0pfH2P+nDF+ +QYQ== MIME-Version: 1.0 X-Received: by 10.31.44.18 with SMTP id s18mt4377235vks.6.1442477252188; Thu, 17 Sep 2015 01:07:32 -0700 (PDT) Reply-To: idi33005@gmail.com X-No-Auto-Attachment: 1 Message-ID: <001a1142d88036a8ed051fece857@google.com> Date: Thu, 17 Sep 2015 08:07:32 +0000 Subject: =?GB2312?B?16jDxbf+zvHN4sOzxvPStSC5psTcyKvD5rXEzeLDs8jtvP4=?= From: idi33005@gmail.com X-ASG-Orig-Subj: =?GB2312?B?16jDxbf+zvHN4sOzxvPStSC5psTcyKvD5rXEzeLDs8jtvP4=?= To: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=001a1142d8803a20c4051fece84d X-Barracuda-Connect: mail-qk0-f198.google.com[209.85.220.198] X-Barracuda-Start-Time: 1442477252 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 --001a1142d8803a20c4051fece84d Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-Transfer-Encoding: base64 xPq7udTasbu2r7XEtci/zbuno7/Kx8qxuvLW97avs/a798HLoaOxu7avxPrWu8TcyMO/zbun0aHU 8aOstvjW97avxPq/ydLUDQrRodTxv827p6GjDQoNCtb3tq/Kvc3iw7O/zbunv6q3oqO6DQoNCjGj rMO/zOzL0cv3s/bJz83yuPa/zcjL08rP5KOsz7XNs9K7zOy1xLmk1/fBv7XW0ru49tK1zvHUsdK7 uPbUwrXEy9HL9w0Kwb+juw0KDQoyo6zDv8zsyc/N8rfiv6q3otDFzca547W9xPq1xMex1NrC8rzS 08rP5MDvw+ajrMjDxPrDv8zs1Pa80zO49tGvxcyjuw0KDQozo6zU9rzTzcW208T9vtvBpqOsyMPD v7j20rXO8dSxw7/M7La809DKwr/J1/ajrLb4vPXJ2cjLssXB98qno7sNCg0KNKOsvPXJ2dTaQjJC xr3MqLXItP21xMqxvOSjrNT2vNPAz9SxuaS7/byr0NSjrMjD0MLK1r/sy9nI68PFoaMNCg0Kv8nS 1LOiytTPws7Sw8fI7bz+o7oNCryvo7rIureioaLN4sOzoaLL0cv3oaO/7MvZu/3A27/Nu6fIuqOs 1vrE47/sy9mzybWloaOj+8urz7LI7bz+o/0NCg0Kx+vWsb3TvNNRUcGqz7UocXEyMDc1OTE0MzQz KQ0KDQq78taxvdO801FRwarPtaOsuPjE+tTaz9+y2df30d3KvsjtvP61xL/Nu6fL0cv3vqvXvLbI vLDQp7n7DQoNCtejo7rJ+tLi0MvCoaOhDQrTotPv0KHQpruwo6zN+8T6v6rQxNK70KYNCkEgbmV3 c3BhcGVyIG9yZ2FuaXplZCBhIGNvbnRlc3QgZm9yIHRoZSBiZXN0IGFuc3dlciB0byB0aGUNCnF1 ZXN0aW9uOiAiSWYgYSBmaXJlIGJyb2tlIG91dCBpbiB0aGUgTG91dnJlLA0KYW5kIGlmIHlvdSBj b3VsZCBvbmx5IHNhdmUgb25lIHBhaW50aW5nLCB3aGljaCBvbmUgd291bGQgeW91IGNhcnJ5IG91 dD8iDQpUaGUgd2lubmluZyByZXBseSB3YXM6ICJUaGUgb25lIG5lYXJlc3QgdGhlIGV4aXQuIg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQrO0tLR0fvH 68T6zO7QtLHttaUg16PG5MnM7PejoaGjINKqzO7QtLTLse21paOsx+u3w87Ko7oNCmh0dHBzOi8v ZG9jcy5nb29nbGUuY29tL2Zvcm1zL2QvMVJmcGtBc2lOX2R2QnFsUzhJM3FkMVhLQS1kUnRpTm5U LTJIX1lLSVRhSkUvdmlld2Zvcm0/Yz0wJnc9MSZ1c3A9bWFpbF9mb3JtX2xpbmsNCg== --001a1142d8803a20c4051fece84d Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

=C4=FA=BB=B9=D4=DA=B1=BB=B6=AF=B5= =C4=B5=C8=BF=CD=BB=A7=A3=BF=CA=C7=CA=B1=BA=F2=D6=F7=B6=AF=B3=F6=BB=F7=C1=CB= =A1=A3=B1=BB=B6=AF=C4=FA=D6=BB=C4=DC=C8=C3=BF=CD=BB=A7=D1=A1=D4=F1=A3=AC=B6= =F8=D6=F7=B6=AF=C4=FA=BF=C9=D2=D4=D1=A1=D4=F1=BF=CD=BB=A7=A1=A3

=D6=F7= =B6=AF=CA=BD=CD=E2=C3=B3=BF=CD=BB=A7=BF=AA=B7=A2=A3=BA

1=A3=AC=C3=BF= =CC=EC=CB=D1=CB=F7=B3=F6=C9=CF=CD=F2=B8=F6=BF=CD=C8=CB=D3=CA=CF=E4=A3=AC=CF= =B5=CD=B3=D2=BB=CC=EC=B5=C4=B9=A4=D7=F7=C1=BF=B5=D6=D2=BB=B8=F6=D2=B5=CE=F1= =D4=B1=D2=BB=B8=F6=D4=C2=B5=C4=CB=D1=CB=F7=C1=BF=A3=BB

2=A3=AC=C3=BF= =CC=EC=C9=CF=CD=F2=B7=E2=BF=AA=B7=A2=D0=C5=CD=C6=B9=E3=B5=BD=C4=FA=B5=C4=C7= =B1=D4=DA=C2=F2=BC=D2=D3=CA=CF=E4=C0=EF=C3=E6=A3=AC=C8=C3=C4=FA=C3=BF=CC=EC= =D4=F6=BC=D33=B8=F6=D1=AF=C5=CC=A3=BB

3=A3=AC=D4=F6=BC=D3=CD=C5=B6=D3= =C4=FD=BE=DB=C1=A6=A3=AC=C8=C3=C3=BF=B8=F6=D2=B5=CE=F1=D4=B1=C3=BF=CC=EC=B6= =BC=D3=D0=CA=C2=BF=C9=D7=F6=A3=AC=B6=F8=BC=F5=C9=D9=C8=CB=B2=C5=C1=F7=CA=A7= =A3=BB

4=A3=AC=BC=F5=C9=D9=D4=DAB2B=C6=BD=CC=A8=B5=C8=B4=FD=B5=C4=CA= =B1=BC=E4=A3=AC=D4=F6=BC=D3=C0=CF=D4=B1=B9=A4=BB=FD=BC=AB=D0=D4=A3=AC=C8=C3= =D0=C2=CA=D6=BF=EC=CB=D9=C8=EB=C3=C5=A1=A3

=BF=C9=D2=D4=B3=A2=CA=D4= =CF=C2=CE=D2=C3=C7=C8=ED=BC=FE=A3=BA

=BC=AF=A3=BA=C8=BA=B7=A2=A1=A2=CD= =E2=C3=B3=A1=A2=CB=D1=CB=F7=A1=A3=BF=EC=CB=D9=BB=FD=C0=DB=BF=CD=BB=A7=C8=BA= =A3=AC=D6=FA=C4=E3=BF=EC=CB=D9=B3=C9=B5=A5=A1=A3=A3=FB=CB=AB=CF=B2=C8=ED=BC= =FE=A3=FD

=C7=EB=D6=B1=BD=D3=BC=D3QQ=C1=AA=CF=B5(qq2075914343)

= =BB=F2=D6=B1=BD=D3=BC=D3QQ=C1=AA=CF=B5=A3=AC=B8=F8=C4=FA=D4=DA=CF=DF=B2=D9= =D7=F7=D1=DD=CA=BE=C8=ED=BC=FE=B5=C4=BF=CD=BB=A7=CB=D1=CB=F7=BE=AB=D7=BC=B6= =C8=BC=B0=D0=A7=B9=FB

=D7=A3= =A3=BA=C9=FA=D2=E2=D0=CB=C2=A1=A3=A1

=D3=A2=D3=EF=D0=A1=D0=A6=BB=B0=A3=AC= =CD=FB=C4=FA=BF=AA=D0=C4=D2=BB=D0=A6

A newspaper organized a contest for = the best answer to the question: "If a fire broke out in the Louvre, <= p>and if you could only save one painting, which one would you carry out?&q= uot;

The winning reply was: "The one nearest the exit."

=

=C8=E7=B9=FB=C4=FA=CE=DE=B7=A8=B2=E9=BF=B4=BB=F2=CC=E1=BD=BB=B4=CB=B1=ED=B5= =A5=A3=AC=BF=C9=D2=D4=D4=DA Google =B1=ED=B5=A5=D6=D0=CC=EE=D0=B4=A1=A3


<= /html> --001a1142d8803a20c4051fece84d-- From eflorac@intellique.com Thu Sep 17 06:17:47 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E62E57F4E for ; Thu, 17 Sep 2015 06:17:46 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 84F31AC001 for ; Thu, 17 Sep 2015 04:17:43 -0700 (PDT) X-ASG-Debug-ID: 1442488660-04cb6c355d1842c0001-NocioJ Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by cuda.sgi.com with ESMTP id XVRMEJgGa5AIIaxf (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Sep 2015 04:17:41 -0700 (PDT) X-Barracuda-Envelope-From: eflorac@intellique.com X-Barracuda-Apparent-Source-IP: 66.39.3.162 Received: from localhost (localhost [127.0.0.1]) by mail1.g1.pair.com (Postfix) with SMTP id 597612CD6E; Thu, 17 Sep 2015 07:17:40 -0400 (EDT) Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail1.g1.pair.com (Postfix) with ESMTPSA id 9658C2CC62; Thu, 17 Sep 2015 07:17:39 -0400 (EDT) Date: Thu, 17 Sep 2015 13:17:42 +0200 From: Emmanuel Florac To: Ferenc Kovacs Cc: xfs@oss.sgi.com Subject: Re: easily reproducible filesystem crash on rebuilding array Message-ID: <20150917131742.335e2021@harpe.intellique.com> X-ASG-Orig-Subj: Re: easily reproducible filesystem crash on rebuilding array In-Reply-To: References: <20150917081757.48aaf891@galadriel.home> Organization: Intellique X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.20; i486-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: mail1.g1.pair.com[66.39.3.162] X-Barracuda-Start-Time: 1442488661 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.20 X-Barracuda-Spam-Status: No, SCORE=0.20 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC7_SA298e X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22630 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC7_SA298e Custom Rule SA298e Le Thu, 17 Sep 2015 09:21:07 +0200 Ferenc Kovacs =C3=A9crivait: > > Thanks god for XFS. ext4 is completely unaware of the corruptions, > > but they're present nonetheless (md5summing files before, during and > > after rebuild)... > > =20 >=20 > Thanks for the info! >=20 Be careful anyway, in one occurrence I was able to get a slight corruption even in this case. For some reason (cache flushing?) it's the very end of the rebuild process (the last 15 minutes or so) which is sensitive to corruption under heavy IOs. --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From viktor@troja.ch Thu Sep 17 06:32:03 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 62EC87F4E for ; Thu, 17 Sep 2015 06:32:03 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 4E73B8F8049 for ; Thu, 17 Sep 2015 04:32:00 -0700 (PDT) X-ASG-Debug-ID: 1442489514-04cb6c355a1847c0001-NocioJ Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by cuda.sgi.com with ESMTP id mxsDdCoEDF3OBHRz (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 17 Sep 2015 04:31:54 -0700 (PDT) X-Barracuda-Envelope-From: viktor@troja.ch X-Barracuda-Apparent-Source-IP: 209.85.212.178 Received: by wicfx3 with SMTP id fx3so19532140wic.1 for ; Thu, 17 Sep 2015 04:31:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=iEGJVBCExs2hlR8/0ARI0AlYvffVUhHPLal3UYSVKyQ=; b=Om5BM28LfzlvuNn5a3l+d3NWUPBWq806Obx1c/tqrr5vPjTMs0UE+FW+6vHlUzfkDZ NGMaXWIBfyDMCd6Iy69fMDDXNsw0WOG6P89NTeHBrIDsXJ9hFQKZMVGJIm7euUOq7+dW AWn3AiGoo/xi5ncAdsy8dZVokowSXe9vyyVp5fFnNOd3B2OghkgYbKpzo4Q/165VZf6y ycOqJJdI7/kKRtMwEPMUj6rQMDi3U180EofUhbA/p/7IP8E6+zBYbzYARLwDSwvY8k3x W8tMCkXKyydB5WXKCT6yiaZPN4t4rKvRi2vhnEovi31iSp3WFxX0mcG1MBmFcUeL/VfG dWnQ== X-Gm-Message-State: ALoCoQmCqXnGgqLHw7dmg8sYbnSEbBEK0JH21XeKB7qnlvxaSbpfbSvoNPuSv9orrdOv+evRtiYW X-Received: by 10.194.91.193 with SMTP id cg1mr68166643wjb.88.1442489513903; Thu, 17 Sep 2015 04:31:53 -0700 (PDT) Received: from [192.168.0.89] (84-73-90-113.dclient.hispeed.ch. [84.73.90.113]) by smtp.googlemail.com with ESMTPSA id ub7sm9565806wib.17.2015.09.17.04.31.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Sep 2015 04:31:53 -0700 (PDT) Subject: Re: XFS FAQ - out of date? To: Fanael Linithien X-ASG-Orig-Subj: Re: XFS FAQ - out of date? References: <55FA0B1D.8000905@troja.ch> Cc: xfs@oss.sgi.com From: Viktor Trojanovic Message-ID: <55FAA4A5.7000701@troja.ch> Date: Thu, 17 Sep 2015 13:31:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-wi0-f178.google.com[209.85.212.178] X-Barracuda-Start-Time: 1442489514 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22630 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 17.09.2015 06:06, Fanael Linithien wrote: > 2015-09-17 2:36 GMT+02:00 Viktor Trojanovic : >> I later found (very few) sources that confirmed that Grub is not compatible >> with the current XFS level 5, that SuSE created a patch for the problem but >> it wasn't adopted upstream. > It is merged upstream[1], but last GRUB release was 2.02 beta 2, which > is almost two years old. If you have no qualms about using grub-git > from AUR, there will be no problems with XFS, even with v5 superblock. > > [1] http://git.savannah.gnu.org/cgit/grub.git/commit/grub-core/fs/xfs.c?id=b6e80c7778b708c1632d957d00507aad60d9e255 Great, I'll try that. Thanks for replying. From bfoster@redhat.com Thu Sep 17 07:16:14 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 07CC87F4E for ; Thu, 17 Sep 2015 07:16:14 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 76BF0AC001 for ; Thu, 17 Sep 2015 05:16:10 -0700 (PDT) X-ASG-Debug-ID: 1442492168-04cb6c355c185af0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id xWD9nWpbZ4ABHYvz (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Sep 2015 05:16:09 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 4E0C4461EA; Thu, 17 Sep 2015 12:16:08 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-92.bos.redhat.com [10.18.41.92]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8HCG7nB003960; Thu, 17 Sep 2015 08:16:08 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id E06D11201EB; Thu, 17 Sep 2015 08:16:06 -0400 (EDT) Date: Thu, 17 Sep 2015 08:16:06 -0400 From: Brian Foster To: Dave Chinner Cc: David Jeffery , xfs@oss.sgi.com Subject: Re: [PATCH] xfs: add missing ilock around dio write last extent alignment Message-ID: <20150917121606.GA19577@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH] xfs: add missing ilock around dio write last extent alignment References: <1441809812-60175-1-git-send-email-bfoster@redhat.com> <20150913235835.GV26895@dastard> <20150914132455.GA22770@bfoster.bfoster> <20150916223435.GW26895@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150916223435.GW26895@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442492168 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 17, 2015 at 08:34:35AM +1000, Dave Chinner wrote: > On Mon, Sep 14, 2015 at 09:24:55AM -0400, Brian Foster wrote: > > On Mon, Sep 14, 2015 at 09:58:35AM +1000, Dave Chinner wrote: > > > On Wed, Sep 09, 2015 at 10:43:32AM -0400, Brian Foster wrote: ... > > > > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c > > > > index 1f86033..4d7534e 100644 > > > > --- a/fs/xfs/xfs_iomap.c > > > > +++ b/fs/xfs/xfs_iomap.c > > > > @@ -142,7 +142,9 @@ xfs_iomap_write_direct( > > > > offset_fsb = XFS_B_TO_FSBT(mp, offset); > > > > last_fsb = XFS_B_TO_FSB(mp, ((xfs_ufsize_t)(offset + count))); > > > > if ((offset + count) > XFS_ISIZE(ip)) { > > > > + xfs_ilock(ip, XFS_ILOCK_EXCL); > > > > error = xfs_iomap_eof_align_last_fsb(mp, ip, extsz, &last_fsb); > > > > + xfs_iunlock(ip, XFS_ILOCK_EXCL); > > > > > > XFS_ILOCK_SHARED? > > > > > > > I suspect that is technically sufficient in this particular call path > > given that we've called xfs_bmapi_read(). The problem is that there is a > > call to xfs_iread_extents() buried a few calls deep in > > xfs_bmap_last_extent(). > > Sure. > > > My understanding is that we need the exclusive > > lock because it's not safe for multiple threads to populate the in-core > > extent list at the same time, so I don't really want to replace the > > existing race with a landmine should the context happen to change in the > > future. > > yes, but that can't happen here because we are guaranteed to have > the extent list in memory because we've alreay called > xfs_bmapi_read() and that will populate the extent list with the > appropriate lock held. > > > > Also, looking at __xfs_get_blocks(), we drop the ilock immediately > > > before calling xfs_iomap_write_direct(), which we already hold in > > > shared mode for the xfs_bmapi_read() for direct IO. > > > > > > Can we push that lock dropping into xfs_iomap_write_direct() after > > > we've done the xfs_iomap_eof_align_last_fsb() call and before we do > > > transaction reservations so we don't need an extra lock round-trip > > > here? e.g. xfs_iomap_write_delay() is called under the lock context > > > held by __xfs_get_blocks().... > > > > > > > That was my initial thought when looking at this code... e.g., to just > > carry the lock over and drop it prior to transaction setup. I didn't go > > that route because __xfs_get_blocks() uses a variable locking mode and > > it seemed ugly to pass along the lock mode to xfs_iomap_direct_write(). > > Further, given the above it also looked like we'd have to check and > > cycle the ilock EXCL if it were ILOCK_SHARED. Finally, > > No, because the __xfs_get_blocks code calls > xfs_ilock_data_map_shared() for direct IO, so already holds the > correct lock for populating the extent list (not that this matters > here). > > > xfs_iomap_direct_write() has a call to xfs_qm_dqattach() which itself > > acquires ILOCK_EXCL. Looking at xfs_iomap_write_delay(), we do have a > > dqattach_locked() variant but it also expects to have ILOCK_EXCL. > > That can be moved to after we've calculated the last extent. i.e. > to just before we start the transaction.... > > > The only thing I'm not sure about is the shared lock safe version of > > xfs_iomap_eof_align_last_fsb(). > > All the callers are guaranteed to have first populated the extent > list, so this should be safe. If you are really worried, add an > assert that verifies either ILOCK_EXCL or (ILOCK_SHARED && extents > read in) > > > xfs_iread_extents() if it were called). Also, I take it we can safely > > assume the in-core extent list is still around if we still hold the lock > > from the xfs_bmapi_read() call. Thoughts? I guess I'll float another > > patch... > > Once the extents are read in, they are in memory until the inode is > reclaimed. That won't happen while we have active references to it. > :) > Yeah, there's a v2 on the list that pretty much matches what is suggested here. My main concern with the xfs_iread_extents() thing was the landmine nature of it (after all, it was obfuscated enough that it wasn't obvious locking was even necessary). I've addressed that with a comment and asserts at the callsite. The only difference is I made it such that xfs_iomap_write_direct() expects ILOCK_SHARED rather than take a variable lockflag parameter, but we could do that either way. Thanks for the comments. Brian > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From cmaiolino@redhat.com Thu Sep 17 09:24:14 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 00B767F4E for ; Thu, 17 Sep 2015 09:24:13 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id A08DDAC007 for ; Thu, 17 Sep 2015 07:24:13 -0700 (PDT) X-ASG-Debug-ID: 1442499852-04bdf04db31a95f0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id dNoUfrSD5xi7V6Qi (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Sep 2015 07:24:12 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 758E28EA2E for ; Thu, 17 Sep 2015 14:24:12 +0000 (UTC) Received: from zion.usersys.redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8HEOBvG030660 for ; Thu, 17 Sep 2015 10:24:12 -0400 From: Carlos Maiolino To: xfs@oss.sgi.com Subject: [RFC PATCH] xfs_io: Implement inodes64 command Date: Thu, 17 Sep 2015 16:24:06 +0200 X-ASG-Orig-Subj: [RFC PATCH] xfs_io: Implement inodes64 command Message-Id: <1442499846-10470-1-git-send-email-cmaiolino@redhat.com> 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: 1442499852 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 This command aims to implement an easy way to check a filesystem for the existence of 64bit inodes. Based on XFS_IOC_FSINUMBERS, and starting with a lastip = 0xffffffff instead of 0. For now, it just returns a string saying there is or there is no 64bit inodes in the filesystem, but, I was wondering if it might not be better to just return 0 or 1, so it can be used inside scripts to check for that. Or maybe an argument to chose between an integer output or a string verbose output. Also, I was wondering if might be useful to, besides return the existence of 64bit inodes, also inform if there is any 64bit inodes allocated in the groups or not. Although, this will need the tool to walk through all the inode groups checking for allocated inodes or not, instead of just stop at the first 64bit inode found. Also, I'm still not sure if 'inodes64' is a good name for the command, I was also thinking about something like 'chk64inos' but 'inodes64' was the best and easy to be remembered I could find. Comments are appreciated :-) Signed-off-by: Carlos Maiolino --- io/open.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/io/open.c b/io/open.c index ac5a5e0..3a98fdf 100644 --- a/io/open.c +++ b/io/open.c @@ -44,6 +44,7 @@ static cmdinfo_t statfs_cmd; static cmdinfo_t chproj_cmd; static cmdinfo_t lsproj_cmd; static cmdinfo_t extsize_cmd; +static cmdinfo_t inodes64_cmd; static prid_t prid; static long extsize; @@ -750,6 +751,37 @@ statfs_f( return 0; } +static int +inodes64_f( + int argc, + char **argv) +{ + int i; + __s32 count; + __u64 last = 0xffffffff; + xfs_inogrp_t igroup[64]; + xfs_fsop_bulkreq_t bulkreq; + + /* Setup bulkreq structure */ + bulkreq.lastip = &last; + bulkreq.icount = 64; + bulkreq.ubuffer = &igroup; + bulkreq.ocount = &count; + + while (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq) == 0) { + if (count > 0) { + printf("Filesystem does have 64bit inodes\n"); + return 0; + } else { + printf("Filesystem does not have 64bit inodes\n"); + return 0; + } + } + perror("xfsctl(XFS_IOC_FSINUMBERS)"); + exitcode = 1; + return 0; +} + void open_init(void) { @@ -815,6 +847,12 @@ open_init(void) _("get/set preferred extent size (in bytes) for the open file"); extsize_cmd.help = extsize_help; + inodes64_cmd.name = "inodes64"; + inodes64_cmd.cfunc = inodes64_f; + inodes64_cmd.flags = CMD_NOMAP_OK; + inodes64_cmd.oneline = + _("Checks if filesyste contais 64bit inodes"); + add_command(&open_cmd); add_command(&stat_cmd); add_command(&close_cmd); @@ -822,4 +860,5 @@ open_init(void) add_command(&chproj_cmd); add_command(&lsproj_cmd); add_command(&extsize_cmd); + add_command(&inodes64_cmd); } -- 2.4.3 From prvs=7702a5136c=joshua.earl@drexelmed.edu Thu Sep 17 11:45:18 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id DC11D7F4E for ; Thu, 17 Sep 2015 11:45:17 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 79511AC001 for ; Thu, 17 Sep 2015 09:45:17 -0700 (PDT) X-ASG-Debug-ID: 1442508310-04bdf04db51ae020001-NocioJ Received: from pp-mta1.drexelmed.edu ([198.17.30.172]) by cuda.sgi.com with ESMTP id sL4vg8PuN9Y8QJqp (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Sep 2015 09:45:11 -0700 (PDT) X-Barracuda-Envelope-From: prvs=7702a5136c=joshua.earl@drexelmed.edu X-Barracuda-Apparent-Source-IP: 198.17.30.172 Received: from pps.filterd (pp-mta1.drexelmed.edu [127.0.0.1]) by pp-mta1.drexelmed.edu (8.15.0.59/8.14.7) with SMTP id t8HGZWxF010668 for ; Thu, 17 Sep 2015 12:45:10 -0400 Received: from ncb-sv-103.ducom.edu ([10.16.20.136]) by pp-mta1.drexelmed.edu with ESMTP id 1x016300rk-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 17 Sep 2015 12:45:09 -0400 Received: from NCB-SV-117.DUCOM.edu ([fe80::6519:3ee7:4c6f:f2df]) by NCB-SV-103.DUCOM.edu ([::1]) with mapi id 14.03.0248.002; Thu, 17 Sep 2015 12:45:04 -0400 From: "Earl, Joshua P" To: "xfs@oss.sgi.com" Subject: RE: xfsxyncd in 'D' state Thread-Topic: xfsxyncd in 'D' state X-ASG-Orig-Subj: RE: xfsxyncd in 'D' state Thread-Index: AdDwn8phEmHFJRKXQuG/nBBkF7izjQAx6mag Date: Thu, 17 Sep 2015 16:45:03 +0000 Message-ID: <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DB8@NCB-SV-117.DUCOM.edu> References: <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2CA0@NCB-SV-117.DUCOM.edu> In-Reply-To: <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2CA0@NCB-SV-117.DUCOM.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.15.69] Content-Type: multipart/alternative; boundary="_000_2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DB8NCBSV117DUCOMed_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-09-17_06:2015-09-17,2015-09-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=ducom_outbound_notspam policy=ducom_outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1509170223 X-Barracuda-Connect: UNKNOWN[198.17.30.172] X-Barracuda-Start-Time: 1442508311 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE, RDNS_NONE, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22636 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS --_000_2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DB8NCBSV117DUCOMed_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Anyone have any ideas on this? Is this the right mailing list? It looks l= ike the email I sent with attachments didn't go through, should I copy and = paste the outputs into an email? We are pretty crippled without the use of= this drive, and it took several weeks to figure out that it was this proce= ss going into uninterruptible sleep that was the 'cause'. I don't know wh= at causes this however, I'm not sure how to track that down. There doesn't= seem to be anything accessing the drive as far as processes go... but on a= clean reboot within about 5 minutes this pops up: root 2216 0.0 0.0 0 0 ? D 12:24 0:00 [xfssyncd/= sdb1] And we are dead in the water until it lets go, which is currently hours lat= er. When we first experienced this problem it would only take a few minute= s to get back to a writable state. Any help would be greatly appreciated! Thanks, ~josh From: xfs-bounces@oss.sgi.com [mailto:xfs-bounces@oss.sgi.com] On Behalf Of= Earl, Joshua P Sent: Wednesday, September 16, 2015 12:50 PM To: xfs@oss.sgi.com Subject: RE: xfsxyncd in 'D' state I was also able to get the xfs_info after finally getting the drive remount= ed: [root@ncb-sv-016 ~]# xfs_info /home meta-data=3D/dev/sdb1 isize=3D256 agcount=3D70, agsize=3D26= 8435455 blks =3D sectsz=3D512 attr=3D2, projid32bit=3D0 data =3D bsize=3D4096 blocks=3D18554637056, ima= xpct=3D1 =3D sunit=3D0 swidth=3D0 blks naming =3Dversion 2 bsize=3D4096 ascii-ci=3D0 log =3Dinternal bsize=3D4096 blocks=3D521728, version= =3D2 =3D sectsz=3D512 sunit=3D0 blks, lazy-coun= t=3D1 realtime =3Dnone extsz=3D4096 blocks=3D0, rtextents=3D0 From: Earl, Joshua P Sent: Tuesday, September 15, 2015 1:53 PM To: 'xfs@oss.sgi.com' > Subject: xfsxyncd in 'D' state Hello, I hope I'm writing to the correct list. I've recently run into a pr= oblem, which has me stumped. I'm running a cluster which shares an xfs fil= esystem to 10 nodes via nfs. This has been working for almost two years. = However, I've been running into trouble with the drive where if anything tr= ies to write to it at certain times it will simply hang, and every process = trying to write will also hang and go into the 'D' state. For example (jus= t editing a text file with emacs): [root@ncb-sv-016 ~]# ps aux|grep D USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2216 0.0 0.0 0 0 ? D 11:28 0:00 [xfssyncd/= sdb1] archana 7708 0.0 0.0 249700 13352 pts/0 D 11:35 0:00 emacs thin= gs root 11453 0.0 0.0 103312 868 pts/1 S+ 12:47 0:00 grep D This will remain like this for hours. Can't remount/unmount drive (sends t= he unmount command into 'D' state) I have no idea what's going on or how to fix it, but I'm hoping you guys mi= ght be able to point me in the right direction. Here is the info that's req= uested in the FAQ: ? kernel version (uname -a) Linux ncb-sv-016.ducom.edu 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:= 37:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ? xfsprogs version (xfs_repair -V) xfs_repair version 3.1.1 ? number of CPUs 16 ? contents of /proc/meminfo ? contents of /proc/mounts ? contents of /proc/partitions Attached except for mounts (not currently in the /proc directory, attached = the fstab instead (hopefully helpful?) ? RAID layout (hardware and/or software) The RAID-6 is the problem one Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVr= fy ---------------------------------------------------------------------------= --- u0 RAID-1 OK - - - 3725.28 RiW ON u1 RAID-6 OK - - 64K 70780.3 RiW ON u2 SPARE OK - - - 3726.01 - OFF VPort Status Unit Size Type Phy Encl-Slot Model ---------------------------------------------------------------------------= --- p8 OK u0 3.63 TB SATA - /c0/e0/slt0 WDC WD4000FYYZ-0= 1UL p9 OK u1 3.63 TB SATA - /c0/e0/slt4 WDC WD4000FYYZ-0= 1UL p10 OK u1 3.63 TB SATA - /c0/e0/slt8 WDC WD4000FYYZ-0= 1UL p11 OK u1 3.63 TB SATA - /c0/e0/slt12 WDC WD4000FYYZ-0= 1UL p12 OK u1 3.63 TB SATA - /c0/e0/slt16 WDC WD4000FYYZ-0= 1UL p13 OK u1 3.63 TB SATA - /c0/e0/slt20 WDC WD4000FYYZ-0= 1UL p14 OK u0 3.63 TB SATA - /c0/e0/slt1 WDC WD4000FYYZ-0= 1UL p15 OK u1 3.63 TB SATA - /c0/e0/slt5 WDC WD4000FYYZ-0= 1UL p16 OK u1 3.63 TB SATA - /c0/e0/slt9 WDC WD4000FYYZ-0= 1UL p17 OK u1 3.63 TB SATA - /c0/e0/slt13 WDC WD4000FYYZ-0= 1UL p18 OK u1 3.63 TB SATA - /c0/e0/slt17 WDC WD4000FYYZ-0= 1UL p19 OK u1 3.63 TB SATA - /c0/e0/slt21 WDC WD4000FYYZ-0= 1UL p20 OK u1 3.63 TB SATA - /c0/e0/slt2 WDC WD4000FYYZ-0= 1UL p21 OK u1 3.63 TB SATA - /c0/e0/slt6 WDC WD4000FYYZ-0= 1UL p22 OK u1 3.63 TB SATA - /c0/e0/slt10 WDC WD4000FYYZ-0= 1UL p23 OK u1 3.63 TB SATA - /c0/e0/slt14 WDC WD4000FYYZ-0= 1UL p24 OK u1 3.63 TB SATA - /c0/e0/slt18 WDC WD4000FYYZ-0= 1UL p25 OK u1 3.63 TB SATA - /c0/e0/slt22 WDC WD4000FYYZ-0= 1UL p26 OK u1 3.63 TB SATA - /c0/e0/slt3 WDC WD4000FYYZ-0= 1UL p27 OK u1 3.63 TB SATA - /c0/e0/slt7 WDC WD4000FYYZ-0= 1UL p28 OK u1 3.63 TB SATA - /c0/e0/slt11 WDC WD4000FYYZ-0= 1UL p29 OK u1 3.63 TB SATA - /c0/e0/slt15 WDC WD4000FYYZ-0= 1UL p30 OK u1 3.63 TB SATA - /c0/e0/slt19 WDC WD4000FYYZ-0= 1UL p31 OK u2 3.63 TB SATA - /c0/e0/slt23 WDC WD4000FYYZ-0= 1UL ? LVM configuration I don't *think* these are in an LVM.. I could be wrong. ? type of disks you are using Models included above in raid config. ? write cache status of drives ? size of BBWC and mode it is running in ? xfs_info output on the filesystem in question For the above three questions I'm not sure how to get the the cache status = of the drives, or what the BBWC is? xfs_info won't currently run (I'm waiti= ng on the drive to unmount) but I ran an xfs_check and an xfs_repair -n and= no errors were shown. ? dmesg output showing all error messages and stack traces Then you need to describe your workload that is causing the problem, and a = demonstration of the bad behaviour that is occurring. If it is a performanc= e problem, then 30s - 1 minute samples of: 1. iostat -x -d -m 5 [root@ncb-sv-016 ~]# iostat -x -d -m 5 Linux 2.6.32-358.23.2.el6.x86_64 (ncb-sv-016.ducom.edu) 09/15/2015 = _x86_64_ (16 CPU) Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.29 3.61 5.78 3.58 0.10 0.03 28.27 = 0.05 5.19 2.39 2.24 sdb 1.02 8.66 31.50 3.91 0.33 0.12 26.14 = 5.94 167.54 27.47 97.25 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 1.60 0.00 2.00 0.00 0.01 14.40 = 0.01 4.30 4.30 0.86 sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 = 6.46 6332.75 1250.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 3.60 0.00 7.00 0.00 0.04 12.11 = 0.02 0.60 1.77 1.24 sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 = 6.28 6256.60 1000.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.40 0.00 0.00 8.00 = 0.00 42.50 12.00 0.48 sdb 0.00 0.00 0.00 1.20 0.00 0.04 64.00 = 5.86 5846.33 833.33 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.60 0.00 0.60 0.00 0.00 16.00 = 0.01 12.67 12.67 0.76 sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 = 6.86 5725.20 1000.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 = 0.00 0.00 0.00 0.00 sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 = 6.06 5459.00 1000.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 4.00 0.00 1.60 0.00 0.02 26.00 = 0.01 6.75 6.50 1.04 sdb 0.00 0.00 0.00 1.00 0.00 0.03 51.20 = 7.05 5670.40 1000.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 29.40 0.00 2.60 0.00 0.12 98.46 = 0.01 4.54 4.08 1.06 sdb 0.00 0.00 0.00 1.20 0.00 0.03 53.33 = 6.54 7428.50 833.33 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 9.60 0.00 15.80 0.00 0.10 12.86 = 0.57 35.82 3.37 5.32 sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 = 6.30 5889.20 1000.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 7.80 0.00 12.80 0.00 0.08 12.38 = 0.74 58.09 15.06 19.28 sdb 0.00 0.00 0.00 1.20 0.00 0.04 64.00 = 6.49 6140.83 833.33 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 4.80 0.00 3.20 0.00 0.03 20.00 = 0.01 0.06 3.12 1.00 sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 = 5.10 6489.25 1250.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.20 0.00 0.00 8.00 = 0.02 152.00 103.00 2.06 sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 = 6.75 5791.00 1000.20 100.02 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 61.20 0.00 11.80 0.00 0.29 49.49 = 0.01 0.88 0.69 0.82 sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 = 6.37 5569.71 714.14 99.98 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.40 0.00 0.60 0.00 0.00 13.33 = 0.01 24.33 24.33 1.46 sdb 0.00 0.00 0.00 1.60 0.00 0.05 64.00 = 5.77 5162.00 625.12 100.02 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.40 0.00 0.00 8.00 = 0.00 3.00 1.50 0.06 sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 = 5.08 3428.50 1250.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 1.60 0.00 0.80 0.00 0.01 24.00 = 0.01 10.75 10.75 0.86 sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 = 5.86 3932.14 714.29 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 2.00 0.00 4.80 0.00 0.03 11.33 = 0.01 2.21 2.08 1.00 sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 = 5.60 3992.71 714.29 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 5.00 0.00 18.20 0.00 0.09 10.20 = 0.02 1.13 0.03 0.06 sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 = 5.44 4208.86 714.29 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 1.40 0.00 0.60 0.00 0.01 26.67 = 0.02 27.00 27.00 1.62 sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 = 5.22 4325.43 714.29 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.60 0.00 0.40 0.00 0.00 20.00 = 0.01 15.50 15.50 0.62 sdb 0.00 0.00 0.00 1.60 0.00 0.05 64.00 = 5.06 4022.75 625.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 = 0.00 0.00 0.00 0.00 sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 = 5.08 3495.50 1250.00 100.00 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz = avgqu-sz await svctm %util sda 0.00 1.60 0.00 1.60 0.00 0.01 12.00 = 0.07 42.88 42.50 6.80 sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 = 5.82 3894.71 714.29 100.00 2. vmstat 5 [root@ncb-sv-016 ~]# vmstat 5 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu= ----- r b swpd free buff cache si so bi bo in cs us sy id w= a st 0 0 0 126125768 19456 405396 0 0 28 10 421 150 0 0 9= 9 0 0 0 0 0 126125520 19464 405396 0 0 0 34 6679 13281 0 0 = 100 0 0 1 0 0 126124896 19472 405392 0 0 0 38 6718 13310 0 0 = 100 0 0 0 0 0 126125312 19472 405400 0 0 0 74 6658 13256 0 0 = 100 0 0 0 0 0 126125440 19480 405392 0 0 0 60 6664 13291 0 0 = 100 0 0 2 0 0 126125440 19480 405400 0 0 0 26 6660 13272 0 0 = 100 0 0 0 0 0 126125680 19488 405400 0 0 0 30 6659 13282 0 0 = 100 0 0 2 0 0 126125696 19496 405396 0 0 0 117 6686 13298 0 0 = 100 0 0 1 0 0 126125568 19496 405400 0 0 0 33 6661 13287 0 0 = 100 0 0 0 0 0 126125816 19504 405400 0 0 0 30 6663 13271 0 0 = 100 0 0 1 0 0 126125816 19504 405400 0 0 0 27 6659 13285 0 0 = 100 0 0 0 0 0 126125696 19512 405400 0 0 0 75 6670 13269 0 0 = 100 0 0 0 0 0 126125816 19520 405400 0 0 0 55 6671 13286 0 0 = 100 0 0 2 0 0 126125696 19528 405396 0 0 0 34 6670 13284 0 0 = 100 0 0 0 0 0 126125272 19528 405400 0 0 0 26 6700 13298 0 0 = 100 0 0 0 0 0 126125408 19536 405400 0 0 0 61 6660 13277 0 0 = 100 0 0 1 0 0 126125536 19544 405392 0 0 0 98 6677 13281 0 0 = 100 0 0 can give us insight into the IO and memory utilisation of your machine at t= he time of the problem. If the filesystem is hanging, then capture the output of the dmesg command = after running: # echo w > /proc/sysrq-trigger # dmesg will tell us all the hung processes in the machine, often pointing us direc= tly to the cause of the hang. Attached Thanks! Josh Earl, MS Research Instructor Drexel College of Medicine Center for Advanced Microbial Processing (CAMP) Institute of Molecular Medicine and Infectious Disease (215) 762-8133 ________________________________ This email and any accompanying attachments are confidential. The informati= on is intended solely for the use of the individual to whom it is addressed= . Any review, disclosure, copying, distribution, or use of this email commu= nication by others is strictly prohibited. If you are not the intended reci= pient, please notify the sender immediately and delete all copies. Thank yo= u for your cooperation. --_000_2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DB8NCBSV117DUCOMed_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anyone have any ideas = on this?  Is this the right mailing list?  It looks like the emai= l I sent with attachments didn’t go through, should I copy and paste = the outputs into an email?  We are pretty crippled without the use of this drive, and it took several weeks to figure out that it was= this process going into uninterruptible sleep that was the ‘cause= 217;.   I don’t know what causes this however, I’m no= t sure how to track that down.  There doesn’t seem to be anythin= g accessing the drive as far as processes go… but on a clean reboot wi= thin about 5 minutes this pops up:

 

root   =    2216  0.0  0.0      0 =     0 ?        D &nb= sp;  12:24   0:00 [xfssyncd/sdb1]

 

And we are dead in the= water until it lets go, which is currently hours later.  When we firs= t experienced this problem it would only take a few minutes to get back to = a writable state.

 

Any help would be grea= tly appreciated!

 

Thanks,

~josh

 

From: xfs-bounces@oss.sgi.com [mailto:xfs-bou= nces@oss.sgi.com] On Behalf Of Earl, Joshua P
Sent: Wednesday, September 16, 2015 12:50 PM
To: xfs@oss.sgi.com
Subject: RE: xfsxyncd in 'D' state

 

I was also able to get= the xfs_info after finally getting the drive remounted:<= /p>

 

[= root@ncb-sv-016 ~]# xfs_info /home

m= eta-data=3D/dev/sdb1         &= nbsp;    isize=3D256    agcount=3D70, agsize= =3D268435455 blks

&= nbsp;        =3D    =             &nb= sp;      sectsz=3D512   attr=3D2, projid= 32bit=3D0

d= ata     =3D       &n= bsp;            = ;   bsize=3D4096   blocks=3D18554637056, imaxpct=3D1

&= nbsp;        =3D    =             &nb= sp;      sunit=3D0      s= width=3D0 blks

n= aming   =3Dversion 2       &nb= sp;      bsize=3D4096   ascii-ci=3D0

l= og      =3Dinternal     &= nbsp;         bsize=3D4096 &nb= sp; blocks=3D521728, version=3D2

&= nbsp;        =3D    =             &nb= sp;      sectsz=3D512   sunit=3D0 blks, = lazy-count=3D1

r= ealtime =3Dnone          =          extsz=3D4096   b= locks=3D0, rtextents=3D0

 

From: Earl, Joshua P
Sent: Tuesday, September 15, 2015 1:53 PM
To: 'xfs@oss.sgi.com' <xfs@oss= .sgi.com>
Subject: xfsxyncd in 'D' state

 

Hello, I hope I’m writing to the correct list.=   I’ve recently run into a problem, which has me stumped.  = I’m running a cluster which shares an xfs filesystem to 10 nodes via = nfs.  This has been working for almost two years.  However, IR= 17;ve been running into trouble with the drive where if anything tries to write = to it at certain times it will simply hang, and every process trying to wri= te will also hang and go into the ‘D’ state.  For example = (just editing a text file with emacs):

 

[root@ncb-sv-01= 6 ~]# ps aux|grep D

USER  = ;     PID %CPU %MEM    VSZ   R= SS TTY      STAT START   TIME COMMAND

root  = ;    2216  0.0  0.0      = 0     0 ?        D&n= bsp;   11:28   0:00 [xfssyncd/sdb1]

archana &n= bsp; 7708  0.0  0.0 249700 13352 pts/0    D &= nbsp;  11:35   0:00 emacs things

root  = ;   11453  0.0  0.0 103312   868 pts/1 &= nbsp;  S+   12:47   0:00 grep D

 

This will remain like this for hours.  Can̵= 7;t remount/unmount drive (sends the unmount command into ‘D’ s= tate)

 

I have no idea what’s going on or how to fix i= t, but I’m hoping you guys might be able to point me in the right dir= ection. Here is the info that’s requested in the FAQ:

§  kernel version (uname -a)

Linux ncb-sv-016.ducom.edu 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed = Oct 16 18:37:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

§  xfsprogs version (xfs_repair -V)

xfs_repair version 3.1.1

§  number of CPUs

16

§  contents of /proc/meminfo

§  contents of /proc/mounts

§  contents of /proc/partitions<= /o:p>

Attached except for mounts (not currently in the /proc directory,= attached the fstab instead (hopefully helpful?)

§  RAID layout (hardware and/or softw= are) The RAID-6 is the problem one

Unit = UnitType  Status         %RCm= pl  %V/I/M  Stripe  Size(GB)  Cache  AVrfy

----------= --------------------------------------------------------------------

u0 &n= bsp;  RAID-1    OK      &= nbsp;      -       -=        -       = 3725.28   RiW    ON    

u1 &n= bsp;  RAID-6    OK      &= nbsp;      -       -=        64K     70780.3&nb= sp;  RiW    ON    

u2 &n= bsp;  SPARE     OK     &n= bsp;       -     &nb= sp; -       -     &n= bsp; 3726.01   -      OFF  &nb= sp;

 = ;

VPort Stat= us         Unit Size  &nb= sp;   Type  Phy Encl-Slot    Model=

----------= --------------------------------------------------------------------

p8 &n= bsp;  OK          &n= bsp;  u0   3.63 TB   SATA  -   /c0/= e0/slt0  WDC WD4000FYYZ-01UL

p9 &n= bsp;  OK          &n= bsp;  u1   3.63 TB   SATA  -   /c0/= e0/slt4  WDC WD4000FYYZ-01UL

p10 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t8  WDC WD4000FYYZ-01UL

p11 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t12 WDC WD4000FYYZ-01UL

p12 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t16 WDC WD4000FYYZ-01UL

p13 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t20 WDC WD4000FYYZ-01UL

p14 &= nbsp; OK           &= nbsp; u0   3.63 TB   SATA  -   /c0/e0/sl= t1  WDC WD4000FYYZ-01UL

p15 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t5  WDC WD4000FYYZ-01UL

p16 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t9  WDC WD4000FYYZ-01UL

p17 &= nbsp; OK            =  u1   3.63 TB   SATA  -   /c0/e0/sl= t13 WDC WD4000FYYZ-01UL

p18 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t17 WDC WD4000FYYZ-01UL

p19 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t21 WDC WD4000FYYZ-01UL

p20 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t2  WDC WD4000FYYZ-01UL

p21 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t6  WDC WD4000FYYZ-01UL

p22 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t10 WDC WD4000FYYZ-01UL

p23 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t14 WDC WD4000FYYZ-01UL

p24 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t18 WDC WD4000FYYZ-01UL

p25 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t22 WDC WD4000FYYZ-01UL

p26 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t3  WDC WD4000FYYZ-01UL

p27 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t7  WDC WD4000FYYZ-01UL

p28 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t11 WDC WD4000FYYZ-01UL

p29 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t15 WDC WD4000FYYZ-01UL

p30 &= nbsp; OK           &= nbsp; u1   3.63 TB   SATA  -   /c0/e0/sl= t19 WDC WD4000FYYZ-01UL

p31 &= nbsp; OK           &= nbsp; u2   3.63 TB   SATA  -   /c0/e0/sl= t23 WDC WD4000FYYZ-01UL

§  LVM configuration

I don’t *think* these are in an LVM.. I could be wro= ng.

§  type of disks you are using

Models included above in raid config.

§  write cache status of drives<= /o:p>

§  size of BBWC and mode it is runnin= g in

§  xfs_info output on the filesystem = in question

For the above three questions I’m not sure how to get the t= he cache status of the drives, or what the BBWC is? xfs_info won’t cu= rrently run (I’m waiting on the drive to unmount) but I ran an xfs_check and an xfs_repair –n and no errors were shown.=

§  dmesg output showing all error mes= sages and stack traces

Then you need to describe your workload that is causing the probl= em, and a demonstration of the bad behaviour that is occurring. If it is a = performance problem, then 30s - 1 minute samples of:

1.    iostat -x -d -m 5

[root@ncb-sv-016 ~]# iostat -x -d -m 5

Linux 2.6.= 32-358.23.2.el6.x86_64 (ncb-sv-016.ducom.edu)      = ; 09/15/2015    _x86_64_      (16 CPU)

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.29     3.61    5.78  &nbs= p; 3.58     0.10     0.03 &nbs= p;  28.27     0.05    5.19 &nb= sp; 2.39   2.24

sdb &= nbsp;            &nb= sp;1.02     8.66   31.50    3.= 91     0.33     0.12  &nb= sp; 26.14     5.94  167.54  27.47  97.25=

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     1.60    0.00  &nbs= p; 2.00     0.00     0.01 &nbs= p;  14.40     0.01    4.30 &nb= sp; 4.30   0.86

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.80     0.00     0.03 &nbs= p;  64.00     6.46 6332.75 1250.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     3.60    0.00  &nbs= p; 7.00     0.00     0.04 &nbs= p;  12.11     0.02    0.60 &nb= sp; 1.77   1.24

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.00     0.00     0.03 &nbs= p;  64.00     6.28 6256.60 1000.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.40     0.00     0.00 &nbs= p;   8.00     0.00   42.50  12= .00   0.48

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.20     0.00     0.04 &nbs= p;  64.00     5.86 5846.33 833.33 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.60    0.00  &nbs= p; 0.60     0.00     0.00 &nbs= p;  16.00     0.01   12.67  12.67&n= bsp;  0.76

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.00     0.00     0.03 &nbs= p;  64.00     6.86 5725.20 1000.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.00     0.00     0.00 &nbs= p;   0.00     0.00    0.00&nbs= p;  0.00   0.00

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.00     0.00     0.03 &nbs= p;  64.00     6.06 5459.00 1000.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     4.00    0.00  &nbs= p; 1.60     0.00     0.02 &nbs= p;  26.00     0.01    6.75 &nb= sp; 6.50   1.04

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.00     0.00     0.03 &nbs= p;  51.20     7.05 5670.40 1000.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00    29.40    0.00    2.= 60     0.00     0.12  &nb= sp; 98.46     0.01    4.54   4= .08   1.06

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.20     0.00     0.03 &nbs= p;  53.33     6.54 7428.50 833.33 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     9.60    0.00   15.= 80     0.00     0.10  &nb= sp; 12.86     0.57   35.82   3.37&n= bsp;  5.32

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.00     0.00     0.03 &nbs= p;  64.00     6.30 5889.20 1000.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     7.80    0.00   12.= 80     0.00     0.08  &nb= sp; 12.38     0.74   58.09  15.06  = 19.28

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.20     0.00     0.04 &nbs= p;  64.00     6.49 6140.83 833.33 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     4.80    0.00  &nbs= p; 3.20     0.00     0.03 &nbs= p;  20.00     0.01    0.06 &nb= sp; 3.12   1.00

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.80     0.00     0.03 &nbs= p;  64.00     5.10 6489.25 1250.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.20     0.00     0.00 &nbs= p;   8.00     0.02  152.00 103.00 &= nbsp; 2.06

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.00     0.00     0.03 &nbs= p;  64.00     6.75 5791.00 1000.20 100.02

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00    61.20    0.00   11.80&nb= sp;    0.00     0.29    4= 9.49     0.01    0.88   0.69&n= bsp;  0.82

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.40     0.00     0.04 &nbs= p;  64.00     6.37 5569.71 714.14  99.98=

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.40    0.00  &nbs= p; 0.60     0.00     0.00 &nbs= p;  13.33     0.01   24.33  24.33&n= bsp;  1.46

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.60     0.00     0.05 &nbs= p;  64.00     5.77 5162.00 625.12 100.02

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.40     0.00     0.00 &nbs= p;   8.00     0.00    3.00&nbs= p;  1.50   0.06

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.80     0.00     0.03 &nbs= p;  64.00     5.08 3428.50 1250.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     1.60    0.00  &nbs= p; 0.80     0.00     0.01 &nbs= p;  24.00     0.01   10.75  10.75&n= bsp;  0.86

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.40     0.00     0.04 &nbs= p;  64.00     5.86 3932.14 714.29 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     2.00    0.00  &nbs= p; 4.80     0.00     0.03 &nbs= p;  11.33     0.01    2.21 &nb= sp; 2.08   1.00

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.40     0.00     0.04 &nbs= p;  64.00     5.60 3992.71 714.29 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     5.00    0.00   18.= 20     0.00     0.09  &nb= sp; 10.20     0.02    1.13   0= .03   0.06

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.40     0.00     0.04 &nbs= p;  64.00     5.44 4208.86 714.29 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     1.40    0.00  &nbs= p; 0.60     0.00     0.01 &nbs= p;  26.67     0.02   27.00  27.00&n= bsp;  1.62

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.40     0.00     0.04 &nbs= p;  64.00     5.22 4325.43 714.29 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.60    0.00  &nbs= p; 0.40     0.00     0.00 &nbs= p;  20.00     0.01   15.50  15.50&n= bsp;  0.62

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.60     0.00     0.05 &nbs= p;  64.00     5.06 4022.75 625.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.00     0.00     0.00 &nbs= p;   0.00     0.00    0.00&nbs= p;  0.00   0.00

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 0.80     0.00     0.03 &nbs= p;  64.00     5.08 3495.50 1250.00 100.00

 = ;

Device:&nb= sp;        rrqm/s   wrqm/s&nbs= p;    r/s     w/s    rMB/= s    wMB/s avgrq-sz avgqu-sz   await  svctm&n= bsp; %util

sda &= nbsp;           &nbs= p; 0.00     1.60    0.00  &nbs= p; 1.60     0.00     0.01 &nbs= p;  12.00     0.07   42.88  42.50&n= bsp;  6.80

sdb &= nbsp;           &nbs= p; 0.00     0.00    0.00  &nbs= p; 1.40     0.00     0.04 &nbs= p;  64.00     5.82 3894.71 714.29 100.00

2.    vmstat 5

[root@ncb-sv-016 ~]# vmstat 5

procs ----= -------memory---------- ---swap-- -----io---- --system-- -----cpu-----=

r  b&= nbsp;  swpd   free   buff  cache   = si   so    bi    bo   in&= nbsp;  cs us sy id wa st

0  0&= nbsp;     0 126125768  19456 405396  &nb= sp; 0    0    28    10  4= 21  150  0  0 99  0  0    &nbs= p;

0  0&= nbsp;     0 126125520  19464 405396  &nb= sp; 0    0     0    34 66= 79 13281  0  0 100  0  0   

1  0&= nbsp;     0 126124896  19472 405392  &nb= sp; 0    0     0    38 67= 18 13310  0  0 100  0  0   

0  0&= nbsp;     0 126125312  19472 405400  &nb= sp; 0    0     0    74 66= 58 13256  0  0 100  0  0   

0  0&= nbsp;     0 126125440  19480 405392  &nb= sp; 0    0     0    60 66= 64 13291  0  0 100  0  0   

2  0&= nbsp;     0 126125440  19480 405400  &nb= sp; 0    0     0    26 66= 60 13272  0  0 100  0  0   

0  0&= nbsp;     0 126125680  19488 405400  &nb= sp; 0    0     0    30 66= 59 13282  0  0 100  0  0   

2  0&= nbsp;     0 126125696  19496 405396  &nb= sp; 0    0     0   117 6686 13= 298  0  0 100  0  0   

1  0&= nbsp;     0 126125568  19496 405400  &nb= sp; 0    0     0    33 66= 61 13287  0  0 100  0  0   

0  0&= nbsp;     0 126125816  19504 405400  &nb= sp; 0    0     0    30 66= 63 13271  0  0 100  0  0   

1  0&= nbsp;     0 126125816  19504 405400  &nb= sp; 0    0     0    27 66= 59 13285  0  0 100  0  0   

0  0&= nbsp;     0 126125696  19512 405400  &nb= sp; 0    0     0    75 66= 70 13269  0  0 100  0  0   

0  0&= nbsp;     0 126125816  19520 405400  &nb= sp; 0    0     0    55 66= 71 13286  0  0 100  0  0   

2  0&= nbsp;     0 126125696  19528 405396  &nb= sp; 0    0     0    34 66= 70 13284  0  0 100  0  0   

0  0&= nbsp;     0 126125272  19528 405400  &nb= sp; 0    0     0    26 67= 00 13298  0  0 100  0  0   

0  0&= nbsp;     0 126125408  19536 405400  &nb= sp; 0    0     0    61 66= 60 13277  0  0 100  0  0   

1  0&= nbsp;     0 126125536  19544 405392  &nb= sp; 0    0     0    98 66= 77 13281  0  0 100  0  0   

can give us insight into the IO and memory utilisation of your ma= chine at the time of the problem.

If the filesystem is hanging, then capture the output of the dmes= g command after running:

# echo w > /proc/sysrq-trigger

# dmesg

will tell us all the hung processes in the machine, often pointin= g us directly to the cause of the hang.

Attached

 

Thanks!

 

Josh Earl, MS

Research Instructor

Drexel College of Medici= ne

Center for Advanced Microbial Processing (CAMP)<= /o:p>

Institute of Molecular Medicine and Infectious Diseas= e

(215) 762-8133

 

This email and any accompanying attachment= s are confidential. The information is intended solely for the use of the i= ndividual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this email communication by o= thers is strictly prohibited. If you are not the intended recipient, please= notify the sender immediately and delete all copies. Thank you for your co= operation.

--_000_2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DB8NCBSV117DUCOMed_-- From tdm@sgi.com Thu Sep 17 11:54:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 940517F4E for ; Thu, 17 Sep 2015 11:54:43 -0500 (CDT) Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay2.corp.sgi.com (Postfix) with ESMTP id 728BC304048 for ; Thu, 17 Sep 2015 09:54:43 -0700 (PDT) Received: from [128.162.232.11] (porter.americas.sgi.com [128.162.232.11]) by estes.americas.sgi.com (Postfix) with ESMTP id 285947002C59 for ; Thu, 17 Sep 2015 11:54:43 -0500 (CDT) Message-ID: <55FAF053.3020405@sgi.com> Date: Thu, 17 Sep 2015 11:54:43 -0500 From: Troy McCorkell User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: What's up with this list? References: <541AFB60.5030403@sgi.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030908070607000202060700" This is a multi-part message in MIME format. --------------030908070607000202060700 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 09/16/2015 07:53 AM, Carlos E. R. wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Content-ID: > > > El 2014-09-18 a las 10:33 -0500, Troy McCorkell escribió: >> On 09/18/2014 07:46 AM, Carlos E. R. wrote: >> >> Hi, >> >> Now an then I get messages like this: >> >> ++································· >> Your membership in the mailing list xfs has been disabled due to >> excessive bounces The last bounce received from you was dated >> 18-Sep-2014. You will not get any more messages from this list >> until >> you re-enable your membership. You will receive 3 more >> reminders like >> this before your membership in the list is deleted. >> >> To re-enable your membership, you can simply respond to this >> message >> (leaving the Subject: line intact), or visit the confirmation >> page at >> >> ... >> >> ·································++- >> >> >> Bounces? I'm subscribed to several mail lists, and this is the >> only one "complaining". And as I do not know >> what messages bounced, I can not investigate it. >> >> My guess is that those emails were clear and flagrant spam, and >> as such were rejected by my ISP. >> >> The mail list should refuse them on entry and not resend them >> to the listers. >> >> - -- Cheers, >> Carlos E. R. >> (from 13.1 x86_64 "Bottle" at Telcontar) >> >> Carlos, >> >> I will forward your email to the SGI IT group. > > Well, I got no further feedback, and the issue continues, a year later. > > As I see it, it goes like this: > > Spam is sent to the list. The list forwards it to subscribers. Some > mail servers, like my ISP, point blank refuse to accept what is > flagrant spam; not a doubt about it, it doesn't reach the spam folder. > That spam probably breaks a rule such as having no valid sender > domain, breaking SPF, something. I don't know for sure, because I can > not see the logs of my ISP. But the oss.sgi.com admin can, surely. > > > The problem for me is that this list server automatically unsubscribes > me, and I have to re-subscribe, posibly loosing interveening posts. > > > I suggest that the list server implements filters to remove those spam > mails on entry, instead of forwarding them. Alternatively, other mail > list servers send a probe email to the subscriber; if the probe > bounces, twice, then the subscription is temporarily disabled. But > they don't unsubscribe people because some "list" posts bounce, unless > it is excesive. > > > - -- Cheers > Carlos E. R. > > (from 13.1 x86_64 "Bottle" (Minas Tirith)) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iF4EAREIAAYFAlX5ZmQACgkQja8UbcUWM1wcxQD7BUPP7V8jRho3G3H0Oz/ZqVVs > APLSE6oLIsGW/4GYn54A/0RiNx3Nd5gLhW8hYv6ljyNLqH26aUzYdiw3YO7c3mbb > =oF/M > -----END PGP SIGNATURE----- > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > I'll chat with the SGI IT group again. Thanks, Troy --------------030908070607000202060700 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09/16/2015 07:53 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Content-ID: <alpine.LSU.2.11.1509161452080.25528@minas-tirith.valinor>


El 2014-09-18 a las 10:33 -0500, Troy McCorkell escribió:
On 09/18/2014 07:46 AM, Carlos E. R. wrote:

      Hi,

      Now an then I get messages like this:

      ++·································
      Your membership in the mailing list xfs has been disabled due to
      excessive bounces The last bounce received from you was dated
      18-Sep-2014.  You will not get any more messages from this list until
      you re-enable your membership.  You will receive 3 more reminders like
      this before your membership in the list is deleted.

      To re-enable your membership, you can simply respond to this message
      (leaving the Subject: line intact), or visit the confirmation page at

      ...

      ·································++-


      Bounces? I'm subscribed to several mail lists, and this is the only one "complaining". And as I do not know
      what messages bounced, I can not investigate it.

      My guess is that those emails were clear and flagrant spam, and as such were rejected by my ISP.

      The mail list should refuse them on entry and not resend them to the listers.

      - -- Cheers,
             Carlos E. R.
             (from 13.1 x86_64 "Bottle" at Telcontar)

Carlos,

I will forward your email to the SGI IT group.

Well, I got no further feedback, and the issue continues, a year later.

As I see it, it goes like this:

Spam is sent to the list. The list forwards it to subscribers. Some mail servers, like my ISP, point blank refuse to accept what is flagrant spam; not a doubt about it, it doesn't reach the spam folder. That spam probably breaks a rule such as having no valid sender domain, breaking SPF, something. I don't know for sure, because I can not see the logs of my ISP. But the oss.sgi.com admin can, surely.


The problem for me is that this list server automatically unsubscribes me, and I have to re-subscribe, posibly loosing interveening posts.


I suggest that the list server implements filters to remove those spam mails on entry, instead of forwarding them. Alternatively, other mail list servers send a probe email to the subscriber; if the probe bounces, twice, then the subscription is temporarily disabled. But they don't unsubscribe people because some "list" posts bounce, unless it is excesive.


- -- Cheers
       Carlos E. R.

       (from 13.1 x86_64 "Bottle" (Minas Tirith))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlX5ZmQACgkQja8UbcUWM1wcxQD7BUPP7V8jRho3G3H0Oz/ZqVVs
APLSE6oLIsGW/4GYn54A/0RiNx3Nd5gLhW8hYv6ljyNLqH26aUzYdiw3YO7c3mbb
=oF/M
-----END PGP SIGNATURE-----

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

I'll chat with the SGI IT group again.

Thanks,
Troy
--------------030908070607000202060700-- From sandeen@sandeen.net Thu Sep 17 12:02:21 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 41A457F4E for ; Thu, 17 Sep 2015 12:02:21 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 300C930404E for ; Thu, 17 Sep 2015 10:02:14 -0700 (PDT) X-ASG-Debug-ID: 1442509332-04cb6c355a18e460001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id sGVXxEZ9STv8kUJf for ; Thu, 17 Sep 2015 10:02:12 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 7D85E63BECC9 for ; Thu, 17 Sep 2015 12:02:12 -0500 (CDT) Subject: Re: [RFC PATCH] xfs_io: Implement inodes64 command To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [RFC PATCH] xfs_io: Implement inodes64 command References: <1442499846-10470-1-git-send-email-cmaiolino@redhat.com> From: Eric Sandeen Message-ID: <55FAF212.2010308@sandeen.net> Date: Thu, 17 Sep 2015 12:02:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1442499846-10470-1-git-send-email-cmaiolino@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1442509332 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22637 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- (oops, resending to list not just Carlos) On 9/17/15 9:24 AM, Carlos Maiolino wrote: > This command aims to implement an easy way to check a filesystem for the > existence of 64bit inodes. > > Based on XFS_IOC_FSINUMBERS, and starting with a lastip = 0xffffffff > instead of 0. > > For now, it just returns a string saying there is or there is no 64bit inodes > in the filesystem, but, I was wondering if it might not be better to just return > 0 or 1, so it can be used inside scripts to check for that. Or maybe an argument > to chose between an integer output or a string verbose output. > > Also, I was wondering if might be useful to, besides return the existence of > 64bit inodes, also inform if there is any 64bit inodes allocated in the groups > or not. Although, this will need the tool to walk through all the inode groups > checking for allocated inodes or not, instead of just stop at the first 64bit > inode found. I'm not sure what you mean here - list the groups which contain them? Any group above the one where the first 64 bit inode is found will also have 64-bit inodes, (unless they have no inodes at all) - so I don't see the value, but maybe I'm missing something. > Also, I'm still not sure if 'inodes64' is a good name for the command, I was > also thinking about something like 'chk64inos' but 'inodes64' was the best and > easy to be remembered I could find. Eh, seems reasonable to me. Not super, but I can't think of anything much better. > Comments are appreciated Below... > Signed-off-by: Carlos Maiolino > --- > io/open.c | 39 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 39 insertions(+) > > diff --git a/io/open.c b/io/open.c > index ac5a5e0..3a98fdf 100644 > --- a/io/open.c > +++ b/io/open.c > @@ -44,6 +44,7 @@ static cmdinfo_t statfs_cmd; > static cmdinfo_t chproj_cmd; > static cmdinfo_t lsproj_cmd; > static cmdinfo_t extsize_cmd; > +static cmdinfo_t inodes64_cmd; > static prid_t prid; > static long extsize; > > @@ -750,6 +751,37 @@ statfs_f( > return 0; > } > > +static int > +inodes64_f( > + int argc, > + char **argv) > +{ > + int i; > + __s32 count; > + __u64 last = 0xffffffff; might be good to use XFS_MAXINUMBER_32 here > + xfs_inogrp_t igroup[64]; why 64? wouldn't one suffice? > + xfs_fsop_bulkreq_t bulkreq; > + > + /* Setup bulkreq structure */ > + bulkreq.lastip = &last; > + bulkreq.icount = 64; > + bulkreq.ubuffer = &igroup; > + bulkreq.ocount = &count; > + > + while (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq) == 0) { > + if (count > 0) { > + printf("Filesystem does have 64bit inodes\n"); > + return 0; > + } else { > + printf("Filesystem does not have 64bit inodes\n"); > + return 0; > + } > + } I'm also not sure what the "while" is for, here. If you start at XFS_MAXINUMBER_32, won't a single call either give you count = 1 or count = 0? > + perror("xfsctl(XFS_IOC_FSINUMBERS)"); > + exitcode = 1; > + return 0; > +} > + > void > open_init(void) > { > @@ -815,6 +847,12 @@ open_init(void) > _("get/set preferred extent size (in bytes) for the open file"); > extsize_cmd.help = extsize_help; > > + inodes64_cmd.name = "inodes64"; > + inodes64_cmd.cfunc = inodes64_f; > + inodes64_cmd.flags = CMD_NOMAP_OK; > + inodes64_cmd.oneline = > + _("Checks if filesyste contais 64bit inodes"); "if filesystem contains" > + > add_command(&open_cmd); > add_command(&stat_cmd); > add_command(&close_cmd); > @@ -822,4 +860,5 @@ open_init(void) > add_command(&chproj_cmd); > add_command(&lsproj_cmd); > add_command(&extsize_cmd); > + add_command(&inodes64_cmd); > } needs xfs_io manpage updates too, and possibly an xfstest test case? -Eric From robin.listas@gmail.com Thu Sep 17 13:31:13 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id BE4027F4E for ; Thu, 17 Sep 2015 13:31:13 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 56734AC001 for ; Thu, 17 Sep 2015 11:31:10 -0700 (PDT) X-ASG-Debug-ID: 1442514667-04cbb005ea1bb200001-NocioJ Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by cuda.sgi.com with ESMTP id kCJ2QGCKlCEWrNzc (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 17 Sep 2015 11:31:08 -0700 (PDT) X-Barracuda-Envelope-From: robin.listas@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.212.170 Received: by wicfx3 with SMTP id fx3so2515902wic.0 for ; Thu, 17 Sep 2015 11:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=6eHoi9yzAYJXz2qb38Dk6vbU5/7s7LthM+FSCPj/u5g=; b=QWejDXhqv3F71mtNb+SaB4hIFc5HSohhR4713N3EJNXk4HngdF4vgra69LHgIb25Pq KQFWh4bYOY0LeUHvuBdwa9Gw69UK65+NBmHeXCbxwmbqfRUO/61khe1w09TimEsuzhln WhIcQ7oRNO4pOYHaN0F8CalGnzBd+oQvGvojcm3Uqz6ed02IcDOFKwhmma6/oMX1fr2B tbVsNl7mJIjCHE6ACEvthQZ3P0eL1wU07mGiF9riJpgqHfr+7XnL1yDKxlKjhR3GEwgX Y0dm5c8vsx4CbLdV080wrqfOYNWeUP+MP/QPYYR0//JseTt6mRF+0hyln+fc/ntQKlbE B8kA== X-Received: by 10.194.103.194 with SMTP id fy2mr1130158wjb.10.1442514667393; Thu, 17 Sep 2015 11:31:07 -0700 (PDT) Received: from minas-tirith.valinor (3.Red-83-42-78.dynamicIP.rima-tde.net. [83.42.78.3]) by smtp.gmail.com with ESMTPSA id ly4sm2142156wjb.4.2015.09.17.11.31.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Sep 2015 11:31:06 -0700 (PDT) Sender: Carlos Robinson Received: from minas-tirith.valinor (localhost [127.0.0.1]) by minas-tirith.valinor (Postfix) with ESMTP id E0330182871 for ; Thu, 17 Sep 2015 20:31:04 +0200 (CEST) Subject: Re: What's up with this list? To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: What's up with this list? References: <541AFB60.5030403@sgi.com> <55FAF053.3020405@sgi.com> From: "Carlos E. R." Message-ID: <55FB06E8.1020203@opensuse.org> Date: Thu, 17 Sep 2015 20:31:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FAF053.3020405@sgi.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-wi0-f170.google.com[209.85.212.170] X-Barracuda-Start-Time: 1442514668 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22641 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-09-17 18:54, Troy McCorkell wrote: > On 09/16/2015 07:53 AM, Carlos E. R. wrote: > I'll chat with the SGI IT group again. Thanks :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlX7BugACgkQja8UbcUWM1yf2gD9GZrVQopDE+YS1yrbhHS+GiYd nV4ZiwQ15EJkRpvwOssA/jEGl2f3SMHd6s2wCpStP2Smm/mOwMszoWX6N5qTS/34 =tcZ8 -----END PGP SIGNATURE----- From bfoster@redhat.com Thu Sep 17 14:21:10 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 085BE7F4E for ; Thu, 17 Sep 2015 14:21:10 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 9A09AAC003 for ; Thu, 17 Sep 2015 12:21:09 -0700 (PDT) X-ASG-Debug-ID: 1442517664-04bdf04db51b2da0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id DCY9bWKwTaNaTuRd (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Sep 2015 12:21:05 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id BFDE2461E3; Thu, 17 Sep 2015 19:21:04 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8HJL4LJ029733; Thu, 17 Sep 2015 15:21:04 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 850741200A8; Thu, 17 Sep 2015 15:21:03 -0400 (EDT) Date: Thu, 17 Sep 2015 15:21:03 -0400 From: Brian Foster To: "Earl, Joshua P" Cc: "xfs@oss.sgi.com" Subject: Re: xfsxyncd in 'D' state Message-ID: <20150917192102.GA5342@bfoster.bfoster> X-ASG-Orig-Subj: Re: xfsxyncd in 'D' state References: <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2CA0@NCB-SV-117.DUCOM.edu> <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DB8@NCB-SV-117.DUCOM.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DB8@NCB-SV-117.DUCOM.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442517665 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 17, 2015 at 04:45:03PM +0000, Earl, Joshua P wrote: > Anyone have any ideas on this? Is this the right mailing list? It looks like the email I sent with attachments didn't go through, should I copy and paste the outputs into an email? We are pretty crippled without the use of this drive, and it took several weeks to figure out that it was this process going into uninterruptible sleep that was the 'cause'. I don't know what causes this however, I'm not sure how to track that down. There doesn't seem to be anything accessing the drive as far as processes go... but on a clean reboot within about 5 minutes this pops up: > Were the attachments large? You could try to compress them or perhaps host them somewhere and post a link. (Also, please try not to top-post). > root 2216 0.0 0.0 0 0 ? D 12:24 0:00 [xfssyncd/sdb1] > > And we are dead in the water until it lets go, which is currently hours later. When we first experienced this problem it would only take a few minutes to get back to a writable state. > That is responsible for writing out metadata and things on older kernels. When was this problem "first experienced" as opposed to the current state? Did performance drop off slowly or rapidly? > Any help would be greatly appreciated! > > Thanks, > ~josh > > From: xfs-bounces@oss.sgi.com [mailto:xfs-bounces@oss.sgi.com] On Behalf Of Earl, Joshua P > Sent: Wednesday, September 16, 2015 12:50 PM > To: xfs@oss.sgi.com > Subject: RE: xfsxyncd in 'D' state > > I was also able to get the xfs_info after finally getting the drive remounted: > > [root@ncb-sv-016 ~]# xfs_info /home > meta-data=/dev/sdb1 isize=256 agcount=70, agsize=268435455 blks > = sectsz=512 attr=2, projid32bit=0 > data = bsize=4096 blocks=18554637056, imaxpct=1 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0 > log =internal bsize=4096 blocks=521728, version=2 > = sectsz=512 sunit=0 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 > So this is a 70TB fs with what looks like mostly default settings. Note that no stripe unit/width are set, fwiw. I don't see current fs utilization (df, df -i) or mount options reported anywhere. Can you provide that information? > From: Earl, Joshua P > Sent: Tuesday, September 15, 2015 1:53 PM > To: 'xfs@oss.sgi.com' > > Subject: xfsxyncd in 'D' state > > Hello, I hope I'm writing to the correct list. I've recently run into a problem, which has me stumped. I'm running a cluster which shares an xfs filesystem to 10 nodes via nfs. This has been working for almost two years. However, I've been running into trouble with the drive where if anything tries to write to it at certain times it will simply hang, and every process trying to write will also hang and go into the 'D' state. For example (just editing a text file with emacs): > You haven't really described the workload either. If not much is going on from the server itself, what are those 10 nfs clients doing when this occurs? In general, the more information you provide about the environment and workload, the more likely other folks here who might be more familiar with NFS and/or hwraid might chime in with suggestions. Not being an NFS expert myself, I'd probably unexport the filesystem, mount it locally and run some tests there to see what seems to induce this behavior, if anything. For example, what happens if existing files are read or directories listed? In terms of writes, does a sequential file writer have reasonable performance (dd)? Can you allocate inodes (e.g., create a temp dir somewhere and run a 'touch' loop to create new files) without any issues? You could also try to untar a tarball, run a short fio/fsstress/whatever workload, etc. If nothing seems to trigger it locally, I'd start to look at adding back the clients to try identify contributors. > [root@ncb-sv-016 ~]# ps aux|grep D > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 2216 0.0 0.0 0 0 ? D 11:28 0:00 [xfssyncd/sdb1] > archana 7708 0.0 0.0 249700 13352 pts/0 D 11:35 0:00 emacs things > root 11453 0.0 0.0 103312 868 pts/1 S+ 12:47 0:00 grep D > What's the stack trace for the emacs process when this occurs? I suspect it would eventually get dumped to the logs as a stalled task, but /proc//stack should show it as well. > This will remain like this for hours. Can't remount/unmount drive (sends the unmount command into 'D' state) > > I have no idea what's going on or how to fix it, but I'm hoping you guys might be able to point me in the right direction. Here is the info that's requested in the FAQ: > ? kernel version (uname -a) > Linux ncb-sv-016.ducom.edu 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:37:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > ? xfsprogs version (xfs_repair -V) > xfs_repair version 3.1.1 > ? number of CPUs > 16 > ? contents of /proc/meminfo > ? contents of /proc/mounts > ? contents of /proc/partitions > Attached except for mounts (not currently in the /proc directory, attached the fstab instead (hopefully helpful?) > ? RAID layout (hardware and/or software) The RAID-6 is the problem one > Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy > ------------------------------------------------------------------------------ > u0 RAID-1 OK - - - 3725.28 RiW ON > u1 RAID-6 OK - - 64K 70780.3 RiW ON > u2 SPARE OK - - - 3726.01 - OFF > > VPort Status Unit Size Type Phy Encl-Slot Model > ------------------------------------------------------------------------------ > p8 OK u0 3.63 TB SATA - /c0/e0/slt0 WDC WD4000FYYZ-01UL > p9 OK u1 3.63 TB SATA - /c0/e0/slt4 WDC WD4000FYYZ-01UL > p10 OK u1 3.63 TB SATA - /c0/e0/slt8 WDC WD4000FYYZ-01UL > p11 OK u1 3.63 TB SATA - /c0/e0/slt12 WDC WD4000FYYZ-01UL > p12 OK u1 3.63 TB SATA - /c0/e0/slt16 WDC WD4000FYYZ-01UL > p13 OK u1 3.63 TB SATA - /c0/e0/slt20 WDC WD4000FYYZ-01UL > p14 OK u0 3.63 TB SATA - /c0/e0/slt1 WDC WD4000FYYZ-01UL > p15 OK u1 3.63 TB SATA - /c0/e0/slt5 WDC WD4000FYYZ-01UL > p16 OK u1 3.63 TB SATA - /c0/e0/slt9 WDC WD4000FYYZ-01UL > p17 OK u1 3.63 TB SATA - /c0/e0/slt13 WDC WD4000FYYZ-01UL > p18 OK u1 3.63 TB SATA - /c0/e0/slt17 WDC WD4000FYYZ-01UL > p19 OK u1 3.63 TB SATA - /c0/e0/slt21 WDC WD4000FYYZ-01UL > p20 OK u1 3.63 TB SATA - /c0/e0/slt2 WDC WD4000FYYZ-01UL > p21 OK u1 3.63 TB SATA - /c0/e0/slt6 WDC WD4000FYYZ-01UL > p22 OK u1 3.63 TB SATA - /c0/e0/slt10 WDC WD4000FYYZ-01UL > p23 OK u1 3.63 TB SATA - /c0/e0/slt14 WDC WD4000FYYZ-01UL > p24 OK u1 3.63 TB SATA - /c0/e0/slt18 WDC WD4000FYYZ-01UL > p25 OK u1 3.63 TB SATA - /c0/e0/slt22 WDC WD4000FYYZ-01UL > p26 OK u1 3.63 TB SATA - /c0/e0/slt3 WDC WD4000FYYZ-01UL > p27 OK u1 3.63 TB SATA - /c0/e0/slt7 WDC WD4000FYYZ-01UL > p28 OK u1 3.63 TB SATA - /c0/e0/slt11 WDC WD4000FYYZ-01UL > p29 OK u1 3.63 TB SATA - /c0/e0/slt15 WDC WD4000FYYZ-01UL > p30 OK u1 3.63 TB SATA - /c0/e0/slt19 WDC WD4000FYYZ-01UL > p31 OK u2 3.63 TB SATA - /c0/e0/slt23 WDC WD4000FYYZ-01UL That's a 21 disk raid6, which seems like a high spindle count for a stripe geometry like raid6 to me. I guess it depends on the use case. Was this always the geometry of the array or was it grown over time? > ? LVM configuration > I don't *think* these are in an LVM.. I could be wrong. > ? type of disks you are using > Models included above in raid config. > ? write cache status of drives > ? size of BBWC and mode it is running in > ? xfs_info output on the filesystem in question > For the above three questions I'm not sure how to get the the cache status of the drives, or what the BBWC is? xfs_info won't currently run (I'm waiting on the drive to unmount) but I ran an xfs_check and an xfs_repair -n and no errors were shown. > ? dmesg output showing all error messages and stack traces > Then you need to describe your workload that is causing the problem, and a demonstration of the bad behaviour that is occurring. If it is a performance problem, then 30s - 1 minute samples of: > 1. iostat -x -d -m 5 > [root@ncb-sv-016 ~]# iostat -x -d -m 5 > Linux 2.6.32-358.23.2.el6.x86_64 (ncb-sv-016.ducom.edu) 09/15/2015 _x86_64_ (16 CPU) > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.29 3.61 5.78 3.58 0.10 0.03 28.27 0.05 5.19 2.39 2.24 > sdb 1.02 8.66 31.50 3.91 0.33 0.12 26.14 5.94 167.54 27.47 97.25 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 1.60 0.00 2.00 0.00 0.01 14.40 0.01 4.30 4.30 0.86 > sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 6.46 6332.75 1250.00 100.00 > It looks like not much write activity causes severe I/O latencies (on the order of seconds) and 100% device utilization. Without some of the details noted above, it's kind of hard to grasp at what's going wrong here beyond the fact that the storage just appears to be running really slow. Brian > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 3.60 0.00 7.00 0.00 0.04 12.11 0.02 0.60 1.77 1.24 > sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 6.28 6256.60 1000.00 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 0.00 0.00 0.40 0.00 0.00 8.00 0.00 42.50 12.00 0.48 > sdb 0.00 0.00 0.00 1.20 0.00 0.04 64.00 5.86 5846.33 833.33 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 0.60 0.00 0.60 0.00 0.00 16.00 0.01 12.67 12.67 0.76 > sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 6.86 5725.20 1000.00 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 > sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 6.06 5459.00 1000.00 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 4.00 0.00 1.60 0.00 0.02 26.00 0.01 6.75 6.50 1.04 > sdb 0.00 0.00 0.00 1.00 0.00 0.03 51.20 7.05 5670.40 1000.00 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 29.40 0.00 2.60 0.00 0.12 98.46 0.01 4.54 4.08 1.06 > sdb 0.00 0.00 0.00 1.20 0.00 0.03 53.33 6.54 7428.50 833.33 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 9.60 0.00 15.80 0.00 0.10 12.86 0.57 35.82 3.37 5.32 > sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 6.30 5889.20 1000.00 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 7.80 0.00 12.80 0.00 0.08 12.38 0.74 58.09 15.06 19.28 > sdb 0.00 0.00 0.00 1.20 0.00 0.04 64.00 6.49 6140.83 833.33 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 4.80 0.00 3.20 0.00 0.03 20.00 0.01 0.06 3.12 1.00 > sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 5.10 6489.25 1250.00 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 0.00 0.00 0.20 0.00 0.00 8.00 0.02 152.00 103.00 2.06 > sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.00 6.75 5791.00 1000.20 100.02 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 61.20 0.00 11.80 0.00 0.29 49.49 0.01 0.88 0.69 0.82 > sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 6.37 5569.71 714.14 99.98 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 0.40 0.00 0.60 0.00 0.00 13.33 0.01 24.33 24.33 1.46 > sdb 0.00 0.00 0.00 1.60 0.00 0.05 64.00 5.77 5162.00 625.12 100.02 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 0.00 0.00 0.40 0.00 0.00 8.00 0.00 3.00 1.50 0.06 > sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 5.08 3428.50 1250.00 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 1.60 0.00 0.80 0.00 0.01 24.00 0.01 10.75 10.75 0.86 > sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 5.86 3932.14 714.29 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 2.00 0.00 4.80 0.00 0.03 11.33 0.01 2.21 2.08 1.00 > sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 5.60 3992.71 714.29 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 5.00 0.00 18.20 0.00 0.09 10.20 0.02 1.13 0.03 0.06 > sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 5.44 4208.86 714.29 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 1.40 0.00 0.60 0.00 0.01 26.67 0.02 27.00 27.00 1.62 > sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 5.22 4325.43 714.29 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 0.60 0.00 0.40 0.00 0.00 20.00 0.01 15.50 15.50 0.62 > sdb 0.00 0.00 0.00 1.60 0.00 0.05 64.00 5.06 4022.75 625.00 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 > sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 5.08 3495.50 1250.00 100.00 > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > sda 0.00 1.60 0.00 1.60 0.00 0.01 12.00 0.07 42.88 42.50 6.80 > sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.00 5.82 3894.71 714.29 100.00 > 2. vmstat 5 > [root@ncb-sv-016 ~]# vmstat 5 > procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- > r b swpd free buff cache si so bi bo in cs us sy id wa st > 0 0 0 126125768 19456 405396 0 0 28 10 421 150 0 0 99 0 0 > 0 0 0 126125520 19464 405396 0 0 0 34 6679 13281 0 0 100 0 0 > 1 0 0 126124896 19472 405392 0 0 0 38 6718 13310 0 0 100 0 0 > 0 0 0 126125312 19472 405400 0 0 0 74 6658 13256 0 0 100 0 0 > 0 0 0 126125440 19480 405392 0 0 0 60 6664 13291 0 0 100 0 0 > 2 0 0 126125440 19480 405400 0 0 0 26 6660 13272 0 0 100 0 0 > 0 0 0 126125680 19488 405400 0 0 0 30 6659 13282 0 0 100 0 0 > 2 0 0 126125696 19496 405396 0 0 0 117 6686 13298 0 0 100 0 0 > 1 0 0 126125568 19496 405400 0 0 0 33 6661 13287 0 0 100 0 0 > 0 0 0 126125816 19504 405400 0 0 0 30 6663 13271 0 0 100 0 0 > 1 0 0 126125816 19504 405400 0 0 0 27 6659 13285 0 0 100 0 0 > 0 0 0 126125696 19512 405400 0 0 0 75 6670 13269 0 0 100 0 0 > 0 0 0 126125816 19520 405400 0 0 0 55 6671 13286 0 0 100 0 0 > 2 0 0 126125696 19528 405396 0 0 0 34 6670 13284 0 0 100 0 0 > 0 0 0 126125272 19528 405400 0 0 0 26 6700 13298 0 0 100 0 0 > 0 0 0 126125408 19536 405400 0 0 0 61 6660 13277 0 0 100 0 0 > 1 0 0 126125536 19544 405392 0 0 0 98 6677 13281 0 0 100 0 0 > can give us insight into the IO and memory utilisation of your machine at the time of the problem. > If the filesystem is hanging, then capture the output of the dmesg command after running: > # echo w > /proc/sysrq-trigger > # dmesg > will tell us all the hung processes in the machine, often pointing us directly to the cause of the hang. > Attached > > Thanks! > > Josh Earl, MS > Research Instructor > Drexel College of Medicine > Center for Advanced Microbial Processing (CAMP) > Institute of Molecular Medicine and Infectious Disease > (215) 762-8133 > > ________________________________ > > This email and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this email communication by others is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and delete all copies. Thank you for your cooperation. > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From prvs=7702a5136c=joshua.earl@drexelmed.edu Thu Sep 17 16:37:21 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 23F807F4E for ; Thu, 17 Sep 2015 16:37:21 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 10DD7304059 for ; Thu, 17 Sep 2015 14:37:20 -0700 (PDT) X-ASG-Debug-ID: 1442525836-04cb6c355b19f3f0001-NocioJ Received: from pp-mta1.drexelmed.edu ([198.17.30.172]) by cuda.sgi.com with ESMTP id ObfKis6ap0g8DZKG (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Sep 2015 14:37:17 -0700 (PDT) X-Barracuda-Envelope-From: prvs=7702a5136c=joshua.earl@drexelmed.edu X-Barracuda-Apparent-Source-IP: 198.17.30.172 Received: from pps.filterd (pp-mta1.drexelmed.edu [127.0.0.1]) by pp-mta1.drexelmed.edu (8.15.0.59/8.14.7) with SMTP id t8HLYXp6025769; Thu, 17 Sep 2015 17:37:15 -0400 Received: from ncb-sv-103.ducom.edu ([10.16.20.136]) by pp-mta1.drexelmed.edu with ESMTP id 1x05bfr153-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Sep 2015 17:37:15 -0400 Received: from NCB-SV-117.DUCOM.edu ([fe80::6519:3ee7:4c6f:f2df]) by NCB-SV-103.DUCOM.edu ([::1]) with mapi id 14.03.0248.002; Thu, 17 Sep 2015 17:37:09 -0400 From: "Earl, Joshua P" To: Brian Foster CC: "xfs@oss.sgi.com" Subject: RE: xfsxyncd in 'D' state Thread-Topic: xfsxyncd in 'D' state X-ASG-Orig-Subj: RE: xfsxyncd in 'D' state Thread-Index: AdDwn8phEmHFJRKXQuG/nBBkF7izjQAx6magAA4ETIAABCFVMA== Date: Thu, 17 Sep 2015 21:37:09 +0000 Message-ID: <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DFC@NCB-SV-117.DUCOM.edu> References: <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2CA0@NCB-SV-117.DUCOM.edu> <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DB8@NCB-SV-117.DUCOM.edu> <20150917192102.GA5342@bfoster.bfoster> In-Reply-To: <20150917192102.GA5342@bfoster.bfoster> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.15.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-09-17_07:2015-09-17,2015-09-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=ducom_outbound_notspam policy=ducom_outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1509170268 X-Barracuda-Connect: UNKNOWN[198.17.30.172] X-Barracuda-Start-Time: 1442525836 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=RDNS_NONE, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22649 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS Hi Brian, Sorry about the top posting thing... I'm not sure how to control that, is m= y replying somehow messing with that? With good news, I seem to have figured out what was going on. I had a cron= job which would run every 15 minutes which changed the permissions in a di= rectory:=20 chmod -R g+rwx /data/shared/homes/bjanto/* chmod -R g+rwx /data/shared/homes/lanastor/* chgrp -hR ilmn /data/nextseq/* chgrp -hR lab /data/shared/homes/* Where /data was a directory in the mounted xfs file system. The script its= elf would complete in under a minute, and I thought everything was fine. H= owever, this would trigger the xfssyncd process to go into the 'D' state, a= nd no writing was allowed until that had completed whatever it was doing. = Apparently this would take longer than 15 minutes. As long as cron was run= ning the drive would never become available for writing. I've solved the problem by just using a setguid on the directories in quest= ion (so anything in those directories get the correct group on creation), s= o no cron job is needed. But is this expected behavior? Should I change a= ny settings on the mount? I can definitely compress the files if need be, they were the /proc/meminfo= etc. outputs requested in the faq. I'm not sure at this point if they are= required. ~josh -----Original Message----- From: Brian Foster [mailto:bfoster@redhat.com]=20 Sent: Thursday, September 17, 2015 3:21 PM To: Earl, Joshua P Cc: xfs@oss.sgi.com Subject: Re: xfsxyncd in 'D' state On Thu, Sep 17, 2015 at 04:45:03PM +0000, Earl, Joshua P wrote: > Anyone have any ideas on this? Is this the right mailing list? It looks= like the email I sent with attachments didn't go through, should I copy an= d paste the outputs into an email? We are pretty crippled without the use = of this drive, and it took several weeks to figure out that it was this pro= cess going into uninterruptible sleep that was the 'cause'. I don't know = what causes this however, I'm not sure how to track that down. There doesn= 't seem to be anything accessing the drive as far as processes go... but on= a clean reboot within about 5 minutes this pops up: >=20 Were the attachments large? You could try to compress them or perhaps host = them somewhere and post a link. (Also, please try not to top-post). > root 2216 0.0 0.0 0 0 ? D 12:24 0:00 [xfssync= d/sdb1] >=20 > And we are dead in the water until it lets go, which is currently hours l= ater. When we first experienced this problem it would only take a few minu= tes to get back to a writable state. >=20 That is responsible for writing out metadata and things on older kernels. W= hen was this problem "first experienced" as opposed to the current state? D= id performance drop off slowly or rapidly? > Any help would be greatly appreciated! >=20 > Thanks, > ~josh >=20 > From: xfs-bounces@oss.sgi.com [mailto:xfs-bounces@oss.sgi.com] On=20 > Behalf Of Earl, Joshua P > Sent: Wednesday, September 16, 2015 12:50 PM > To: xfs@oss.sgi.com > Subject: RE: xfsxyncd in 'D' state >=20 > I was also able to get the xfs_info after finally getting the drive remou= nted: >=20 > [root@ncb-sv-016 ~]# xfs_info /home > meta-data=3D/dev/sdb1 isize=3D256 agcount=3D70, agsize=3D= 268435455 blks > =3D sectsz=3D512 attr=3D2, projid32bit= =3D0 > data =3D bsize=3D4096 blocks=3D18554637056, i= maxpct=3D1 > =3D sunit=3D0 swidth=3D0 blks > naming =3Dversion 2 bsize=3D4096 ascii-ci=3D0 > log =3Dinternal bsize=3D4096 blocks=3D521728, versio= n=3D2 > =3D sectsz=3D512 sunit=3D0 blks, lazy-co= unt=3D1 > realtime =3Dnone extsz=3D4096 blocks=3D0, rtextents= =3D0 >=20 So this is a 70TB fs with what looks like mostly default settings. Note tha= t no stripe unit/width are set, fwiw. I don't see current fs utilization (df, df -i) or mount options reported an= ywhere. Can you provide that information? > From: Earl, Joshua P > Sent: Tuesday, September 15, 2015 1:53 PM > To: 'xfs@oss.sgi.com' > > Subject: xfsxyncd in 'D' state >=20 > Hello, I hope I'm writing to the correct list. I've recently run into a = problem, which has me stumped. I'm running a cluster which shares an xfs f= ilesystem to 10 nodes via nfs. This has been working for almost two years.= However, I've been running into trouble with the drive where if anything = tries to write to it at certain times it will simply hang, and every proces= s trying to write will also hang and go into the 'D' state. For example (j= ust editing a text file with emacs): >=20 You haven't really described the workload either. If not much is going on f= rom the server itself, what are those 10 nfs clients doing when this occurs= ? In general, the more information you provide about the environment and wo= rkload, the more likely other folks here who might be more familiar with NF= S and/or hwraid might chime in with suggestions. Not being an NFS expert myself, I'd probably unexport the filesystem, mount= it locally and run some tests there to see what seems to induce this behav= ior, if anything. For example, what happens if existing files are read or d= irectories listed? In terms of writes, does a sequential file writer have r= easonable performance (dd)? Can you allocate inodes (e.g., create a temp di= r somewhere and run a 'touch' loop to create new files) without any issues? You could also try to untar a tarball, run a sho= rt fio/fsstress/whatever workload, etc. If nothing seems to trigger it locally, I'd start to look at adding back th= e clients to try identify contributors. > [root@ncb-sv-016 ~]# ps aux|grep D > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 2216 0.0 0.0 0 0 ? D 11:28 0:00 [xfssync= d/sdb1] > archana 7708 0.0 0.0 249700 13352 pts/0 D 11:35 0:00 emacs th= ings > root 11453 0.0 0.0 103312 868 pts/1 S+ 12:47 0:00 grep D >=20 What's the stack trace for the emacs process when this occurs? I suspect it= would eventually get dumped to the logs as a stalled task, but /proc/= /stack should show it as well. > This will remain like this for hours. Can't remount/unmount drive=20 > (sends the unmount command into 'D' state) >=20 > I have no idea what's going on or how to fix it, but I'm hoping you guys = might be able to point me in the right direction. Here is the info that's r= equested in the FAQ: > ? kernel version (uname -a) > Linux ncb-sv-016.ducom.edu 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct=20 > 16 18:37:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ? xfsprogs=20 > version (xfs_repair -V) xfs_repair version 3.1.1 ? number of CPUs > 16 > ? contents of /proc/meminfo > ? contents of /proc/mounts > ? contents of /proc/partitions > Attached except for mounts (not currently in the /proc directory,=20 > attached the fstab instead (hopefully helpful?) ? RAID layout (hardware = and/or software) The RAID-6 is the problem one > Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache A= Vrfy > -------------------------------------------------------------------------= ----- > u0 RAID-1 OK - - - 3725.28 RiW O= N > u1 RAID-6 OK - - 64K 70780.3 RiW O= N > u2 SPARE OK - - - 3726.01 - O= FF >=20 > VPort Status Unit Size Type Phy Encl-Slot Model > -------------------------------------------------------------------------= ----- > p8 OK u0 3.63 TB SATA - /c0/e0/slt0 WDC WD4000FYYZ= -01UL > p9 OK u1 3.63 TB SATA - /c0/e0/slt4 WDC WD4000FYYZ= -01UL > p10 OK u1 3.63 TB SATA - /c0/e0/slt8 WDC WD4000FYYZ= -01UL > p11 OK u1 3.63 TB SATA - /c0/e0/slt12 WDC WD4000FYYZ= -01UL > p12 OK u1 3.63 TB SATA - /c0/e0/slt16 WDC WD4000FYYZ= -01UL > p13 OK u1 3.63 TB SATA - /c0/e0/slt20 WDC WD4000FYYZ= -01UL > p14 OK u0 3.63 TB SATA - /c0/e0/slt1 WDC WD4000FYYZ= -01UL > p15 OK u1 3.63 TB SATA - /c0/e0/slt5 WDC WD4000FYYZ= -01UL > p16 OK u1 3.63 TB SATA - /c0/e0/slt9 WDC WD4000FYYZ= -01UL > p17 OK u1 3.63 TB SATA - /c0/e0/slt13 WDC WD4000FYYZ= -01UL > p18 OK u1 3.63 TB SATA - /c0/e0/slt17 WDC WD4000FYYZ= -01UL > p19 OK u1 3.63 TB SATA - /c0/e0/slt21 WDC WD4000FYYZ= -01UL > p20 OK u1 3.63 TB SATA - /c0/e0/slt2 WDC WD4000FYYZ= -01UL > p21 OK u1 3.63 TB SATA - /c0/e0/slt6 WDC WD4000FYYZ= -01UL > p22 OK u1 3.63 TB SATA - /c0/e0/slt10 WDC WD4000FYYZ= -01UL > p23 OK u1 3.63 TB SATA - /c0/e0/slt14 WDC WD4000FYYZ= -01UL > p24 OK u1 3.63 TB SATA - /c0/e0/slt18 WDC WD4000FYYZ= -01UL > p25 OK u1 3.63 TB SATA - /c0/e0/slt22 WDC WD4000FYYZ= -01UL > p26 OK u1 3.63 TB SATA - /c0/e0/slt3 WDC WD4000FYYZ= -01UL > p27 OK u1 3.63 TB SATA - /c0/e0/slt7 WDC WD4000FYYZ= -01UL > p28 OK u1 3.63 TB SATA - /c0/e0/slt11 WDC WD4000FYYZ= -01UL > p29 OK u1 3.63 TB SATA - /c0/e0/slt15 WDC WD4000FYYZ= -01UL > p30 OK u1 3.63 TB SATA - /c0/e0/slt19 WDC WD4000FYYZ= -01UL > p31 OK u2 3.63 TB SATA - /c0/e0/slt23 WDC WD4000FYYZ= -01UL That's a 21 disk raid6, which seems like a high spindle count for a stripe = geometry like raid6 to me. I guess it depends on the use case. Was this always the geometry of the array or was it grown over time? > ? LVM configuration > I don't *think* these are in an LVM.. I could be wrong. > ? type of disks you are using > Models included above in raid config. > ? write cache status of drives > ? size of BBWC and mode it is running in ? xfs_info output on the=20 > filesystem in question For the above three questions I'm not sure how=20 > to get the the cache status of the drives, or what the BBWC is? xfs_info = won't currently run (I'm waiting on the drive to unmount) but I ran an xfs_= check and an xfs_repair -n and no errors were shown. > ? dmesg output showing all error messages and stack traces Then you=20 > need to describe your workload that is causing the problem, and a demonst= ration of the bad behaviour that is occurring. If it is a performance probl= em, then 30s - 1 minute samples of: > 1. iostat -x -d -m 5 > [root@ncb-sv-016 ~]# iostat -x -d -m 5 > Linux 2.6.32-358.23.2.el6.x86_64 (ncb-sv-016.ducom.edu) 09/15/2015 = _x86_64_ (16 CPU) >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.29 3.61 5.78 3.58 0.10 0.03 28.2= 7 0.05 5.19 2.39 2.24 > sdb 1.02 8.66 31.50 3.91 0.33 0.12 26.1= 4 5.94 167.54 27.47 97.25 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 1.60 0.00 2.00 0.00 0.01 14.4= 0 0.01 4.30 4.30 0.86 > sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.0= 0 6.46 6332.75 1250.00 100.00 >=20 It looks like not much write activity causes severe I/O latencies (on the o= rder of seconds) and 100% device utilization. Without some of the details n= oted above, it's kind of hard to grasp at what's going wrong here beyond th= e fact that the storage just appears to be running really slow. Brian > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 3.60 0.00 7.00 0.00 0.04 12.1= 1 0.02 0.60 1.77 1.24 > sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.0= 0 6.28 6256.60 1000.00 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 0.00 0.00 0.40 0.00 0.00 8.0= 0 0.00 42.50 12.00 0.48 > sdb 0.00 0.00 0.00 1.20 0.00 0.04 64.0= 0 5.86 5846.33 833.33 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 0.60 0.00 0.60 0.00 0.00 16.0= 0 0.01 12.67 12.67 0.76 > sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.0= 0 6.86 5725.20 1000.00 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 0.00 0.00 0.00 0.00 0.00 0.0= 0 0.00 0.00 0.00 0.00 > sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.0= 0 6.06 5459.00 1000.00 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 4.00 0.00 1.60 0.00 0.02 26.0= 0 0.01 6.75 6.50 1.04 > sdb 0.00 0.00 0.00 1.00 0.00 0.03 51.2= 0 7.05 5670.40 1000.00 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 29.40 0.00 2.60 0.00 0.12 98.4= 6 0.01 4.54 4.08 1.06 > sdb 0.00 0.00 0.00 1.20 0.00 0.03 53.3= 3 6.54 7428.50 833.33 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 9.60 0.00 15.80 0.00 0.10 12.8= 6 0.57 35.82 3.37 5.32 > sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.0= 0 6.30 5889.20 1000.00 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 7.80 0.00 12.80 0.00 0.08 12.3= 8 0.74 58.09 15.06 19.28 > sdb 0.00 0.00 0.00 1.20 0.00 0.04 64.0= 0 6.49 6140.83 833.33 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 4.80 0.00 3.20 0.00 0.03 20.0= 0 0.01 0.06 3.12 1.00 > sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.0= 0 5.10 6489.25 1250.00 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 0.00 0.00 0.20 0.00 0.00 8.0= 0 0.02 152.00 103.00 2.06 > sdb 0.00 0.00 0.00 1.00 0.00 0.03 64.0= 0 6.75 5791.00 1000.20 100.02 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 61.20 0.00 11.80 0.00 0.29 49.4= 9 0.01 0.88 0.69 0.82 > sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.0= 0 6.37 5569.71 714.14 99.98 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 0.40 0.00 0.60 0.00 0.00 13.3= 3 0.01 24.33 24.33 1.46 > sdb 0.00 0.00 0.00 1.60 0.00 0.05 64.0= 0 5.77 5162.00 625.12 100.02 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 0.00 0.00 0.40 0.00 0.00 8.0= 0 0.00 3.00 1.50 0.06 > sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.0= 0 5.08 3428.50 1250.00 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 1.60 0.00 0.80 0.00 0.01 24.0= 0 0.01 10.75 10.75 0.86 > sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.0= 0 5.86 3932.14 714.29 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 2.00 0.00 4.80 0.00 0.03 11.3= 3 0.01 2.21 2.08 1.00 > sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.0= 0 5.60 3992.71 714.29 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 5.00 0.00 18.20 0.00 0.09 10.2= 0 0.02 1.13 0.03 0.06 > sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.0= 0 5.44 4208.86 714.29 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 1.40 0.00 0.60 0.00 0.01 26.6= 7 0.02 27.00 27.00 1.62 > sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.0= 0 5.22 4325.43 714.29 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 0.60 0.00 0.40 0.00 0.00 20.0= 0 0.01 15.50 15.50 0.62 > sdb 0.00 0.00 0.00 1.60 0.00 0.05 64.0= 0 5.06 4022.75 625.00 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 0.00 0.00 0.00 0.00 0.00 0.0= 0 0.00 0.00 0.00 0.00 > sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.0= 0 5.08 3495.50 1250.00 100.00 >=20 > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-s= z avgqu-sz await svctm %util > sda 0.00 1.60 0.00 1.60 0.00 0.01 12.0= 0 0.07 42.88 42.50 6.80 > sdb 0.00 0.00 0.00 1.40 0.00 0.04 64.0= 0 5.82 3894.71 714.29 100.00 > 2. vmstat 5 > [root@ncb-sv-016 ~]# vmstat 5 > procs -----------memory---------- ---swap-- -----io---- --system-- -----c= pu----- > r b swpd free buff cache si so bi bo in cs us sy id= wa st > 0 0 0 126125768 19456 405396 0 0 28 10 421 150 0 0= 99 0 0 > 0 0 0 126125520 19464 405396 0 0 0 34 6679 13281 0 = 0 100 0 0 > 1 0 0 126124896 19472 405392 0 0 0 38 6718 13310 0 = 0 100 0 0 > 0 0 0 126125312 19472 405400 0 0 0 74 6658 13256 0 = 0 100 0 0 > 0 0 0 126125440 19480 405392 0 0 0 60 6664 13291 0 = 0 100 0 0 > 2 0 0 126125440 19480 405400 0 0 0 26 6660 13272 0 = 0 100 0 0 > 0 0 0 126125680 19488 405400 0 0 0 30 6659 13282 0 = 0 100 0 0 > 2 0 0 126125696 19496 405396 0 0 0 117 6686 13298 0 = 0 100 0 0 > 1 0 0 126125568 19496 405400 0 0 0 33 6661 13287 0 = 0 100 0 0 > 0 0 0 126125816 19504 405400 0 0 0 30 6663 13271 0 = 0 100 0 0 > 1 0 0 126125816 19504 405400 0 0 0 27 6659 13285 0 = 0 100 0 0 > 0 0 0 126125696 19512 405400 0 0 0 75 6670 13269 0 = 0 100 0 0 > 0 0 0 126125816 19520 405400 0 0 0 55 6671 13286 0 = 0 100 0 0 > 2 0 0 126125696 19528 405396 0 0 0 34 6670 13284 0 = 0 100 0 0 > 0 0 0 126125272 19528 405400 0 0 0 26 6700 13298 0 = 0 100 0 0 > 0 0 0 126125408 19536 405400 0 0 0 61 6660 13277 0 = 0 100 0 0 > 1 0 0 126125536 19544 405392 0 0 0 98 6677 13281 0 = 0 100 0 0 > can give us insight into the IO and memory utilisation of your machine at= the time of the problem. > If the filesystem is hanging, then capture the output of the dmesg comman= d after running: > # echo w > /proc/sysrq-trigger > # dmesg > will tell us all the hung processes in the machine, often pointing us dir= ectly to the cause of the hang. > Attached >=20 > Thanks! >=20 > Josh Earl, MS > Research Instructor > Drexel College of Medicine > Center for Advanced Microbial Processing (CAMP) Institute of Molecular=20 > Medicine and Infectious Disease > (215) 762-8133 >=20 > ________________________________ >=20 > This email and any accompanying attachments are confidential. The informa= tion is intended solely for the use of the individual to whom it is address= ed. Any review, disclosure, copying, distribution, or use of this email com= munication by others is strictly prohibited. If you are not the intended re= cipient, please notify the sender immediately and delete all copies. Thank = you for your cooperation. > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__oss.sgi.com_mailma > n_listinfo_xfs&d=3DAwIBAg&c=3D3kkgRanvEDK8hL9DynGJVVH69jkBMvrwECTgfOmvv0E= &r=3DHiolWjLw4P5HxQGEvzKcfCwD3EYUiDpGfeAhgr7hw3M&m=3D0SleLEBijJl2B8Pk6Lsu8E= CDCQDIKASaEIYUKaWRyAo&s=3DaAZVjeECRjIdMS-OkbTo3YNdphVwt74N-HK5ie2KBbc&e=3D From team32@songqq.com Thu Sep 17 17:36:25 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2B0597F4E for ; Thu, 17 Sep 2015 17:36:25 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id F234C304066 for ; Thu, 17 Sep 2015 15:36:19 -0700 (PDT) X-ASG-Debug-ID: 1442529374-04bdf04db41bb6d0001-NocioJ Received: from songqq.com ([103.240.183.157]) by cuda.sgi.com with SMTP id xIfQLLMRH4yz52xw for ; Thu, 17 Sep 2015 15:36:15 -0700 (PDT) X-Barracuda-Envelope-From: team32@songqq.com X-Barracuda-Apparent-Source-IP: 103.240.183.157 Received: from [123.88.220.180]; Fri, 18 Sep 2015 06:33:18 +0800 Date: Fri, 18 Sep 2015 06:36:15 +0800 From: "team32" Reply-To: mcliziming@163.com To: "xfs" Subject: =?GB2312?B?v827p7j41ve2r7XEyMu/qreio6zW+sT6u6+xu7avzqrW97avx+HLyb+qt6K6?= =?GB2312?B?o83iv827p6Gj?= Message-ID: <201509180636156876672@songqq.com> X-ASG-Orig-Subj: =?GB2312?B?v827p7j41ve2r7XEyMu/qreio6zW+sT6u6+xu7avzqrW97avx+HLyb+qt6K6?= =?GB2312?B?o83iv827p6Gj?= X-Mailer: Foxmail 6, 10, 201, 20 [cn] MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 X-Barracuda-Connect: UNKNOWN[103.240.183.157] X-Barracuda-Start-Time: 1442529374 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.10 X-Barracuda-Spam-Status: No, SCORE=0.10 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=RDNS_NONE, UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22653 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS zeLDs7/Nu6fL0cv30+u/qreiz7XNs6Os1ve2r8q9zeLDs7/Nu6e/qreitdrSu8HstbzGt8XGo7oN CjGhor/Nu6fL0cv3srvJ6LnYvPy0ys/e1sajrDE4uPbIq8fyzajTw9L9x+bS1LywMjAwtuC49rn6 vNLPwjcwMLbguPbH+NPy0NTL0cv30v3H5qOstuDW2NDFz6K5/cLLuabE3KOszqrE+rXEv827p7/N u6fQxc+iy9HL99Ta1srT68G/yc+xo7zdu6S6vaOsw7/M7L/Ju/HIoaG+yc/N8qG/v827p9DFz6IN CjKhosTa1sPTyrz+06rP+sSjv+mjrL/JtuDVy7rFoaK24Nb3zOKhorbgxKOw5aGi19S2r8fQu7tp cLeiy83Tyrz+o6yx3MPi08q8/rG7t/7O8cb3uenA4M6qwKy7+NPKvP6jrNPQ0KfM4bjf08q8/rXE tb2078LKo6zDv8zsv8m3osvNob7Jz83yob/Tyrz+DQozoaLSu7bU0rvXqMr0v823/s6qxPrI7bz+ tcTKudPDzOG5qbPkt9a1xLGj1c+jrL/Nt/7Iy9Sxsru99srsz6TI7bz+o6y7uc6qxPrM4bmpuPfW 1r+qt6LL0cv3vLzHydLUvLDQodPv1ta3rdLrtci1yKOsv8nS1M6qxPrU2r/Nu6e/qreiyc/M4bmp x9DKtb2o0ukNCs/qx+nH6ytRLS1Ro7oyMDM2MDE5NTE51rG526Gi1ebKtdTaz9/R3cq+yO28/tCn ufs= From david@fromorbit.com Thu Sep 17 21:08:17 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id EF0697F4E for ; Thu, 17 Sep 2015 21:08:16 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id B0D258F8049 for ; Thu, 17 Sep 2015 19:08:13 -0700 (PDT) X-ASG-Debug-ID: 1442542086-04bdf04db61bfcc0001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id HCJGEDxVCcGvvuxl for ; Thu, 17 Sep 2015 19:08:07 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2B8EgBXcftVPOV8LHldDoMVgT2GWaJQAQEBAQEBBopskR4EAgKBRU0BAQEBAQEHAQEBAUE/hCMBAQEDATocIwULCAMYCSUPBSUDBxoTGogMB8s8AQEBBwIgGYYThUSFDQeELAWVYY0CgVGENoMhjgmDbYJ0HIEWUCwziioBAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 18 Sep 2015 11:33:52 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Zcl1j-0006Rh-UE; Fri, 18 Sep 2015 12:03:51 +1000 Date: Fri, 18 Sep 2015 12:03:51 +1000 From: Dave Chinner To: "Earl, Joshua P" Cc: Brian Foster , "xfs@oss.sgi.com" Subject: Re: xfsxyncd in 'D' state Message-ID: <20150918020351.GS3902@dastard> X-ASG-Orig-Subj: Re: xfsxyncd in 'D' state References: <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2CA0@NCB-SV-117.DUCOM.edu> <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DB8@NCB-SV-117.DUCOM.edu> <20150917192102.GA5342@bfoster.bfoster> <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DFC@NCB-SV-117.DUCOM.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DFC@NCB-SV-117.DUCOM.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442542086 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22658 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header On Thu, Sep 17, 2015 at 09:37:09PM +0000, Earl, Joshua P wrote: > Hi Brian, > > Sorry about the top posting thing... I'm not sure how to control > that, is my replying somehow messing with that? when everthing is backwards to read the thread it makes it hard And please wrap your text at 72 columns. > With good news, I seem to have figured out what was going on. I > had a cron job which would run every 15 minutes which changed the > permissions in a directory: > chmod -R g+rwx /data/shared/homes/bjanto/* > chmod -R g+rwx /data/shared/homes/lanastor/* > chgrp -hR ilmn /data/nextseq/* > chgrp -hR lab /data/shared/homes/* So you are modifying a large amount of metadata every 15 minutes, and then you have a problem with your 22-disk wide RAID6 array when the metadata gets written back. metadata writeback is, by the nature of metadata in a filesystem, done in small, isolated IOs that cause large RAID5/6 arrays to do an stripe-wide RMW cycle on every IO. > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > > sda 0.29 3.61 5.78 3.58 0.10 0.03 28.27 0.05 5.19 2.39 2.24 > > sdb 1.02 8.66 31.50 3.91 0.33 0.12 26.14 5.94 167.54 27.47 97.25 > > > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util > > sda 0.00 1.60 0.00 2.00 0.00 0.01 14.40 0.01 4.30 4.30 0.86 > > sdb 0.00 0.00 0.00 0.80 0.00 0.03 64.00 6.46 6332.75 1250.00 100.00 That's pretty clear that your hardware raid array is taking over a second per IO that requires a RMW cycle. So not a filesystem problem... Cheers, Dave. -- Dave Chinner david@fromorbit.com From xuw2015@gmail.com Fri Sep 18 06:06:46 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,T_DKIM_INVALID autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 6EB537F4E for ; Fri, 18 Sep 2015 06:06:46 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 07854AC003 for ; Fri, 18 Sep 2015 04:06:45 -0700 (PDT) X-ASG-Debug-ID: 1442574400-04bdf04db51cb970001-NocioJ Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by cuda.sgi.com with ESMTP id QEMVQBAosMBqkQGR (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 18 Sep 2015 04:06:40 -0700 (PDT) X-Barracuda-Envelope-From: xuw2015@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.160.169 Received: by ykdu9 with SMTP id u9so43167660ykd.2 for ; Fri, 18 Sep 2015 04:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=hesR3G3QFjskyeL6KCMPWbdV7iEWfKuUAWASjSkNSbk=; b=z19xzmuHkydmGV4LLgcYQ7W9PhFuwNq7w3xK5dz853VBUYmjudqfZ+7xYgpwEAOa52 a2VYFpBBd1EHsGbJTJ1E6uDyufhiTRDn2+EDg+3UwnE6zVyblouPfijDH6SiQHW5fExV vivwckGDCxaTtW9NCs4cAb3KJmWDXrmcGmu1bXUc4sVdftVkQoyYt1KAF+izL4sWHu2T VB6S/fwAEasAeG0Ke/JoVuIukvRa/BZvAweXkwPePR/1rNjTd0yfDCs/zn254rOAAixX fx6PW7avxyQYwh03Lxu660mCNL7MSc+frrx3jYg+hvvm0mj5WXSi+zS2TeAqPqvQfI1H ggYw== MIME-Version: 1.0 X-Received: by 10.170.97.66 with SMTP id o63mr3975353yka.55.1442574399942; Fri, 18 Sep 2015 04:06:39 -0700 (PDT) Received: by 10.13.224.133 with HTTP; Fri, 18 Sep 2015 04:06:39 -0700 (PDT) Date: Fri, 18 Sep 2015 19:06:39 +0800 Message-ID: Subject: How Can I Get Writeback Status When Running fs_mark From: George Wang X-ASG-Orig-Subj: How Can I Get Writeback Status When Running fs_mark To: Dave Chinner Cc: xfs@oss.sgi.com Content-Type: text/plain; charset=UTF-8 X-Barracuda-Connect: mail-yk0-f169.google.com[209.85.160.169] X-Barracuda-Start-Time: 1442574400 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22667 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 Hi, Dave, I read the mail you post for "fs-writeback: drop wb->list_lock during blk_finish_plug()", and I adore you very much. I'm very curious that how you get the writeback status when running fs_mark. I will appreciate very much if you can share the way you get writeback status and iops, etc. And maybe people in community can use this way to do the same tests as you. The following is a part copy of the test result you got: $ ~/tests/fsmark-10-4-test-xfs.sh meta-data=/dev/vdc isize=512 agcount=500, agsize=268435455 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=0 data = bsize=4096 blocks=134217727500, imaxpct=1 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=131072, version=2 = sectsz=512 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 # ./fs_mark -D 10000 -S0 -n 10000 -s 4096 -L 120 -d /mnt/scratch/0 -d /mnt/scratch/1 -d /mnt/scratch/2 -d /mnt/scratch/3 -d /mnt/scratch/4 -d /mnt/scratch/5 -d /mnt/scratch/6 -d /mnt/scratch/7 # Version 3.3, 8 thread(s) starting at Thu Sep 17 08:08:36 2015 # Sync method: NO SYNC: Test does not issue sync() or fsync() calls. # Directories: Time based hash between directories across 10000 subdirectories with 180 seconds per subdirectory. # File names: 40 bytes long, (16 initial bytes of time stamp with 24 random bytes at end of name) # Files info: size 4096 bytes, written with an IO size of 16384 bytes per write # App overhead is time in microseconds spent in the test not doing file writing related system calls. FSUse% Count Size Files/sec App Overhead 0 80000 4096 106938.0 543310 0 160000 4096 102922.7 476362 0 240000 4096 107182.9 538206 0 320000 4096 107871.7 619821 0 400000 4096 99255.6 622021 0 480000 4096 103217.8 609943 0 560000 4096 96544.2 640988 0 640000 4096 100347.3 676237 0 720000 4096 87534.8 483495 0 800000 4096 72577.5 2556920 0 880000 4096 97569.0 646996 0 960000 4096 80147.0 515679 0 1040000 4096 100394.2 816979 0 1120000 4096 91466.5 739009 0 1200000 4096 85868.1 977506 0 1280000 4096 89691.5 715207 0 1360000 4096 52547.5 712810 0 1440000 4096 47999.1 685282 0 1520000 4096 47894.3 697261 0 1600000 4096 47549.4 789977 0 1680000 4096 40029.2 677885 0 1760000 4096 16637.4 12804557 0 1840000 4096 16883.6 24295975 thanks George From yizhoumenyeyahoschuyinus@wo.cn Fri Sep 18 07:51:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 3AAED7F4E for ; Fri, 18 Sep 2015 07:51:48 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id C36ACAC002 for ; Fri, 18 Sep 2015 05:51:43 -0700 (PDT) X-ASG-Debug-ID: 1442580699-04bdf04db31ce3a0001-NocioJ Received: from wo.cn ([61.141.183.114]) by cuda.sgi.com with ESMTP id Ob5lO0pecaozWBZQ for ; Fri, 18 Sep 2015 05:51:40 -0700 (PDT) X-Barracuda-Envelope-From: yizhoumenyeyahoschuyinus@wo.cn X-Barracuda-Apparent-Source-IP: 61.141.183.114 From: yizhoumenyeyahoschuyinus@wo.cn Subject: =?GB2312?B?QUQuxOO6w6O7tPp3v6pst6Jj4NFmdnluZWI=?= To: "xfs" X-ASG-Orig-Subj: =?GB2312?B?QUQuxOO6w6O7tPp3v6pst6Jj4NFmdnluZWI=?= Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Date: Fri, 18 Sep 2015 20:51:02 +0800 X-Mailer: Foxmail 4.2 [cn] X-Barracuda-Connect: UNKNOWN[61.141.183.114] X-Barracuda-Start-Time: 1442580700 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.24 X-Barracuda-Spam-Status: No, SCORE=0.24 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MISSING_MID, NO_REAL_NAME, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22669 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 MISSING_MID Missing Message-Id: header 0.00 NO_REAL_NAME From: does not include a real name 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS Message-Id: <20150918125143.A7471A420A4@cuda.sgi.com> 20:51:01 ÄúºÃ£¬ ±¾¹«Ë¾Ìṩ¶ÔÍâ´úo¿ª¸÷ÐÐÒµ·¢sƯ£¬ÈçÓÐÐèÒªÇëÀ´µçÁªÏµ¡£ Áõ˼ΰ<1.3.6,4.1.4.0.3.0.7.8> Q£º<2.2.4.9.6/0.1.4.1.3> From cmaiolino@redhat.com Fri Sep 18 09:21:29 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 174157F37 for ; Fri, 18 Sep 2015 09:21:29 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 83EB9AC007 for ; Fri, 18 Sep 2015 07:21:25 -0700 (PDT) X-ASG-Debug-ID: 1442586081-04cbb005ec1e7760001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id lP2oCCXtGbbZpdzF (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 18 Sep 2015 07:21:22 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 54C4B8F2FE; Fri, 18 Sep 2015 14:21:21 +0000 (UTC) Received: from redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8IELHpX009412 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 18 Sep 2015 10:21:20 -0400 Date: Fri, 18 Sep 2015 16:21:17 +0200 From: Carlos Maiolino To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [RFC PATCH] xfs_io: Implement inodes64 command Message-ID: <20150918142117.GA20717@redhat.com> X-ASG-Orig-Subj: Re: [RFC PATCH] xfs_io: Implement inodes64 command Mail-Followup-To: Eric Sandeen , xfs@oss.sgi.com References: <1442499846-10470-1-git-send-email-cmaiolino@redhat.com> <55FAF212.2010308@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55FAF212.2010308@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442586082 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 17, 2015 at 12:02:10PM -0500, Eric Sandeen wrote: > (oops, resending to list not just Carlos) > > On 9/17/15 9:24 AM, Carlos Maiolino wrote: > > This command aims to implement an easy way to check a filesystem for the > > existence of 64bit inodes. > > > > Based on XFS_IOC_FSINUMBERS, and starting with a lastip = 0xffffffff > > instead of 0. > > > > For now, it just returns a string saying there is or there is no 64bit inodes > > in the filesystem, but, I was wondering if it might not be better to just return > > 0 or 1, so it can be used inside scripts to check for that. Or maybe an argument > > to chose between an integer output or a string verbose output. > > > > Also, I was wondering if might be useful to, besides return the existence of > > 64bit inodes, also inform if there is any 64bit inodes allocated in the groups > > or not. Although, this will need the tool to walk through all the inode groups > > checking for allocated inodes or not, instead of just stop at the first 64bit > > inode found. > > I'm not sure what you mean here - list the groups which contain them? > Any group above the one where the first 64 bit inode is found will also > have 64-bit inodes, (unless they have no inodes at all) - so I don't see > the value, but maybe I'm missing something. > Inodes are allocated in 'clusters', you might have a 64-bit inodes cluster allocated, but not in use at all, the xfs_inogrp_t.xi_allocmask field will show which inodes from that cluster is allocated or not, so, I was wondering if the information that "64bit inodes were created" is enough, of if would be useful to say that '64bits inodes were created and are/aren't in use'. > > Also, I'm still not sure if 'inodes64' is a good name for the command, I was > > also thinking about something like 'chk64inos' but 'inodes64' was the best and > > easy to be remembered I could find. > > Eh, seems reasonable to me. Not super, but I can't think of anything much > better. > > > Comments are appreciated > > Below... > > > Signed-off-by: Carlos Maiolino > > --- > > io/open.c | 39 +++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 39 insertions(+) > > > > diff --git a/io/open.c b/io/open.c > > index ac5a5e0..3a98fdf 100644 > > --- a/io/open.c > > +++ b/io/open.c > > @@ -44,6 +44,7 @@ static cmdinfo_t statfs_cmd; > > static cmdinfo_t chproj_cmd; > > static cmdinfo_t lsproj_cmd; > > static cmdinfo_t extsize_cmd; > > +static cmdinfo_t inodes64_cmd; > > static prid_t prid; > > static long extsize; > > > > @@ -750,6 +751,37 @@ statfs_f( > > return 0; > > } > > > > +static int > > +inodes64_f( > > + int argc, > > + char **argv) > > +{ > > + int i; > > + __s32 count; > > + __u64 last = 0xffffffff; > > might be good to use XFS_MAXINUMBER_32 here > Good, I didn't know about this flag :) > > + xfs_inogrp_t igroup[64]; > > why 64? wouldn't one suffice? > well, 64 is the default size of the inode chunks (or clusters, whatever we call it), so we can get a whole inode cluster at a time. > > + xfs_fsop_bulkreq_t bulkreq; > > + > > + /* Setup bulkreq structure */ > > + bulkreq.lastip = &last; > > + bulkreq.icount = 64; > > + bulkreq.ubuffer = &igroup; > > + bulkreq.ocount = &count; > > + > > + while (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq) == 0) { > > + if (count > 0) { > > + printf("Filesystem does have 64bit inodes\n"); > > + return 0; > > + } else { > > + printf("Filesystem does not have 64bit inodes\n"); > > + return 0; > > + } > > + } > > I'm also not sure what the "while" is for, here. > > If you start at XFS_MAXINUMBER_32, won't a single call either > give you count = 1 or count = 0? > Probably you are right. I used the while() keeping in mind the possibility to return the status of all 64bit inodes existing in the filesystem, also, I had this question: "What if the inode XFS_MAXINUMBER_32 does not exist, but bigger inodes do? Like in different, bigger AGs?" I was considering that each call using XFS_IOC_FSINUMBERS, will return only the inodes in the same allocation group, and another xfsctl call was needed to continue in the following ones. But I really don't know from where I took it, probably misinterpreting the xfsctl manpage :) I should have read the kernel implementation before writing it :) So, yes, you're right, just a single xfsctl call here will return the next valid inode bigger than 0xffffffff. while{} needed only if we want to keep track of the status of the remaining ones, which, IMHO is not the goal of this command. > > + perror("xfsctl(XFS_IOC_FSINUMBERS)"); > > + exitcode = 1; > > + return 0; > > +} > > + > > void > > open_init(void) > > { > > @@ -815,6 +847,12 @@ open_init(void) > > _("get/set preferred extent size (in bytes) for the open file"); > > extsize_cmd.help = extsize_help; > > > > + inodes64_cmd.name = "inodes64"; > > + inodes64_cmd.cfunc = inodes64_f; > > + inodes64_cmd.flags = CMD_NOMAP_OK; > > + inodes64_cmd.oneline = > > + _("Checks if filesyste contais 64bit inodes"); > > "if filesystem contains" > Typo, sorry > > + > > add_command(&open_cmd); > > add_command(&stat_cmd); > > add_command(&close_cmd); > > @@ -822,4 +860,5 @@ open_init(void) > > add_command(&chproj_cmd); > > add_command(&lsproj_cmd); > > add_command(&extsize_cmd); > > + add_command(&inodes64_cmd); > > } > > needs xfs_io manpage updates too, and possibly an xfstest test case? > > -Eric Will do, this was just an RFC to get comments about it. I wasn't willing to write a manpage entry without even know if people agreed with the command name, or even with the idea :) Thanks for the comments, much appreciated. > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- Carlos From sandeen@sandeen.net Fri Sep 18 09:28:46 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 8F6857F37 for ; Fri, 18 Sep 2015 09:28:46 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 7CE428F8040 for ; Fri, 18 Sep 2015 07:28:46 -0700 (PDT) X-ASG-Debug-ID: 1442586523-04cb6c355c1b5ef0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id Ibjw8aa9EY8LHGLh for ; Fri, 18 Sep 2015 07:28:43 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 903DA6035B3E for ; Fri, 18 Sep 2015 09:28:43 -0500 (CDT) Subject: Re: [RFC PATCH] xfs_io: Implement inodes64 command To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [RFC PATCH] xfs_io: Implement inodes64 command References: <1442499846-10470-1-git-send-email-cmaiolino@redhat.com> <55FAF212.2010308@sandeen.net> <20150918142117.GA20717@redhat.com> From: Eric Sandeen X-Enigmail-Draft-Status: N1110 Message-ID: <55FC1F9A.5020103@sandeen.net> Date: Fri, 18 Sep 2015 09:28:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150918142117.GA20717@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1442586523 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22671 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/18/15 9:21 AM, Carlos Maiolino wrote: > On Thu, Sep 17, 2015 at 12:02:10PM -0500, Eric Sandeen wrote: ... >>> Also, I was wondering if might be useful to, besides return the existence of >>> 64bit inodes, also inform if there is any 64bit inodes allocated in the groups >>> or not. Although, this will need the tool to walk through all the inode groups >>> checking for allocated inodes or not, instead of just stop at the first 64bit >>> inode found. >> >> I'm not sure what you mean here - list the groups which contain them? >> Any group above the one where the first 64 bit inode is found will also >> have 64-bit inodes, (unless they have no inodes at all) - so I don't see >> the value, but maybe I'm missing something. >> > > Inodes are allocated in 'clusters', you might have a 64-bit inodes cluster > allocated, but not in use at all, the xfs_inogrp_t.xi_allocmask field will show > which inodes from that cluster is allocated or not, so, I was wondering if the > information that "64bit inodes were created" is enough, of if would be useful to > say that '64bits inodes were created and are/aren't in use'. Hm, unless the ikeep option is specified, aren't 100% unused clusters freed? >>> Also, I'm still not sure if 'inodes64' is a good name for the command, I was >>> also thinking about something like 'chk64inos' but 'inodes64' was the best and >>> easy to be remembered I could find. >> >> Eh, seems reasonable to me. Not super, but I can't think of anything much >> better. >> >>> Comments are appreciated >> >> Below... ... >>> + xfs_inogrp_t igroup[64]; >> >> why 64? wouldn't one suffice? >> > > well, 64 is the default size of the inode chunks (or clusters, whatever we call > it), so we can get a whole inode cluster at a time. Ok, but the stated purpose of the command is to tell us whether there are 0, or more than 0, 64-bit inodes on the filesystem. Why do you need the whole cluster for that? >>> + xfs_fsop_bulkreq_t bulkreq; >>> + >>> + /* Setup bulkreq structure */ >>> + bulkreq.lastip = &last; >>> + bulkreq.icount = 64; >>> + bulkreq.ubuffer = &igroup; >>> + bulkreq.ocount = &count; >>> + >>> + while (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq) == 0) { >>> + if (count > 0) { >>> + printf("Filesystem does have 64bit inodes\n"); >>> + return 0; >>> + } else { >>> + printf("Filesystem does not have 64bit inodes\n"); >>> + return 0; >>> + } >>> + } >> >> I'm also not sure what the "while" is for, here. >> >> If you start at XFS_MAXINUMBER_32, won't a single call either >> give you count = 1 or count = 0? >> > > Probably you are right. I used the while() keeping in mind the possibility to > return the status of all 64bit inodes existing in the filesystem, also, I had > this question: > > "What if the inode XFS_MAXINUMBER_32 does not exist, but bigger inodes do? Like > in different, bigger AGs?" I thought that the interface returns the first inode(s) greater than lastip, or returns none and ocount == 0 if none are found. > I was considering that each call using XFS_IOC_FSINUMBERS, will return only the > inodes in the same allocation group, and another xfsctl call was needed to > continue in the following ones. But I really don't know from where I took it, > probably misinterpreting the xfsctl manpage :) > > I should have read the kernel implementation before writing it :) > > So, yes, you're right, just a single xfsctl call here will return the next valid > inode bigger than 0xffffffff. ok. > while{} needed only if we want to keep track of the status of the remaining > ones, which, IMHO is not the goal of this command. *nod* ... >> needs xfs_io manpage updates too, and possibly an xfstest test case? >> >> -Eric > > Will do, this was just an RFC to get comments about it. I wasn't willing to > write a manpage entry without even know if people agreed with the command name, > or even with the idea :) I understand, it's just a reminder. :) > Thanks for the comments, much appreciated. no problem! From tdm@sgi.com Fri Sep 18 11:01:49 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 070FE7F3F for ; Fri, 18 Sep 2015 11:01:49 -0500 (CDT) Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay1.corp.sgi.com (Postfix) with ESMTP id DF19E8F8035; Fri, 18 Sep 2015 09:01:45 -0700 (PDT) Received: from [128.162.232.11] (porter.americas.sgi.com [128.162.232.11]) by estes.americas.sgi.com (Postfix) with ESMTP id 8DB697002686; Fri, 18 Sep 2015 11:01:45 -0500 (CDT) Message-ID: <55FC3569.5020801@sgi.com> Date: Fri, 18 Sep 2015 11:01:45 -0500 From: Troy McCorkell User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: xfs@oss.sgi.com, carlos.e.r@opensuse.org Subject: Re: What's up with this list? References: <541AFB60.5030403@sgi.com> <55FAF053.3020405@sgi.com> <55FB06E8.1020203@opensuse.org> In-Reply-To: <55FB06E8.1020203@opensuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/17/2015 01:31 PM, Carlos E. R. wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2015-09-17 18:54, Troy McCorkell wrote: > >> On 09/16/2015 07:53 AM, Carlos E. R. wrote: >> > > >> I'll chat with the SGI IT group again. >> > Thanks :-) > > - -- > Cheers / Saludos, > > Carlos E. R. > > (from 13.1 x86_64 "Bottle" (Minas Tirith)) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iF4EAREIAAYFAlX7BugACgkQja8UbcUWM1yf2gD9GZrVQopDE+YS1yrbhHS+GiYd > nV4ZiwQ15EJkRpvwOssA/jEGl2f3SMHd6s2wCpStP2Smm/mOwMszoWX6N5qTS/34 > =tcZ8 > -----END PGP SIGNATURE----- > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > Carlos, I discussed the spam issue on the xfs@oss.sgi.com mailing list with SGI IT. xfs@oss.sgi.com is an open list and does not require people to be members of the list to post to it. The spam filters applied to xfs@oss.sgi.com are as aggressive as they can be and still allow for an open list. Next option would be to add a moderator to the list. Adding a moderator would interfere with non-list members posting to the list. Thanks, Troy From angelo70@gmail.com Fri Sep 18 11:17:01 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,T_DKIM_INVALID autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 87E437F3F for ; Fri, 18 Sep 2015 11:17:01 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 5C0AA8F8035 for ; Fri, 18 Sep 2015 09:17:01 -0700 (PDT) X-ASG-Debug-ID: 1442593019-04cb6c355c1b8e30001-NocioJ Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by cuda.sgi.com with ESMTP id toudkCfiVMDQIBz8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 18 Sep 2015 09:16:59 -0700 (PDT) X-Barracuda-Envelope-From: angelo70@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.212.176 Received: by wicfx3 with SMTP id fx3so37391480wic.0 for ; Fri, 18 Sep 2015 09:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=5ramiK0dmvEjlGLXY/Qok2aYY4Q10g0dUsr6V4CvSRk=; b=VWJ8YhLP2g0ZA7YIi2127TnhQxCuBolv1LCGjt2CC9HxLe/iOg0xyoH+BlPDpl4b2M yjM4qZTkSto9730WWlzCaieqlh5wLHS9044Zv3Nc/H94O/CyDyiKfDGoMBGkGhPwOsV6 sNwYYmUT+R/IJ8jwm7U5YToLMdyrqql4vZXVLR4FsrcGSy0ygG/gd7Hpv5D+WHqft7gN y4wJDmA0K0QoSNvKJ28UR8hR7bxbYGtv2+NfWN8JHdD2WRIxvH0M1om1+WfAaeEjoOAf rWVKjfVmM6xIPR7UE7PU6wzVKP5ztnBN+R/f0sxTzQ0GIXFrb2xmvQlhCFDJkLD7cC5d Bc+A== X-Received: by 10.180.8.200 with SMTP id t8mr17606223wia.34.1442593018666; Fri, 18 Sep 2015 09:16:58 -0700 (PDT) Received: from [192.168.0.111] (host22-235-dynamic.248-95-r.retail.telecomitalia.it. [95.248.235.22]) by smtp.googlemail.com with ESMTPSA id cm6sm16301827wib.22.2015.09.18.09.16.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2015 09:16:58 -0700 (PDT) Message-ID: <55FC38F9.1000102@gmail.com> Date: Fri, 18 Sep 2015 18:16:57 +0200 From: angelo User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: xfstests, bad generic tests 009 and 308 Content-Type: text/plain; charset=windows-1252; format=flowed X-ASG-Orig-Subj: xfstests, bad generic tests 009 and 308 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail-wi0-f176.google.com[209.85.212.176] X-Barracuda-Start-Time: 1442593019 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED, MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22673 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature Hi all, working on arm (32bit arch), kernel 4.1.6. Looking to find the reason of a bad result on xfstests, -tests/generic/009 ------------------ i get several "all holes" messages generic/009 [ 842.949643] run fstests generic/009 at 2015-09-18 15:29:36 - output mismatch (see /home/angelo/xfstests/results//generic/009.out.bad) --- tests/generic/009.out 2015-09-17 10:54:06.689071257 +0000 +++ /home/angelo/xfstests/results//generic/009.out.bad 2015-09-18 15:29:41.412784177 +0000 @@ -1,79 +1,45 @@ QA output created by 009 1. into a hole -0: [0..7]: hole -1: [8..23]: unwritten -2: [24..39]: hole +0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 also some other tests are giving the same bad notices. -tests/generic/308 ------------------ I have now: CONFIG_LBDAF=y In my target device this test creates a 16 Terabytes file 308.tempfile -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 While "df" is not complaining about: /dev/mmcblk0p5 8378368 45252 8333116 1% /media/p5 and next rm -f on it hands the cpu to 95%, forever. This issue seems known from a long time, as it has been discussed in the thread: http://oss.sgi.com/archives/xfs/2013-04/msg00273.html I was wondering if there was any special reason why the Jeff patch has never been finally applied. I applied this patch anyway, and tests pass. Best regards, Angelo Dureghello From angelo.dureghello@nomovok.com Fri Sep 18 11:38:44 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 4931B7F3F for ; Fri, 18 Sep 2015 11:38:44 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 36E898F8037 for ; Fri, 18 Sep 2015 09:38:44 -0700 (PDT) X-ASG-Debug-ID: 1442594320-04cbb005ec1eb040001-NocioJ Received: from mail.nomovok.com (mail.nomovok.com [83.150.122.238]) by cuda.sgi.com with ESMTP id LKqdXc39b2gARSUR (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Sep 2015 09:38:41 -0700 (PDT) X-Barracuda-Envelope-From: angelo.dureghello@nomovok.com X-Barracuda-Apparent-Source-IP: 83.150.122.238 Received: from [192.168.0.111] (host22-235-dynamic.248-95-r.retail.telecomitalia.it [95.248.235.22]) by mail.nomovok.com (Postfix) with ESMTPSA id BAA94AE089 for ; Fri, 18 Sep 2015 19:38:39 +0300 (EEST) Message-ID: <55FC3E0E.9060506@nomovok.com> Date: Fri, 18 Sep 2015 18:38:38 +0200 From: Angelo Dureghello User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: xfstests, bad generic tests 009 and 308 Content-Type: text/plain; charset=utf-8; format=flowed X-ASG-Orig-Subj: xfstests, bad generic tests 009 and 308 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail.nomovok.com[83.150.122.238] X-Barracuda-Start-Time: 1442594320 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22674 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words Hi all, working on arm (32bit arch), kernel 4.1.6. Looking to find the reason of some bad results on xfstests, -tests/generic/009 ------------------ i get several "all holes" messages generic/009 [ 842.949643] run fstests generic/009 at 2015-09-18 15:29:36 - output mismatch (see /home/angelo/xfstests/results//generic/009.out.bad) --- tests/generic/009.out 2015-09-17 10:54:06.689071257 +0000 +++ /home/angelo/xfstests/results//generic/009.out.bad 2015-09-18 15:29:41.412784177 +0000 @@ -1,79 +1,45 @@ QA output created by 009 1. into a hole -0: [0..7]: hole -1: [8..23]: unwritten -2: [24..39]: hole +0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 also some other tests are giving the same bad notices. -tests/generic/308 ------------------ I have now: CONFIG_LBDAF=y In my target device this test creates a 16 Terabytes file 308.tempfile -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 While "df" is not complaining about: /dev/mmcblk0p5 8378368 45252 8333116 1% /media/p5 and next rm -f on it hands the cpu to 95%, forever. This issue seems known from a long time, as it has been discussed in the thread: http://oss.sgi.com/archives/xfs/2013-04/msg00273.html I was wondering if there was any special reason why the Jeff patch has never been finally applied. I applied this patch anyway, and tests pass. -- Best regards, Angelo Dureghello From bounces@workgrowth.ml Fri Sep 18 17:39:09 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 0902D7F4E for ; Fri, 18 Sep 2015 17:39:09 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 043FEAC002 for ; Fri, 18 Sep 2015 15:39:02 -0700 (PDT) X-ASG-Debug-ID: 1442615937-04cb6c6b07065b0001-NocioJ Received: from coro3.isol-servers.net (static-ip-85-25-159-22.inaddr.ip-pool.com [85.25.159.22]) by cuda.sgi.com with ESMTP id oDZ8IMcSbHL3dELL (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 18 Sep 2015 15:38:58 -0700 (PDT) X-Barracuda-Envelope-From: bounces@workgrowth.ml X-Barracuda-Apparent-Source-IP: 85.25.159.22 Received: by coro3.isol-servers.net (Postfix, from userid 10001) id 78C19DC0F71; Sat, 19 Sep 2015 01:38:57 +0300 (EEST) To: xfs@oss.sgi.com Subject: Goodbye from our Newsletter X-PHP-Originating-Script: 10001:class.phpmailer.php X-ASG-Orig-Subj: Goodbye from our Newsletter Received: from b115306.yse.yahoo.net [68.180.229.164] by workgrowth.ml with HTTP; Sat, 19 Sep 2015 01:38:56 +0300 Date: Sat, 19 Sep 2015 01:38:57 +0300 From: "workgrowth.ml" Message-ID: X-Priority: 3 X-Mailer: PHPMailer 5.2.9 (https://github.com/PHPMailer/PHPMailer/) X-phpList-version: 3.0.12 X-MessageID: systemmessage X-ListMember: xfs@oss.sgi.com Precedence: bulk Bounces-To: bounces@workgrowth.ml List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: static-ip-85-25-159-22.inaddr.ip-pool.com[85.25.159.22] X-Barracuda-Start-Time: 1442615938 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22682 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Goodbye from our Newsletter, sorry to see you go. You have been unsubscribed from our newsletters. This is the last email you will receive from us. Our newsletter system, phpList, will refuse to send you any further messages, without manual intervention by our administrator. If there is an error in this information, you can re-subscribe: please go to http://workgrowth.ml/lists/?p=subscribe and follow the steps. Thank you From david@fromorbit.com Fri Sep 18 17:57:35 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 841047F3F for ; Fri, 18 Sep 2015 17:57:35 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 73CE68F8035 for ; Fri, 18 Sep 2015 15:57:32 -0700 (PDT) X-ASG-Debug-ID: 1442617049-04cbb033b206bd0001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id TbEVjK4T9BE9FKpT for ; Fri, 18 Sep 2015 15:57:30 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DpBwCKlfxVPOV8LHldgySBPYJcg32iRgEGim+RHgQCAoE2TQEBAQEBAQcBAQEBQT+EJAEBBDocIxAIAxgJJQ8FJQMHGhMbiBLLbAErGYYThD6BBoUNB4MYgRQBBJVjjQObHYR2LDOJbQEBAQ Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 19 Sep 2015 08:26:25 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Zd4Zs-0000Ue-8o; Sat, 19 Sep 2015 08:56:24 +1000 Date: Sat, 19 Sep 2015 08:56:24 +1000 From: Dave Chinner To: Troy McCorkell Cc: xfs@oss.sgi.com, carlos.e.r@opensuse.org Subject: Re: What's up with this list? Message-ID: <20150918225624.GF26895@dastard> X-ASG-Orig-Subj: Re: What's up with this list? References: <541AFB60.5030403@sgi.com> <55FAF053.3020405@sgi.com> <55FB06E8.1020203@opensuse.org> <55FC3569.5020801@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55FC3569.5020801@sgi.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442617049 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22683 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Fri, Sep 18, 2015 at 11:01:45AM -0500, Troy McCorkell wrote: > xfs@oss.sgi.com is an open list and does not require people to be members > of the list to post to it. The spam filters applied to > xfs@oss.sgi.com are > as aggressive as they can be and still allow for an open list. > > Next option would be to add a moderator to the list. Adding a moderator > would interfere with non-list members posting to the list. Moderation is not an option because of this interference and the burden it puts on the moderator to respond in a timely fashion. If the spam rejection does not improve our next option is to move to the linux-xfs@vger.kernel.org list - the vger infrastructure is not perfect, but it does have better spam rejection than the current filtering on this list. This may be the best long-term solution to the problem, but it does involve short term pain for everyone. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Fri Sep 18 18:00:30 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 2F03A7F3F for ; Fri, 18 Sep 2015 18:00:30 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id CBA69AC002 for ; Fri, 18 Sep 2015 16:00:29 -0700 (PDT) X-ASG-Debug-ID: 1442617227-04bdf0462206da0001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id H2x8riZRzLEOWrJT for ; Fri, 18 Sep 2015 16:00:27 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AvEgCLlvxVPOV8LHldgyRUaYJcii2cAgMRAQZERollilBbhXMEAgKBNk0BAQEBAQEHAQEBAUE/hCMBAQEDATocIwULCAMYCSUPBSUDBxoTiCYHDstbAQEBAQEBBAEBAQEBHRmGE4VEgm6CHweDGIEUBYc0ji+FEYVEgi6BZpk3hHYsMwGJbAEBAQ Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 19 Sep 2015 08:29:13 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Zd4O4-0000R0-7f; Sat, 19 Sep 2015 08:44:12 +1000 Date: Sat, 19 Sep 2015 08:44:12 +1000 From: Dave Chinner To: Angelo Dureghello Cc: xfs@oss.sgi.com Subject: Re: xfstests, bad generic tests 009 and 308 Message-ID: <20150918224412.GE26895@dastard> X-ASG-Orig-Subj: Re: xfstests, bad generic tests 009 and 308 References: <55FC3E0E.9060506@nomovok.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55FC3E0E.9060506@nomovok.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442617227 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22683 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words On Fri, Sep 18, 2015 at 06:38:38PM +0200, Angelo Dureghello wrote: > Hi all, > > working on arm (32bit arch), kernel 4.1.6. Is this a new platform? Also, we need to know what compiler you are using, because we know that certain versions of gcc miscompile XFS kernel code on arm (4.6, 4.7 and certain versions of 4.8 are suspect) due to a combination of compiler mis-optimisations and kernel bugs in the arm 64 bit division asm implementation. As such, it would be worthwhile trying gcc-4.9 and a 4.3-rc1 kernel to see if the problems still occur. > Looking to find the reason of some bad results on xfstests, > > -tests/generic/009 > ------------------ > i get several "all holes" messages > > generic/009 [ 842.949643] run fstests generic/009 at 2015-09-18 > 15:29:36 > - output mismatch (see > /home/angelo/xfstests/results//generic/009.out.bad) > --- tests/generic/009.out 2015-09-17 10:54:06.689071257 +0000 > +++ /home/angelo/xfstests/results//generic/009.out.bad > 2015-09-18 15:29:41.412784177 +0000 > @@ -1,79 +1,45 @@ > QA output created by 009 > 1. into a hole > -0: [0..7]: hole > -1: [8..23]: unwritten > -2: [24..39]: hole > +0: [0..39]: hole > daa100df6e6711906b61c9ab5aa16032 > > also some other tests are giving the same bad notices. Can you attach the entire /home/angelo/xfstests/results//generic/009.out.bad file? I'm not sure which of the tests this output comes from, so I need to confirm which specific operations are resulting in errors. > -tests/generic/308 > ------------------ > > I have now: CONFIG_LBDAF=y > > In my target device this test creates a 16 Terabytes file 308.tempfile > > -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 > > While "df" is not complaining about: > > /dev/mmcblk0p5 8378368 45252 8333116 1% /media/p5 > > and next rm -f on it hands the cpu to 95%, forever. > > This issue seems known from a long time, as it has been discussed in > the thread: > > http://oss.sgi.com/archives/xfs/2013-04/msg00273.html > > I was wondering if there was any special reason why the Jeff patch has > never been finally applied. MAX_LFS_FILESIZE on 32 bits is 8TB, whereas xfs supports 16TB file size on 32 bit systems. The specific issue this test fixed was committed in commit 8695d27 ("xfs: fix infinite loop at xfs_vm_writepage on 32bit system") http://oss.sgi.com/archives/xfs/2014-05/msg00447.html And, as you may notice now, generic/308 is the test case for the exact problem the above commit fixed. Can you find out exactly where the CPU is looping? sysrq-l will help, as will running 'perf top -U -g' to show you the hot code paths, and so on. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Fri Sep 18 18:17:51 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 0A11F7F3F for ; Fri, 18 Sep 2015 18:17:51 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id A8ACEAC003 for ; Fri, 18 Sep 2015 16:17:50 -0700 (PDT) X-ASG-Debug-ID: 1442618266-04bdf0462807210001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id eCNFzxtorGPxpuAP for ; Fri, 18 Sep 2015 16:17:47 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CEEABHmvxVPOV8LHldgyRUaYJcii2bOE0RAQaJPlFgiyeFdwICAQECgTdNAQEBAQEBBwEBAQFBP4QjAQEBAwEnExwjBQsIAw4KCSUPBSUDBxoTFIgSB8trAQEBAQYBAQEBAR0ZhhOFRIQ7AQFQB4QsBZVjhRGHcoFRh1aFWYRohzWEdiwziC6BPwEBAQ Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 19 Sep 2015 08:47:46 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Zd4uW-0000Xk-Qm; Sat, 19 Sep 2015 09:17:44 +1000 Date: Sat, 19 Sep 2015 09:17:44 +1000 From: Dave Chinner To: George Wang Cc: xfs@oss.sgi.com Subject: Re: How Can I Get Writeback Status When Running fs_mark Message-ID: <20150918231744.GG26895@dastard> X-ASG-Orig-Subj: Re: How Can I Get Writeback Status When Running fs_mark 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-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442618266 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22683 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Fri, Sep 18, 2015 at 07:06:39PM +0800, George Wang wrote: > Hi, Dave, > > I read the mail you post for "fs-writeback: drop wb->list_lock during > blk_finish_plug()", and I > adore you very much. > > I'm very curious that how you get the writeback status when running fs_mark. > > I will appreciate very much if you can share the way you get writeback > status and iops, etc. http://pcp.io/ Indeed: http://pcp.io/testimonials.html > And maybe people in community can use this way to do the same tests as you. > > The following is a part copy of the test result you got: This is the best way to demonstrate: https://flic.kr/p/xR9Cwn That's a screen shot of my "coding and testing" virtual desktop when running the fsmark test. (Yes, it's a weird size - I have 3 x 24" monitors in portrait orientation which gives a 3600x1920 image....) > FSUse% Count Size Files/sec App Overhead > 0 80000 4096 106938.0 543310 > 0 160000 4096 102922.7 476362 > 0 240000 4096 107182.9 538206 > 0 320000 4096 107871.7 619821 > 0 400000 4096 99255.6 622021 > 0 480000 4096 103217.8 609943 > 0 560000 4096 96544.2 640988 > 0 640000 4096 100347.3 676237 > 0 720000 4096 87534.8 483495 > 0 800000 4096 72577.5 2556920 > 0 880000 4096 97569.0 646996 > > You can see this from the lower chart that tracks memory usage - all 16GB gets used up pretty quickly, and it matches with changes in writeback behaviour. You can also see it from /proc/meminfo and Writeback iops and throughput you can also get from 'iostat -d -m -x 5', etc. But when you've got it in pretty, real-time graphs you can easily see correlations between different behaviours.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From prvs=7703a3e46f=joshua.earl@drexelmed.edu Fri Sep 18 18:52:04 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id AB94B7F3F for ; Fri, 18 Sep 2015 18:52:04 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 6F8018F804B for ; Fri, 18 Sep 2015 16:52:01 -0700 (PDT) X-ASG-Debug-ID: 1442620318-04bdf0462207bb0001-NocioJ Received: from pp-mta2.drexelmed.edu ([198.17.30.173]) by cuda.sgi.com with ESMTP id ggCVF2NqotbLZ8Nd (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 18 Sep 2015 16:51:59 -0700 (PDT) X-Barracuda-Envelope-From: prvs=7703a3e46f=joshua.earl@drexelmed.edu X-Barracuda-Apparent-Source-IP: 198.17.30.173 Received: from pps.filterd (pp-mta2.drexelmed.edu [127.0.0.1]) by pp-mta2.drexelmed.edu (8.15.0.59/8.14.7) with SMTP id t8INkeJF028148; Fri, 18 Sep 2015 19:51:56 -0400 Received: from ncb-sv-104.ducom.edu ([10.16.20.142]) by pp-mta2.drexelmed.edu with ESMTP id 1x05bgj8b6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Sep 2015 19:51:56 -0400 Received: from NCB-SV-117.DUCOM.edu ([fe80::6519:3ee7:4c6f:f2df]) by NCB-SV-104.DUCOM.edu ([::1]) with mapi id 14.03.0248.002; Fri, 18 Sep 2015 19:51:54 -0400 From: "Earl, Joshua P" To: Dave Chinner CC: Brian Foster , "xfs@oss.sgi.com" Subject: RE: xfsxyncd in 'D' state Thread-Topic: xfsxyncd in 'D' state X-ASG-Orig-Subj: RE: xfsxyncd in 'D' state Thread-Index: AdDwn8phEmHFJRKXQuG/nBBkF7izjQAx6magAA4ETIAABCFVMAAJ7/uAACUPJiA= Date: Fri, 18 Sep 2015 23:51:53 +0000 Message-ID: <2CC86DBF85FEEC41A2DFE1647B40613D6B6217BD@NCB-SV-117.DUCOM.edu> References: <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2CA0@NCB-SV-117.DUCOM.edu> <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DB8@NCB-SV-117.DUCOM.edu> <20150917192102.GA5342@bfoster.bfoster> <2CC86DBF85FEEC41A2DFE1647B40613D5DAF2DFC@NCB-SV-117.DUCOM.edu>,<20150918020351.GS3902@dastard> In-Reply-To: <20150918020351.GS3902@dastard> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.240.98.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-09-18_12:2015-09-18,2015-09-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=ducom_outbound_notspam policy=ducom_outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1509180298 X-Barracuda-Connect: UNKNOWN[198.17.30.173] X-Barracuda-Start-Time: 1442620319 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=RDNS_NONE, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22684 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS On Thu, Sep 17, 2015 at 09:37:09PM +0000, Earl, Joshua P wrote: > Hi Brian, > > Sorry about the top posting thing... I'm not sure how to control > that, is my replying somehow messing with that? when everthing is backwards to read the thread it makes it hard And please wrap your text at 72 columns. Thanks, sorry for my ignorance! I didn't understand the nomenclature (first time posting) > With good news, I seem to have figured out what was going on. I > had a cron job which would run every 15 minutes which changed the > permissions in a directory: > chmod -R g+rwx /data/shared/homes/bjanto/* > chmod -R g+rwx /data/shared/homes/lanastor/* > chgrp -hR ilmn /data/nextseq/* > chgrp -hR lab /data/shared/homes/* So you are modifying a large amount of metadata every 15 minutes, and then you have a problem with your 22-disk wide RAID6 array when the metadata gets written back. metadata writeback is, by the nature of metadata in a filesystem, done in small, isolated IOs that cause large RAID5/6 arrays to do an stripe-wide RMW cycle on every IO. > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq= -sz avgqu-sz await svctm %util > > sda 0.29 3.61 5.78 3.58 0.10 0.03 28= .27 0.05 5.19 2.39 2.24 > > sdb 1.02 8.66 31.50 3.91 0.33 0.12 26= .14 5.94 167.54 27.47 97.25 > > > > Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq= -sz avgqu-sz await svctm %util > > sda 0.00 1.60 0.00 2.00 0.00 0.01 14= .40 0.01 4.30 4.30 0.86 > > sdb 0.00 0.00 0.00 0.80 0.00 0.03 64= .00 6.46 6332.75 1250.00 100.00 That's pretty clear that your hardware raid array is taking over a second per IO that requires a RMW cycle. So not a filesystem problem... I appreciate your insight, I honestly had no idea. It is unintuitive to me when you make a change to a file that the file has an additional 'metadata' write which takes a lot longer. I guess in the future if I make changes to the owner/group of files there is just going to be some lag associated with it on a raid 5/6 with many disks Thanks! ~josh Cheers, Dave. -- Dave Chinner david@fromorbit.com ________________________________ This email and any accompanying attachments are confidential. The informati= on is intended solely for the use of the individual to whom it is addressed= . Any review, disclosure, copying, distribution, or use of this email commu= nication by others is strictly prohibited. If you are not the intended reci= pient, please notify the sender immediately and delete all copies. Thank yo= u for your cooperation. From robin.listas@gmail.com Fri Sep 18 19:31:13 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 5A4907F3F for ; Fri, 18 Sep 2015 19:31:13 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 2CD0D8F8037 for ; Fri, 18 Sep 2015 17:31:10 -0700 (PDT) X-ASG-Debug-ID: 1442622666-04bdf0462708780001-NocioJ Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by cuda.sgi.com with ESMTP id fX0jGRFNBhjlJwxE (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 18 Sep 2015 17:31:07 -0700 (PDT) X-Barracuda-Envelope-From: robin.listas@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.212.175 Received: by wicfx3 with SMTP id fx3so82618719wic.1 for ; Fri, 18 Sep 2015 17:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=MYoki1Mf9aLtmZZ7yN92CcesX5OGgM4JZWkcEEpdZyw=; b=DajAKyKDTa+QaOKCpdo3lOkiWv/Y9f4D1odkEA6QAmBagcBPIz7xS5ubalhG1y3twd oyZXyqfV45N9euKZeFSMWCrJMRKvAzSvdMhoux4k6otrUnznt5RWqGA7kc0RkdWx7Vrb 2mGa6g0VrVfU4Qf9z8Rs2oUtZZcs4DFKtdakQ+ZS6MT9I3GuaCJ32oW71D9trqxciglF 2lgweZOU5fr6JrXKxBdKw3OqDkkVYXE37BVS5wmGCAU9ip5+1L725+9XvrgfBQcdqxOq W2BslFuaFuNJuS4U0pp/U/KTa3aGN5WicDK7iT0/f3u3uf49SacrecvJmXUN+pQzfx4W vRUQ== X-Received: by 10.180.104.40 with SMTP id gb8mr888202wib.17.1442622666362; Fri, 18 Sep 2015 17:31:06 -0700 (PDT) Received: from minas-tirith.valinor (111.Red-2-140-5.dynamicIP.rima-tde.net. [2.140.5.111]) by smtp.gmail.com with ESMTPSA id r9sm11317286wjz.35.2015.09.18.17.31.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2015 17:31:05 -0700 (PDT) Sender: Carlos Robinson Received: from localhost (localhost [127.0.0.1]) by minas-tirith.valinor (Postfix) with ESMTP id CE67C1814DB for ; Sat, 19 Sep 2015 02:30:57 +0200 (CEST) Date: Sat, 19 Sep 2015 02:30:42 +0200 (CEST) From: "Carlos E. R." X-X-Sender: cer@minas-tirith.valinor To: XFS mailing list Subject: Re: What's up with this list? In-Reply-To: <20150918225624.GF26895@dastard> X-ASG-Orig-Subj: Re: What's up with this list? Message-ID: References: <541AFB60.5030403@sgi.com> <55FAF053.3020405@sgi.com> <55FB06E8.1020203@opensuse.org> <55FC3569.5020801@sgi.com> <20150918225624.GF26895@dastard> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463758550-202773465-1442622657=:24753" X-Barracuda-Connect: mail-wi0-f175.google.com[209.85.212.175] X-Barracuda-Start-Time: 1442622667 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22685 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463758550-202773465-1442622657=:24753 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2015-09-19 a las 08:56 +1000, Dave Chinner escribió: > On Fri, Sep 18, 2015 at 11:01:45AM -0500, Troy McCorkell wrote: >> xfs@oss.sgi.com is an open list and does not require people to be members >> of the list to post to it. The spam filters applied to >> xfs@oss.sgi.com are >> as aggressive as they can be and still allow for an open list. >> >> Next option would be to add a moderator to the list. Adding a moderator >> would interfere with non-list members posting to the list. > > Moderation is not an option because of this interference and the > burden it puts on the moderator to respond in a timely fashion. There is no need to go to extreme measures; I think it is easier than that. I do not have access to the oss.sgi.com logs, but surely the admins can, and find out what were the posts that bounced and for what reason. My guess is that they were sent from an invalid domain (no dns), or no reverse dns, or something like that (not content analysis, that comes once the mail is accepted and stored). Surely a filter for those is simple enough to implement, and should not harm other participants. - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlX8rMEACgkQja8UbcUWM1zCvQD8ChIl3emugmUA3OzXZNlbDb+a RHppXrwnmLVMwmhRXXAA/RwwQZn/di5yKZZQFDwhFsEnALkmeycPdKNhGHRXLePN =Y84u -----END PGP SIGNATURE----- ---1463758550-202773465-1442622657=:24753-- From fanael4@gmail.com Sat Sep 19 00:12:29 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,T_DKIM_INVALID autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id B54E57F3F for ; Sat, 19 Sep 2015 00:12:29 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 9894E30405F for ; Fri, 18 Sep 2015 22:12:26 -0700 (PDT) X-ASG-Debug-ID: 1442639544-04cb6c6b070cc60001-NocioJ Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by cuda.sgi.com with ESMTP id zugG2dLcnTxhnzeB (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 18 Sep 2015 22:12:25 -0700 (PDT) X-Barracuda-Envelope-From: fanael4@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.214.178 Received: by obbda8 with SMTP id da8so51675493obb.1 for ; Fri, 18 Sep 2015 22:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tq65hOwZ3qBu0s1NThVICJ3njPl7uPpS2U3FQSYZXeQ=; b=zhFzuqAbF2EVlyTvmxq8RdvcygH3MfolSSagMFQQ1A9rdyHd9gJ1h0fsdR3v/vo2kR TxQi0FXW9qOUuVX7KlRSGAoNw39ztf7U7LlCCVDRXoIChUm8otaylNxHpk/ZwSfNDH4P ts9E1z3fqBCr/4MsISTnaC9rAUIiV1aCghlWPwPMaoljdCd/rMY03NzljKCWvMUN01H/ iJkO4/ORwQWZ4xf7KUmYP3ylkb5SCvMdD68xGES2DY8MLNPvMnqGDmqzx9rOIU804Djr rOjKha+qnQ8kwsPC5pUgbaUCGgFhyb4ozrAhqBZeVVCTGRUbhE/3689UfBbSL2/RqeMa rd/w== MIME-Version: 1.0 X-Received: by 10.182.225.138 with SMTP id rk10mr6153764obc.2.1442639544391; Fri, 18 Sep 2015 22:12:24 -0700 (PDT) Received: by 10.202.171.196 with HTTP; Fri, 18 Sep 2015 22:12:24 -0700 (PDT) In-Reply-To: <20150918225624.GF26895@dastard> References: <541AFB60.5030403@sgi.com> <55FAF053.3020405@sgi.com> <55FB06E8.1020203@opensuse.org> <55FC3569.5020801@sgi.com> <20150918225624.GF26895@dastard> Date: Sat, 19 Sep 2015 07:12:24 +0200 Message-ID: Subject: Re: What's up with this list? From: Fanael Linithien X-ASG-Orig-Subj: Re: What's up with this list? To: Dave Chinner Cc: Troy McCorkell , carlos.e.r@opensuse.org, xfs@oss.sgi.com Content-Type: text/plain; charset=UTF-8 X-Barracuda-Connect: mail-ob0-f178.google.com[209.85.214.178] X-Barracuda-Start-Time: 1442639544 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22689 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 2015-09-19 0:56 GMT+02:00 Dave Chinner : > If the spam rejection does not improve our next option is to move to > the linux-xfs@vger.kernel.org list - the vger infrastructure is not > perfect, but it does have better spam rejection than the current > filtering on this list. This may be the best long-term solution to > the problem, but it does involve short term pain for everyone. I'd say do it. I don't remember getting any spam from vger lists, while here it's several mails a day. From arekm@maven.pl Sat Sep 19 06:47:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 1891B7F37 for ; Sat, 19 Sep 2015 06:47:08 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 09EB2304032 for ; Sat, 19 Sep 2015 04:47:04 -0700 (PDT) X-ASG-Debug-ID: 1442663217-04cbb033b014b90001-NocioJ Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by cuda.sgi.com with ESMTP id Jh35elSapCHJupWT (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 19 Sep 2015 04:46:58 -0700 (PDT) X-Barracuda-Envelope-From: arekm@maven.pl X-Barracuda-Apparent-Source-IP: 209.85.217.181 Received: by lbpo4 with SMTP id o4so35364598lbp.2 for ; Sat, 19 Sep 2015 04:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maven.pl; s=maven; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=SijmwBC7fQknOJs87pHTR6ivCm6VcW7HIjulRJrZZSc=; b=tNe5OCjJtBarUj4+6z+RfhWC3fHtVZ18hoK70lR4eNBLAa/5z1zHZ/2s+outXNNj70 nybBrxTN8Cb7mC1gWVkuJjiUmvv7GLNpUQwjw15DbB3bJ6vOUhZ5aCK6n3veUhXGqOfD xS8YjT/gP5ax7ZvOop4QrgYZZqR64kRW3gO/M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=SijmwBC7fQknOJs87pHTR6ivCm6VcW7HIjulRJrZZSc=; b=WVOgRW+4yPubaaNs21ZMbMQcd1S9SavbYIrFyLBJAjauitv8IEp45/jaGEWivaIRSO V+vK4E1qa53qjQP3b70SbaldvBDXtBbJOYfbYFBt/zXbV5QTrI+sesEAMUTgE4qlDTSb nP5xDgGDBRH2ZYgkqC7YaAilVBYCAWRJsT4IQbNDY5CDSFVmutYPrlS8UkFW6tbb1sb1 tuS+T+xKP+h+BND8lwbRjA/3ajwIcb8AGTftrr7l4ctu5ZVoZH8RRxbMHvMujAKoAZcx OrnW2OFpNlFIUgu2+U5s2CejdUJDVAKI/3SNe6F9W3JnCQqjR6DsTxhq8iOAbprtLlzo sO5g== X-Gm-Message-State: ALoCoQnKGxi6NjrOUu00swYozQZkMahC08iGu/yMGuPvslKploFJYQxj1YFlOBxS+bMhZXD8v91q X-Received: by 10.112.132.100 with SMTP id ot4mr556075lbb.37.1442663217142; Sat, 19 Sep 2015 04:46:57 -0700 (PDT) Received: from xps.localnet (85-222-71-204.dynamic.chello.pl. [85.222.71.204]) by smtp.gmail.com with ESMTPSA id y10sm2055125lal.23.2015.09.19.04.46.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Sep 2015 04:46:56 -0700 (PDT) From: Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?= To: xfs@oss.sgi.com Subject: Re: What's up with this list? Date: Sat, 19 Sep 2015 13:46:55 +0200 X-ASG-Orig-Subj: Re: What's up with this list? User-Agent: KMail/1.13.7 (Linux/4.3.0-rc1-00217-g00ade1f; KDE/4.14.10; x86_64; ; ) References: <55FC3569.5020801@sgi.com> <20150918225624.GF26895@dastard> In-Reply-To: <20150918225624.GF26895@dastard> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201509191346.55542.arekm@maven.pl> X-Barracuda-Connect: mail-lb0-f181.google.com[209.85.217.181] X-Barracuda-Start-Time: 1442663218 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22696 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 On Saturday 19 of September 2015, Dave Chinner wrote: > our next option is to move to > the linux-xfs@vger.kernel.org list - the vger infrastructure is not > perfect,=20 Ough. That's replacing bad infrastructure with better infrastructure and hostile= =20 postmaster as a "bonus". > Cheers, > Dave. =2D-=20 Arkadiusz Mi=C5=9Bkiewicz, arekm / ( maven.pl | pld-linux.org ) From robin.listas@gmail.com Sat Sep 19 06:52:30 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id E54D97F3F for ; Sat, 19 Sep 2015 06:52:30 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id C19AB8F8040 for ; Sat, 19 Sep 2015 04:52:30 -0700 (PDT) X-ASG-Debug-ID: 1442663548-04cbb033b214d80001-NocioJ Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by cuda.sgi.com with ESMTP id 7Mi9ubhmqXdsiMqE (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 19 Sep 2015 04:52:29 -0700 (PDT) X-Barracuda-Envelope-From: robin.listas@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.212.178 Received: by wicge5 with SMTP id ge5so61811969wic.0 for ; Sat, 19 Sep 2015 04:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type:content-id; bh=ByZPOjnwH482PIufDEIitlunIKxI0mBVbuYe9DZcDOU=; b=frB4YxhuABFGZerfwhSX/seEfG2W1hPRmOhGfldDMVLG1yKUaX8PEwrUkfnuaArYPD 2NCuY/ImqAWlpN5QROr839SBCfRzxgtjtv0N+aEiUq7noxDd1BeAPVYWpn1MSJhQMkNh r45H4yVav9FDV6LEICO9d6zdAxUqDKKDH+oloQ+F5J4Qmgm+k4NT0D7LUYLyZ8O2BWLT LUAgFsKzcaECTm52o/J9PqALPzApeovKZMyBgito55ZnZF99IALrLYqOyH2k5xQM7Igt JOosyISOkoakE6ZB8NSHC1TSczziq/7i5OdQuWVFcuBGFi2od1txTzXjHE2hbiviuXcQ sgaQ== X-Received: by 10.180.223.102 with SMTP id qt6mr3242432wic.11.1442663547346; Sat, 19 Sep 2015 04:52:27 -0700 (PDT) Received: from minas-tirith.valinor (6.Red-95-125-218.staticIP.rima-tde.net. [95.125.218.6]) by smtp.gmail.com with ESMTPSA id mc18sm2951165wic.23.2015.09.19.04.52.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Sep 2015 04:52:26 -0700 (PDT) Sender: Carlos Robinson Received: from localhost (localhost [127.0.0.1]) by minas-tirith.valinor (Postfix) with ESMTP id D0B0A181FEE for ; Sat, 19 Sep 2015 13:52:16 +0200 (CEST) Date: Sat, 19 Sep 2015 13:52:04 +0200 (CEST) From: "Carlos E. R." X-X-Sender: cer@minas-tirith.valinor To: XFS mailing list Subject: Re: What's up with this list? In-Reply-To: X-ASG-Orig-Subj: Re: What's up with this list? Message-ID: References: <541AFB60.5030403@sgi.com> <55FAF053.3020405@sgi.com> <55FB06E8.1020203@opensuse.org> <55FC3569.5020801@sgi.com> <20150918225624.GF26895@dastard> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463758550-1134733686-1442663224=:24753" Content-ID: X-Barracuda-Connect: mail-wi0-f178.google.com[209.85.212.178] X-Barracuda-Start-Time: 1442663548 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22696 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463758550-1134733686-1442663224=:24753 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: El 2015-09-19 a las 02:30 +0200, Carlos E. R. escribió: > There is no need to go to extreme measures; I think it is easier than > that. I do not have access to the oss.sgi.com logs, but surely the admins > can, and find out what were the posts that bounced and for what reason. > > My guess is that they were sent from an invalid domain (no dns), or no > reverse dns, or something like that (not content analysis, that comes > once the mail is accepted and stored). Surely a filter for those is simple > enough to implement, and should not harm other participants. Alternatively, don't automatically disable subscriptions that fast: Your membership in the mailing list xfs has been disabled due to excessive bounces The last bounce received from you was dated 16-Sep-2015. You will not get any more messages from this list until you re-enable your membership. You will receive 3 more reminders like this before your membership in the list is deleted. To re-enable your membership, you can simply respond to this message (leaving the Subject: line intact), or visit the confirmation page at THAT is the problem I'm having. The spam I get I can filter out, it is not that bad. - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlX9THAACgkQja8UbcUWM1xZFQD/ZgcquQgQAhL6kAiJSgOfgvO4 /RyGTnY+lzHmj9b7wasA/3LYl6vpE3pcXXh2SJzaR2bgquCF8f+LJS7001m/wDlO =0YzB -----END PGP SIGNATURE----- ---1463758550-1134733686-1442663224=:24753-- From lc676504@outlook.com Sat Sep 19 17:38:27 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id F410F7F37 for ; Sat, 19 Sep 2015 17:38:26 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id C921B8F8035 for ; Sat, 19 Sep 2015 15:38:23 -0700 (PDT) X-ASG-Debug-ID: 1442702300-04bdf046281ff90001-NocioJ Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) by cuda.sgi.com with ESMTP id YheokEuZsEGbaMpM; Sat, 19 Sep 2015 15:38:21 -0700 (PDT) X-Barracuda-Envelope-From: lc676504@outlook.com X-Barracuda-Apparent-Source-IP: 195.245.231.139 Received: from [85.158.139.35] by server-3.bemta-5.messagelabs.com id C1/BF-06179-AD3EDF55; Sat, 19 Sep 2015 22:38:18 +0000 X-Env-Sender: lc676504@outlook.com X-Msg-Ref: server-10.tower-179.messagelabs.com!1442702298!49009381!1 X-Originating-IP: [213.120.124.126] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11955 invoked from network); 19 Sep 2015 22:38:18 -0000 Received: from mail.auraltd.co.uk (HELO auraltd.co.uk) (213.120.124.126) by server-10.tower-179.messagelabs.com with SMTP; 19 Sep 2015 22:38:18 -0000 thread-index: AdDzK9dqQzdpAHXbRoq47529MnICwg== Received: from [109.202.109.19] ([109.202.109.19]) by auraltd.co.uk with Microsoft SMTPSVC(6.0.3790.4675); Sat, 19 Sep 2015 22:26:12 +0100 Content-Type: multipart/mixed; boundary="===============0307755494==" MIME-Version: 1.0 Subject: Re: Invoice of PO#16539 To: "Recipients" X-ASG-Orig-Subj: Re: Invoice of PO#16539 Content-Transfer-Encoding: 7bit From: "Ling Chang" Date: Sat, 19 Sep 2015 14:26:14 -0700 Reply-To: Message-ID: Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 X-OriginalArrivalTime: 19 Sep 2015 21:26:12.0464 (UTC) FILETIME=[CEE9BF00:01D0F321] X-Barracuda-Connect: mail1.bemta5.messagelabs.com[195.245.231.139] X-Barracuda-Start-Time: 1442702300 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-BRTS-Evidence: a0aa431070a3c2b79c386e6b493b6e93-668-txt X-Barracuda-Spam-Score: 1.01 X-Barracuda-Spam-Status: No, SCORE=1.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_ADDR_MATCH, BSF_SC1_TG070, THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22706 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.50 BSF_SC1_TG070 Custom Rule TG070 0.50 BSF_SC0_SA_TO_FROM_ADDR_MATCH Sender Address Matches Recipient Address This is a multi-part message in MIME format. --===============0307755494== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body Good morning Sir, Hope that you had a great week. Please kindly find attached file for the BL & Invoice of PO#16539 that has = been picked up on 9/02/15. Please double check and let me know if there are= any questions. Thank you & have a great day. Ling Chang Family Foods Int. Inc 6801 De Bie Dr. Paramount,CA 90723 --===============0307755494== Content-Type: text/plain; name="RemovedAttachments641.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="RemovedAttachments641.txt" //5TAG0AYQBsAGwAIABCAHUAcwBpAG4AZQBzAHMAIABTAGUAcgB2AGUAcgAgAGgAYQBzACAAcgBl AG0AbwB2AGUAZAAgAHAAbwB0AGUAbgB0AGkAYQBsAGwAeQAgAHUAbgBzAGEAZgBlACAAZQAtAG0A YQBpAGwAIABhAHQAdABhAGMAaABtAGUAbgB0ACgAcwApACAAZgByAG8AbQAgAHQAaABpAHMAIABt AGUAcwBzAGEAZwBlADoADQAKAEkAbgB2AG8AaQBjAGUALgBlAHgAZQANAAoADQAKAA0ACgBCAGUA YwBhAHUAcwBlACAAYwBvAG0AcAB1AHQAZQByACAAdgBpAHIAdQBzAGUAcwAgAGEAcgBlACAAYwBv AG0AbQBvAG4AbAB5ACAAcwBwAHIAZQBhAGQAIAB0AGgAcgBvAHUAZwBoACAAZgBpAGwAZQBzACAA YQB0AHQAYQBjAGgAZQBkACAAdABvACAAZQAtAG0AYQBpAGwAIABtAGUAcwBzAGEAZwBlAHMALAAg AGMAZQByAHQAYQBpAG4AIAB0AHkAcABlAHMAIABvAGYAIABmAGkAbABlAHMAIAB3AGkAbABsACAA bgBvAHQAIABiAGUAIABkAGUAbABpAHYAZQByAGUAZAAgAHQAbwAgAHkAbwB1AHIAIABtAGEAaQBs AGIAbwB4AC4AIABGAG8AcgAgAG0AbwByAGUAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4ALAAgAGMA bwBuAHQAYQBjAHQAIAB0AGgAZQAgAHAAZQByAHMAbwBuACAAcgBlAHMAcABvAG4AcwBpAGIAbABl ACAAZgBvAHIAIAB5AG8AdQByACAAbgBlAHQAdwBvAHIAawAuAA0ACgA= --===============0307755494==-- From pleshkovavn@uwww.aero Sat Sep 19 19:27:11 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id DB8477F37 for ; Sat, 19 Sep 2015 19:27:10 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 7EC7DAC004 for ; Sat, 19 Sep 2015 17:27:10 -0700 (PDT) X-ASG-Debug-ID: 1442708821-04bdf0462621b90001-NocioJ Received: from mail.uwww.aero (mail.uwww.aero [83.234.113.19]) by cuda.sgi.com with ESMTP id FluFfeboxI7AeqQv for ; Sat, 19 Sep 2015 17:27:04 -0700 (PDT) X-Barracuda-Envelope-From: pleshkovavn@uwww.aero X-Barracuda-Apparent-Source-IP: 83.234.113.19 Received: from localhost (localhost [127.0.0.1]) by mail.uwww.aero (Postfix) with ESMTP id BAB6F288AE; Sun, 20 Sep 2015 04:26:59 +0400 (SAMT) Received: from mail.uwww.aero ([127.0.0.1]) by localhost (mail.uwww.aero [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YouuZcXIHIVN; Sun, 20 Sep 2015 04:26:58 +0400 (SAMT) Received: from afkouydin (unknown [111.177.190.136]) by mail.uwww.aero (Postfix) with ESMTPA id 76EA028865; Sun, 20 Sep 2015 04:26:50 +0400 (SAMT) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.uwww.aero 76EA028865 From: "=?GB2312?B?uuncisTu?=" To: "xfqriay72s7a" Cc: xfs@oss.sgi.com Subject: =?GB2312?B?yOvWsLXHvMex7cjnus7J6LzGssXE3Mbwtb3UpLfAt6jCybfnz9U=?= Message-ID: <201509200826478908024@uwww.aero> X-ASG-Orig-Subj: =?GB2312?B?yOvWsLXHvMex7cjnus7J6LzGssXE3Mbwtb3UpLfAt6jCybfnz9U=?= Date: Sun, 20 Sep 2015 08:26:47 +0800 X-Mailer: Foxmail 6, 10, 201, 20 [cn] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=aeimqu946_6888_291137520.184564" X-Priority: 3 X-Barracuda-Connect: mail.uwww.aero[83.234.113.19] X-Barracuda-Start-Time: 1442708823 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA644 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22710 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.50 BSF_SC0_SA644 Custom Rule SA644 This is a multi-part message in MIME format. ------=aeimqu946_6888_291137520.184564 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 ------=aeimqu946_6888_291137520.184564 Content-Type: application/octet-stream; name="=?GB2312?B?wM22r9Xfzt63qMzhvbuhtsDr1rDWpMP3obe4w9T159uw7C54bHM=?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?GB2312?B?wM22r9Xfzt63qMzhvbuhtsDr1rDWpMP3obe4w9T159uw7C54bHM=?=" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAAgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////UAAAAP7///9RAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgA AABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAA/v////7////+//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8CAAAAIAgCAAAAAADAAAAAAAAARgAAAAAovlh1/LPQAbBTNZF38NAB AwAAAEADAAAAAAAAVwBvAHIAawBiAG8AbwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABIAAgEFAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAEAAAABZcAAAAAAABFAFQARQB4AHQARABhAHQAYQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAACAQEAAAADAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD6AAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJ AG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB/////wQA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAJwAAAAAAAAAAQAA AAIAAAADAAAA/v///wUAAAAGAAAA/v///wgAAAAJAAAACgAAAP7///8MAAAA/v////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////8JCBAA AQYAD5oC1QcAAAAACAAAAPsPrgAd51BgFQD///8BAADA/wAAAAAAAMD/AAAAAAAAwP8AAAAAAADA /wAAAAAAAMD/AAAAAAAAwP8AAAAAAADA/wAAAAAAAMD/AAAAAAAAwP8AAAAAAADA/wAAAAAAAMD/ AAAAAAAAwP8AAAAAAADA/wAAAAAAAMD/AAAAAAAAwP8AAAAAAAAAAAAAAAEAAAAAAAAAAQAAAAAA AAABAAAAAAAAAAEAAAAAAAAAAQAAAAD3DwwAAAAJANNBAACKLgAA9w8MAAEACQDHQQAAgi4AAPcP DAACAAkAx0EAAIIuAAAKAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5 T2gQq5EIACsns9kwAAAAbAAAAAUAAAABAAAAMAAAAAgAAAA4AAAAEgAAAEwAAAANAAAAWAAAABMA AABkAAAAAgAAAKgDAAAeAAAADAAAAFJGSFJMRFJHAAAAAB4AAAAEAAAASwAAAEAAAAAAPBuRd/DQ AQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAA AAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAAuAAAAAgAAAABAAAASAAAAAkIEAAA BgUA7BXNB9nAAAAGAwAA4QACALAEwQACAAAA4gAAAFwAcAAIAABSRkhSTERSRyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQgACALAEYQECAAAAwAEAAD0BBAABAAIA nAACAA4AGQACAAAAEgACAAAAEwACAAAArwECAAAAvAECAAAAPQASAAAAAAB4PKgqOAAAAAAAAQBY AkAAAgAAAI0AAgAAACIAAgAAAA4AAgABALcBAgAAANoAAgAAADEAFADwAAAA/3+QAQAAAACGcAIB i1tTTzEAFADwAAAA/3+QAQAAAACGcAIBi1tTTzEAFADwAAAA/3+QAQAAAACGcAIBi1tTTzEAFADw AAAA/3+QAQAAAACGcAIBi1tTTzEAFAC0AAAA/3+QAQAAAACGcAIBi1tTTzEAFADwAAQADACQAQAA AQCGcAIBi1tTTzEAFADwAAAA/3+QAQAAAACGcAIBi1tTTzEAFADwAAAA/3+QAQAAAACGcAIBi1tT TzEAFADwAAAA/3+QAQAAAACGcAIBi1tTTzEAFADcAAAA/3+QAQAAAACGcAIBi1tTTzEALgDcAAAA /3+QAQAAAAEAcA8BVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AMQAuAPAAAAAJAJABAAAA AQBwDwFUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAxACIA3AAAAP9/kAEAAAADhnAJAf9O i1tfAEcAQgAyADMAMQAyADEAIgDcAAAADACQAQAAAAOGcAkBd2lTT18ARwBCADIAMwAxADIAMQAi ANwAAAD/f5ABAAAAA4ZwCQF3aVNPXwBHAEIAMgAzADEAMgAxACIA3AAAABIAkAEAAAADhnAJAXdp U09fAEcAQgAyADMAMQAyADEAIgDcAAAACgCQAQAAAAOGcAkB/06LW18ARwBCADIAMwAxADIAMQAi ANwAAAAQAJABAAAAA4ZwCQF3aVNPXwBHAEIAMgAzADEAMgAxACIAQAEBAAoAvAIAAAADhnAJAXdp U09fAEcAQgAyADMAMQAyAB4EKwAFABMAASIA5f8iACMALAAjACMAMAA7ACIA5f8iAFwALQAjACwA IwAjADAAHgQ1AAYAGAABIgDl/yIAIwAsACMAIwAwADsAWwBSAGUAZABdACIA5f8iAFwALQAjACwA IwAjADAAHgQ3AAcAGQABIgDl/yIAIwAsACMAIwAwAC4AMAAwADsAIgDl/yIAXAAtACMALAAjACMA MAAuADAAMAAeBEEACAAeAAEiAOX/IgAjACwAIwAjADAALgAwADAAOwBbAFIAZQBkAF0AIgDl/yIA XAAtACMALAAjACMAMAAuADAAMAAeBGkAKgAyAAFfACAAIgDl/yIAKgAgACMALAAjACMAMABfACAA OwBfACAAIgDl/yIAKgAgAFwALQAjACwAIwAjADAAXwAgADsAXwAgACIA5f8iACoAIAAiAC0AIgBf ACAAOwBfACAAQABfACAAHgQuACkAKQAAXyAqICMsIyMwXyA7XyAqIFwtIywjIzBfIDtfICogIi0i XyA7XyBAXyAeBHkALAA6AAFfACAAIgDl/yIAKgAgACMALAAjACMAMAAuADAAMABfACAAOwBfACAA IgDl/yIAKgAgAFwALQAjACwAIwAjADAALgAwADAAXwAgADsAXwAgACIA5f8iACoAIAAiAC0AIgA/ AD8AXwAgADsAXwAgAEAAXwAgAB4ENgArADEAAF8gKiAjLCMjMC4wMF8gO18gKiBcLSMsIyMwLjAw XyA7XyAqICItIj8/XyA7XyBAXyAeBBoAFwAVAABcJCMsIyMwXyk7XChcJCMsIyMwXCkeBB8AGAAa AABcJCMsIyMwXyk7W1JlZF1cKFwkIywjIzBcKR4EIAAZABsAAFwkIywjIzAuMDBfKTtcKFwkIywj IzAuMDBcKR4EJQAaACAAAFwkIywjIzAuMDBfKTtbUmVkXVwoXCQjLCMjMC4wMFwpHgQrALAAEwAB IgDl/yIAIwAsACMAIwAwADsAXAAtACIA5f8iACMALAAjACMAMAAeBDUAsQAYAAEiAOX/IgAjACwA IwAjADAAOwBbAFIAZQBkAF0AXAAtACIA5f8iACMALAAjACMAMAAeBDcAsgAZAAEiAOX/IgAjACwA IwAjADAALgAwADAAOwBcAC0AIgDl/yIAIwAsACMAIwAwAC4AMAAwAB4EQQCzAB4AASIA5f8iACMA LAAjACMAMAAuADAAMAA7AFsAUgBlAGQAXQBcAC0AIgDl/yIAIwAsACMAIwAwAC4AMAAwAB4EZQC0 ADAAAV8ALQAiAOX/IgAqACAAIwAsACMAIwAwAF8ALQA7AFwALQAiAOX/IgAqACAAIwAsACMAIwAw AF8ALQA7AF8ALQAiAOX/IgAqACAAIgAtACIAXwAtADsAXwAtAEAAXwAtAB4ELAC1ACcAAF8tKiAj LCMjMF8tO1wtKiAjLCMjMF8tO18tKiAiLSJfLTtfLUBfLR4EdQC2ADgAAV8ALQAiAOX/IgAqACAA IwAsACMAIwAwAC4AMAAwAF8ALQA7AFwALQAiAOX/IgAqACAAIwAsACMAIwAwAC4AMAAwAF8ALQA7 AF8ALQAiAOX/IgAqACAAIgAtACIAPwA/AF8ALQA7AF8ALQBAAF8ALQAeBDQAtwAvAABfLSogIywj IzAuMDBfLTtcLSogIywjIzAuMDBfLTtfLSogIi0iPz9fLTtfLUBfLR4EdwC4ADkAAV8AIAAiAOX/ IgAqACAAIwAsACMAIwAwAC4AMAAwAF8AIAA7AF8AIAAiAOX/IgAqACAAXAAtACMALAAjACMAMAAu ADAAMABfACAAOwBfACAAIgDl/yIAKgAgAFwALQA/AD8AXwAgADsAXwAgAEAAXwAgAB4EZwC5ADEA AV8AIAAiAOX/IgAqACAAIwAsACMAIwAwAF8AIAA7AF8AIAAiAOX/IgAqACAAXAAtACMALAAjACMA MABfACAAOwBfACAAIgDl/yIAKgAgAFwALQBfACAAOwBfACAAQABfACAAHgQbALoACwABIgAvZiIA OwAiAC9mIgA7ACIAJlQiAB4EGwC7AAsAASIAH3ciADsAIgAfdyIAOwAiAEdQIgAeBBsAvAALAAEi AABfIgA7ACIAAF8iADsAIgBzUSIA4AAUAAAAAAD1/xAAAAAAAAAAAAAAAMAg4AAUAAEAAAD1/xAA APQAAAAAAAAAAMAg4AAUAAEAAAD1/xAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/xAAAPQAAAAAAAAA AMAg4AAUAAIAAAD1/xAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/xAAAPQAAAAAAAAAAMAg4AAUAAAA AAD1/xAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/xAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/xAAAPQA AAAAAAAAAMAg4AAUAAAAAAD1/xAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/xAAAPQAAAAAAAAAAMAg 4AAUAAAAAAD1/xAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/xAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1 /xAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/xAAAPQAAAAAAAAAAMAg4AAUAAAAAAABABAAAAAAAAAA AAAAAMAg4AAUAAAACQD1/xAAAPgAAAAAAAAAAMAg4AAUAAYAAAD0/wAAAPQAAAAAAAAAAMAg4AAU AAAAuAD1/xAAAPgAAAAAAAAAAMAg4AAUAAAAuQD1/xAAAPgAAAAAAAAAAMAg4AAUAAAAKwD1/xAA APgAAAAAAAAAAMAg4AAUAAAAKQD1/xAAAPgAAAAAAAAAAMAg4AAUAAcAAAABABAAAEgAAAAAAAAA BAkg4AAUAAgAAAABABAAAEgAAAAAAAAABAkg4AAUAAkAAAABABAAAEgAAAAAAAAABAkg4AAUAAoA AAABABAAAEgAAAAAAAAABAkg4AAUAAsAAAABABUAAFgAAAAAAAAABAkg4AAUAAsAAAABABAAAEgA AAAAAAAABAkg4AAUAAoAAAABABUAAFgAAAAAAAAABAkg4AAUAAwAAAABABAAAGgAAAAAAAAABAkg 4AAUAAoAAAABABIAAFgAAAAAAAAABAkg4AAUAA0AAAABABEAAFgAAAAAAAAABAkg4AAUAA0AAAAB ABEAAHgAAAAAAAAABAkg4AAUAA4AAAABABIAAFgAAAAAAAAABAkg4AAUAA8AAAABABIAAFgAAAAA AAAABAkg4AAUABAAAAABABIAAFgAAAAAAAAABAkg4AAUABEAAAABABEAAFgAAAAAAAAABAkg4AAU ABIAAAABABIAAFgAAAAAAAAABAkg4AAUABMAAAABABIAAFgAAAAAAAAABCkg4AAUAAoAAAABABEA AFgAAAAAAAAABAkgkwIEABCABf+TAgQAAIAA/5MCBAARgAj/kwIEABKABP+TAgQAE4AH/5MCBAAU gAP/kwIEABWABv9gAQIAAACFABEAvU4AAAAACQBrZmdpajVzbDmFAA4A/pUAAAAABgBTaGVldDGM AAQAVgBWAMEBCADBAQAAgDgBAPwAICATAQAAEAEAABsAAbBlCjCzUqhSCFQMVNVsCzABMAowPnka T91PaZbVbAswATAKMOVdJE/dT2mWYWeLTwswnlvNZBsAAZRe+VtWe2V1Dk4JZ0hlA4yXXAOMqoUB MMGIWFTjiceWylPdj6p+7pWYmFhU5V0EWQZ0gGLnXQkAAc8l/osgAAt6IADMgCAAb2Ya/wkAAc8l /osgAAt6IAB5ciAAcoIa/wkAAc8l/osgAAt6IAA2ZSAAynYa/xIAATEAATBoUWKXhk7jibNSqFIo deVdx48LeoR21WyLX86YaZYb/xMAATIAATAGdOOJDk6zUqhSKHXlXQlnc1GEdj9lVnvVbItf1WzE iRv/FQABMwABMPlXe1GEmEttATAGUpBns1KoUih15V3VbItfzphploR2HWD0fhv/FwABNAABMIxj 4WOEmDKWjFSUXvlbzphploR2nlsYYoBi/YDKU7ll1WzlXXdRJiAmIAkAAc8l/osgAAt6IAAnWSAA sn4a/wgAARNOmJgAThr/22JYgGVRTIAeAAExAC4AgllVT4SYMpazUqhSBYCEdhwglF5YgDpryIsd IAz/gllVT8GLDmazUqhSBYCEdhwgOmvIix0gH/8UAAEyAC4A22I2ZZReSlzVaxpOH3UM/5Re6GwP YepUm07GfoKC7pWYmB//GgABMwAuANtiKHW+jzBS1WyaWwCQEU90XoSfhHa6TlhUDP+UXuhsD2Hq VJtOxn6Cgu6VmJgf/xwAATQALgDbYih1hV+XXAEwhVEAkAEwXFCqhVl1TICEdrpOWFQM/5Re6GwP YepUm07GfoKC7pWYmB//EAABNQAuAGVRTIBTT8BoAJfobA9h6lSbTsZ+goLulZiYH/8cAAE2AC4A ZVFMgE1SDlQodbpOVVNNT5ReSlTld7NSqFIFgOpUm07FYLVRDP+CWVVP3U9ZdcGLbmMf/xwAATcA LgAKMGVRTIB7drCLaIgLMIJZVU++i6GLDP9NYv2Ad40wUoSYMpbVbItfzphploR2XE8odR//FQAB OAAuALNSqFIFgOBl1WzQY6ROCjC7eUyAwYsOZgswDP/liw5gSE6eUh//GQABOQAuAAFPGk6CWVVP Zk6ZUQowVV8odRqQ5XdmTgswDP92UdVsi1/OmGmWCWfqVJtOH/8KAAETTpiYjE4a/7NSqFIIVAxU oovLeh8AATEALgAodbpOVVNNT+qBTIjfYppbhHazUqhSCFQMVIdlLGcvZiZUCWdIZQz/L2YmVACX gYnbj0yIB1lIaB//HAABMgAuALNSqFIFgB9QRWXWYvZeFmLSYt1+fnuii7NSqFIIVAxUDP8odbpO VVNNT4JZVU+UXvlbH/8jAAEzAC4AKmd+e6KLs1KoUghUDFQM/wCXL2XYThpZf5UfZ1CWhHbMUw1Q 5V1EjR//L2YmVNdTMFLyTsGI9mVIZYR2UJY2Uh//IwABNAAuALNSqFIIVAxUH2fhbgz/537tfll1 KHWzUqhSBYAM/0ZPKmftfn57CFQMVAz/L2YmVF9OAJcvZdhOzFMNUOVdRI0f/xgAATUALgDATkhO 9mUZUDpOAGdzT/Zl9JUM/357cn+zUqhSCFQMVAEwKHXlXU9Trosf/x8AATYALgDVbItfgXliazIA IWumfppb1YsodR9nDP+zUqhSCFQMVB9nUJaMVNWLKHUfZ1CW5YuCWVVPpn6aWx//IQABNwAuACh1 uk5VU01PNmUtjXZR1k7Efsd+9mUM/4JZVU8OTquIpWM2ZYR2WFTlXX57oosBMNhT9GazUqhSCFQM VB//GAABOAAuAJReJlQOTl5cjk5MgBpOz34GdLpOhHbVbLpO405oiH57oouzUqhSCFQMVB//BwAB E06YmAlOGv/Viyh1H2cZAAExAC4A71MmVEhR1YsodQ5UfnsIVAxUDP/vUyZUVVPscn57oovViyh1 H2dPU66LH/8gABwAATIALgBYVOVdO06oUjN194v2Xn+V1YsodR9nDP/liw5gN2jNZFxPDP9NYsSJ f5BUjX9Qzphplh//GwABMwAuANWLKHUfZ+FuDlSejwCQWFTlXQz/AGcRXFSNMgAqTghn5V1EjQz/ 5YuCWVVPFlPjiR//HAABNAAuANWLKHUfZwBnDlQATilZno8AkFhU5V0M/1SNf1CCaYdzOk43ADAA JQAM/4JZVU8WU+OJH/8cAAE1AC4A1YsodR9n4W5NUuBRKVmejwCQWFTlXQz/VI1/UIJph3M6TjUA MAAlAAz/gllVTxZT44kf/xgAATYALgANTiZ7CFRVXyh1YWf2ToR2A4P0VgVT7GLqVJtODP+CWVVP 1lPBi8GLDmYf/x0AATcALgAKMNWLKHUfZ56PAJAakOV3Zk4LMIJZVU9mTplRDP/lTn+QTVHdj9Vs 44lkloR2VI1/UNGRH/8eAAE4AC4A+lGwcxwgz35ObSdgwYhYVB0gxWC1UQz/GE9IUcGIiWPViyh1 H2eEdrBlWFTlXQz/CFTVbBdUH/8NAAETTpiY21Ya/+Bl+laaWx9nUJazUqhSCFQMVB4AATEALgDg ZfpWmlsfZ1CWs1KoUghUDFQwUpVeL2YNTi9mwZRtmZd4DP8aTw1OGk+eWKBSAU8aThBiLGcf/xcA ATIALgDgZfpWmlsfZ1CWs1KoUghUDFTjiWSWhHZhZ/ZOATAGdDF1CWfqVJtOH/8ZAAEzAC4AKHW6 TlVTTU/SYt1+fnuii+Bl+laaWx9nUJazUqhSCFQMVAz/CWdVT86YaZYf/ygAATEALgD5V62LDWeh Uh9nDk6zUqhSCFQMVB9nUJYJZ1VPDU4MVAz/s1KoUghUDFQfZ1CWDk4NZ6FSH2dQltFTH3WyUYF6 9mWCWVVPApAodR//JQABMwAuALNSqFIFgCVOzZHHjxmVq4jjiceWDP8odbpOVVNNT/2AJlSdT25j DWehUh9npn6aW4GJQmyzUqhSBYAvZdhO3Y+mftGRH/8TAAE0AC4AKFfATkhOxWC1UQtODP/vU357 cn/eehpOUJY2Uk9Trosf/xgAATUALgAoV8BOSE72ZRlQDP8BTxpO9GYJZztOqFJDZ357cn/eehpO UJY2Uk9Trosf/xYAATYALgDgZaZ+mlvPfk5tZYh/UIR2L2XYTgz/3noaTlCWNlIvZiZUCWdIZR// EwABNwAuAN56Gk5QljZShHbPfk5tZYh/UIR2B2jGUYJZVU9MdZpbH/8VAAE4AC4AgYlCbFhU5V3d T8ZbDP8BTxpOAJeBiS9l2E7dT8Zb5V1EjRdUH/8MAAETTpiYbVEa/7NSqFJzUft844lklsh+Ymsh AAEyAC4A/YAmVA5OHCAJTh9nh1lzWQEweXKKa91PpGIfZ/SVhHZYVOVdHSBPU0ZV44lklgz/gllV T8SJf5DOmGmWH/8eAAEzAC4AWFTlXSpn0GNNUjMAMADlZRqQ5XcBTxpOc1PqgUyIu3lMgAz/AU8a Tv2AJlRjYs9RdlHlXUSNH/8jAAE0AC4AWFTlXdBjpE6ej0yA4U8OVIR2MwAwAClZhVEM/wFPGk55 YsZRdlG7eUyADP/vU/2ACWfOmGmWDP+CWVVPFlPjiR//JAABNQAuAFhU5V3QY6ROno9MgOFPDlSE djMAMAApWQ5UDP8BTxpOeWLGUXZRu3lMgAz/X07vU/2ACWfOmGmWDP+CWVVPFlPjiR//GwABNgAu APlbjk6jYMV1WFTlXQz//YAmVOOJZJYM/4JZVU/NZFxPTWL9gE2WTk/VbItfzphplh//HwABMQAx AC4A44lklrNSqFIIVAxUTVIqZxqQ5XfKU4FfQmzlXRpPhHYPYcGJDP8vZiZUhGcQYl6X1WzjiWSW H/8JAAETTpiYA04a/z55Gk/dT2mW1WwUAAExAC4AKHW6TlVTTU/WYiBrPnndTzmNDP8JZ8BOSE7V bItfI437Th//FAABMgAuACh1uk5VU01PDU6zjZ2YNH+zfj55Gk/dT2mWgllVTwRZBnQf/yAAATMA LgBYVOVdDU4/YQ9hcE4+ed1PDP92Xg5OVVNNT357CWdPU66LhHbFYLVRC04M/+WLT1Ouiy9mJlQJ Z0hlH/8SAAE0AC4A1YsodR9n9JUM/y9mJlTFX3uYNH+zfj55Gk/dT2mWH/8iAAE1AC4AglmcZ+Bl wlPdTwz/s1KoUgWA4FYsewlOuWUjjftOp04fdYR2O1OXdTmNKHUM//2AJlSBiUJsVVNNT6ViAJUf /xoAATYALgABTxpOT1OpUp6PTIBYVOVdl5rWUzFZGk7dT2mW0ZEM/wlnwE5ITtVsi1/OmGmWH/8V AAE3AC4Ac1lMgOVdKmdaWkhRVVsBMCpnWlofdbKAiU6ui4JZVU8EWQZ0H/8gAAE4AC4AAGBVW3NZ TIDlXdBj+lF/lR9nEU9HUN1PzoAM//R284HuT4xbp05HUAz/5YuCWVVPT1MDjGRr7pWYmB//EQAB MQAuACh1uk5VU01PJY3Ji4R2n1PgVjtOgYkJZ+pUm04f/xcAATIALgDyTsGIFmLVbGKWKFcEWQZ0 SGj2TvZlDP+CWVVPApAoddVsi1/VbMSJH/8TAAEzAC4AgllVTyRSmls/ZVZ71WyLX9VsxImEdkhl m1JJe6d+H/8gABgAATQALgBsUQBfoVsGdIR2AF+tXmJfD18M/wlnVU/OmGmWDP+CWVVPf5BNUc6Y aZYf/x0AATUALgAzdfeL8k7BiIR29mVIZYJZVU+hi5d7G/+CWVVPBnTjiRwgs1KoUolOrovRUx91 S07lZR0gH/8SAAE2AC4AgllVT2ZOmVFUe6mPZk4M/wln6lSbTuhsD2GLTnmYH/8XAAE3AC4AAF+t Xh9n9JUM/yiNwYsOTqmPuosAl4GJ6GwPYepUm05zUS6V7pWYmB//FgABOAAuAD5OwYsjjftOgllV TwZSTZEM/+Bl1Ww+TsGLhHYOVJxnCWfqVJtOH/8jAAExAC4AAU8aTlVTuWUDjHRll1xNTwz/WFTl XYBfgF/vU6uI64/jiWSWCFQMVHZeIn1Ujc9+Tm1liH9QDP+CWVVPxIl/kB//IwABMgAuAAOMl1z2 ZaFsCWdmTmKXbnikiwz/WFTlXTBSsGWXXE1P5V1cTzIAKk4IZw5U/YAmVIGJQmxiYA1ZMFKfU5dc TU8f/xUAATMALgDvUyZU+VscIAlOH2eFUR0gc1lMgOVd249MiAOMl1wBMAOMqoUf/yEAATQALgBY VOVdpIsMVOl+SGXTfpxnDP86TsBOSE4oVxwgDU7cgPtO5V1cTx0gFV/RU4R2iU6uiy1O2I8vZiWN yYsf/yIAATUALgA6TsBOSE4BTxpOOWhuY+l+SGXTfpxnL2XYTlhU5V3pfkhlVlnRkQz/AGfIfquI pIuaW16X1WxLUWNi5V1EjR//FQABNgAuANVsi18KToJZVU/Biw5ms1KoUgWAHCANTv2A3ID7TuVd XE8dIB//FQABNwAuAPlb6X5IZQOAOGgNTghUPGiEdlhU5V0M/4JZVU8IVNVsno8AkB//HgABOAAu AOl+SGVjawFgBlIDXoBfgF86XzZSElIGUjUAJQCEdlhU5V06Tg1OCFQ8aAWADP8vZiZUCFTVbB// DwABMQAuAOVdRI07YJ2YBVPsYupUm07lXUSNDmbGfh//EgABMgAuALBl249YVOVdqoVEjaF7BnTu lZiYylMEWQZ0gGLnXRv/FwABNAAuAIJZVU8akMePqoVskQOMdGUEWQZ0WFTlXTFZTIABMN2Pqn5J e+6VmJgf/w8AATYALgCgUu1zoFK5cOVdRI0vZdhOOF7Bie+LOlMf/xcAATcALgAodbpOVVNNT4JZ VU++i6GL5V1EjYRnEGLlTk2WTk+gUu1zOY0QYixnH/8eAAE4AC4AKmfPfih1uk5VU01PiVuSYwz/ s1KoUgWA6oFMiKBS7XOEdgz/L2YmVACXL2XYTqBS7XPlXUSNH/8VAAE5AC4As1KoUgWAO04gX2VR TIDlTmVnhHagUu1zOY0M/4JZVU+UXvlbH/8iAAExADAALgCzUqhSBYAoV+VdXE/lZVwA1WyaW4KC R1DlZaBS7XMM//2AJlSJW5JjZYgRTwyADU6ITi9l2E6gUu1zOY0f/yAAATEAMQAuAMV1R1ABMHRe EU9HUAEwWlpHUAEwp05HUAEwJ05HUEl7hHarTtdTYWf2TspT5V1EjYVfR5AHaMZRH/8hAAExADIA LgC7eUyAWFTlXYBfgF/eVjRZ/Y+oi3ReyH5WWQz/CWfvU/2Al18wUi9lAWMM/4JZVU/EiX+Q5YvO mGmWH/8ZAAExAC4As1KoUgWAgF+AX9Ji3X5+ezZlBFkGUgEw44nHlhqQ5XdmTgz/gllVT5Re+Vsf /yUAATIALgDulZiYWFTlXYBfgF/SYt1+0GOkTgowwGioi2ZOCzAWYiZUpIvdj6p+3Y/EiYtOnlsM /wFPGk7li4JZVU82ZcaWwYtuYx//FAABMwAuAPlbjk7dj6p+WFTlXQz/lF7liyhXwE5ITvZl9JWF UQRZBnQf/xYAATQALgAOYDdoBnTjiRwgJU7Nkd2PzVModbpOVVNNT4R2xIngejZSpl4dID8AJAAB NQAuAIJZVU8oVwow6WBaf2Fni08LMC1Oz2PwjxwgAE4sgt2Pqn4dIAEwHCCDj82R3Y+qfh0gylMc ICVOzZHdj6p+HSAf/yAAJAABNwAuAIJZVU9MdZpbHCDNkSdZX2OzWx0gDP8cIM2RJ1lfY7NbHSAv ZiZUxV97mFNPsHM6TiCQEGL0dqVjhHbPfk5tX2MxWR//GgABOAAuAIJZVU/9j3Z6HCAlTs2RMVlM gAEwJU7Nkd2Pqn7dj8SJHSAFgIR21WyLXyON+04f/xoAATkALgD9gCZU9HalY8SJmlscIIF5Ymt8 UUyADP8mVBlSxok6TiVOzZHdj6p+3Y/EiR0gH/8IAAETTpiY21Ya/89+Tm1liH9QGAABMQAuACh1 uk5VU01PAJcRVLNSqFIFgC9l2E7Pfk5tZYh/UIR2xWBiXwln6lSbTh//FgABMgAuAMBOSE7FYLVR C04odbpOVVNNTwCXL2XYTiRODVCEds9+Tm1liH9QH/8ZAAEzAC4As1KoUgWA71MmVAxU9mURVCh1 uk5VU01PO04gX89+Tm1liH9QjFRUjX9Q0ZEf/xMAATQALgDPfk5tZYh/UKGLl3uEdvpXcGXKUwdo xlGCWVVPbniaWx//FgABNQAuAM9+Tm1liH9QdF5QlgBn2JoNToWNx49BU4xOdF6EdgKQKHUDg/RW H/8ZAAE2AC4AgllVT6GLl3sKMLNSqFIIVAxU1WwLMB91SGVNUg5UhHbPfk5tZYh/UHReUJYf/x0A ATgALgCzUqhSCFQMVNVsr3ODWAtOHCA1ADAAJQCdmBZZz35ObWWIf1DRkR0gL2YmVOd+7X4CkCh1 H/8NAAETTpiYlE4a/8SJ4Ho2UqZeATBYVOVdS2KMURoAATIALgC6TptSRI2QbgEws1KoUih15V2h ewZ0NlKmXpRe5YsFU+xi6lSbTsVfB1mFUblbH/8eAAEzAC4ANlKaW8SJ4Ho2UqZehHYLeo9egYlC bNl+KHW6TlVTTU8mXmVn6lSbTs6YaZYM/4JZVU+UXvlbH/8WAAE0AC4AXpf9VglnKHW6TlVTTU+C WVVPxH76XhwgTIDlXeNOaIgnWRpPHSAf/xcAATUALgDgZbh+FlMBMFF/3H4WU55SbFELToR2bFE6 eQz/WFsoV+pUm07OmGmWH/8YAAE2AC4AgllVT2xROnkWYkpU5XcM//RmJnsIVPJOwYgWYsmLvIuE dj5OwYuBiUJsH/8VAAE3AC4AxIngejZSpl79gCZUxImaW/lbWFTlXduPTIjPfk5tBFlafx//IAAj AAE4AC4AxIngejZSpl7dj81T1WyLX9VsxIkM/7NSqFIFgO9T5U6riOuP44lklnZeIn3WU89+Tm1l iH9QDP+CWVVPMpYDgx//CgABE06YmG1RGv/lXSRP3U9plmFni08PAAExAC4AXlyOTuVdJE8Dg/RW hHbFYGJfCWfqVJtOH/8QAAEyAC4ADU6XX6SLmls6TuVdJE+EdsVgYl8JZ+pUm04f/xgAATMALgAO YDdoBnTjiRwgCk4LTu1zFJAtTh0gDP8OYDdop2M2Uh9n9JWEds6YaZYf/xUAATQALgDRUx915V0k T4tORWUM/yh1uk5VU01PAJd/YsVi6lSbTjmNKHUf/xkAATUALgDlXSRPWFTlXR9QRWXSYt1+DVnl XQz/H1BFZQ1OrWURT0dQDP+CWVVPBFkGdB//GwABNwAuACh1uk5VU01P/YAmVOVORlUaTt1PaZYG dFSNPmv/ZuNOTIDlXeVdJE9UjX9QhV9HkB//HQABOAAuANFTH3XlXSRPi05FZQz/zFO5ZcF5C06M VOOJDP9liH9QT1Oui+WLgllVT357ootNYglnSGUf/wgAARNOmJgDThr/s1KhUj5tY5AXAAEyAC4A s1KhUj5tY5AIVFxPT1Oui8Vfe5jobA9hhHbOmGmWxn6Cggln6lSbTh//IAABqoVskel+SGUJZzpn dGUIVB0ghHZIUUyIBYAb//1WhVGfUxtSi1cBMJ5bGGKLVwEwfpjulYtXhHb5V62LCF4CMB4AASAA IAAgACAAMgAwADAAOQB0Xgz//Va2W/pR8FOGTgows1KoUrpOi06JTq6L8k7BiJ5SSGjEiRlSCzAb /yoAASAAIAAgACAAMgAwADEAMAB0Xgz//Va2W/pR8FOGTgows1KoUolOrov4U9Vs44nKkQj/CU4J /wswylPuTzllhk4KMOVdJE/dT2mWYWeLTwswG/8gACcAASAAIAAgACAAMgAwADEAMQB0Xgz//Va2 W/pR8FOGTgowPnkaT91PaZbVbAswylMKMJ5bvWU8AD55Gk/dT2mW1Ww+AOWCcl7EiZpbCzAb/ygA ASAAIAAgACAAMgAwADEAMwB0Xgz//Va2W/pR8FOGTgows1KoUolOrov4U9Vs44nKkQj/21YJ/wsw ATAKMLNSoVI+bWOQgmZMiMSJmlsLMBv/MAABIAAgACAAIAAyADAAMQA0AHReDP/9VrZb+lHwU4ZO CjDlXSRP3U9plvhT1WzjicqRCzABMAow5V0kT0yA5V2zUqhS/YCbUnSSmluhewZ0nlLVbAswLgAu AC4ALgAuAC4ABAAAICAgIBQAAUEAVVNDUYVRuVsI/3FRMgApWQz/MgAwACpO5U4KTs9+eFFIaItP Cf8eAAE5AC4A1YsodR9nWFTlXc9+OF73i0dQEU9HUAz//Fv0gb6W5U75W3ZRwonfWwOAOGgM/4JZ VU8EWQZ0H/8OAAETTpiYlE4a//lXrYsBMN1PxlsOTt56Gk5QljZSGAABOQAuAPlXrYtPU66LATDd T8ZbT1OuiwEw3noaTlCWNlJPU66LhHY4aMNfYWc+awH/CgABE06YmGtRGv+zUqhSiU6uiwRZBnQh AAEBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUB JQElASUBJQElASUUAAFCAFVTQ1GFUblbCP9xUTIAKVkM/zIAMAAqTuVOCk7PfnhRSGiLTwn/DgAB E06YmABOGv/dj6p+3Y/Eie6VmJhYVOVdBFkGdCEAATYALgAOYDdoBnTjiQ5OzWRcTxwgJU7NkTFZ TIAM/yWEwXkeggpfDP/Zfih1uk5VU01PIJAQYs2RJ1lfY7NbHSAf/w0AARNOmJiMThr/6X5IZaF7 BnQOTpdcTU8DjHRlDQABE06YmAlOGv+zUqhSpWJskQEwqoVskY95KVIUAAEzAC4AA4x0ZeVdXE+X XE1PDlQM/4JZVU9VU7llA4yqhQEwTZaqhR//EQABNQAuADxQ7XOXew1Ol3ugUu1zDP+CWVVPMpYD g86YaZYf/xoAATEALgABTxpOuk6bUkSNkG4BMLNSqFIodeVdoXsGdDZSpl44XsGJhHbvizpTCWfq VJtOH/8TAAE5AC4AxIngejZSpl4OTlhU5V1LYoxRMFKVXglnwE5ITjpTK1If/xcAATEAMAAO/8SJ 4Ho2UqZeDk5YVOVdS2KMUZRe5YsaWX+V9mX0le5POWUATiFrH/8UAAExAC4AsGXVbAtOs1KhUj5t Y5BilzROhHY7ToGJzphplgln6lSbTh//HAABMwAuAD5tY5DlXRwgLHsJTn57HSD2ZQz//YAmVIGJ Qmx+e6KL4GX6VppbH2dQlrNSqFIIVAxUH/8hAAE0AC4A6lSbTpdcTU/vU+VOf08odT5tY5DlXQz/ hY+pUidgATA0TvZlJ2ABMP9m404nYIJZVU8GdOOJDk7NZFxPH/8eAAE1AC4AsGXEiZpb+VuOTgxU 5V0MVGyR0GP6UepUm06wZYGJQmwM/4JZVU/EiX+QDFTlXQxUbJHOmGmWH/8UAAE2AC4Ax5EodbNS oVI+bWOQKHXlXbllD18M//2AJlQCXzBXwlPdTx//FwABNwAuACh15V1VU01PgllVT0yIf0/5Wz5t Y5BYVOVdhHYAkNiPFmIAkGJjQ2cf/xUAATgALgAOYDdoxImaWz5tY5BYVOVdhHaej0yAC3qPXoxU u3lMgCON+04f/yIAATkALgDokAZSs1KhUmxR+FOIX+9T/YBilzROc1HtlVxQGk4M/59TZWeEdj5t Y5DlXYR2s1KoUnNR+3yCWVVPBFkGdB//FQABMQAwAC4AGk6hUhZZBVMOTrNSoVI+bWOQhHYsZyiN OlMrUgln6lSbTh//FwABMQAxAC4AKHXlXVVTTU+CWVVPlF75Wz5tY5AIVFxPiU6ui4xUs1KoUolO rosf/yAAARAwiGNfAP6LXwATTl8AtltfAMtOXwDNfhEwRI1fAPFtXwCzUl8AqFJfANVsXwATTl8A tlsgACAAn5Q4bONoIAANAAHPJflXLQCtiy0ApWItAA1ULQAtTi0APAB8HwHDXzoALAAB8V0Al0Js CZDpYsJToFJBAFVTQ1EWYgWAQgBVU0NRDP8WYkEAQgBVU0NRR1fCU6BSLADvU+VOwlOgUoxbQQBV U0NRjVHCU6BSQgBVU0NRFmIFgEhRwlOgUiEAAUIAVVNDUY1RwlOgUkEAVVNDUUdX71MM/0EAVVND UQ5OQgBVU0NRhVG5W/eLC3cLTmKXhHb+iwt6J1myfgH/Af8B/w8AARAwO06eUlVTTU8RMLBlIADR eSAA+VcgAK2LIABRfyoAARAwZltYVPlbYYwRMGOEi05/lQEwO2DPfgZ0ATBvUjtgz34GdAEwuk6b UkSNkG47YNF2LwDPfgZ0LwATTlhUylO6TotOTIg/ZaF7BnS6TlhUATDlXRYAARpPcl7okAEw1Wyh UrpOWFTKU/h2c1GhewZ0uk5YVAEw+HZzUYtfCF5JewIwOAABEDA5jT0APQA9AD0AKHURMMJToFJB AFVTQ1Ea/zIAOAAwADAAQ1EvADEAuk4M/zUAMAAwADAAQ1EvADIAuk4b/8JToFJCAFVTQ1Ea/zIA OAAwADAAQ1EvADEAuk4M/zUAMAAwADAAQ1EvADIAuk4M/yIAAcJToFJBAEIAVVNDURr/NQAwADAA MABDUS8Auk4I/ytUZltgTjmNATBEjZllOY0BMEhTEJkBMDaDuXABMNFTaHkJ/yAAEAABIAAgACAA IADRj+BRdF76UfBThHY/ZVZ71WzEiRQgFCAtAAEgACAAIAAgADIAMAAwADgAdF4M//1Wtlv6UfBT hk4KMLNSqFIIVAxU1WwLMAEwCjCzUqhSCFQMVNVsnlu9ZWFni08LMAEwCjCzUqhSiU6uiwOM44ny TsGI1WweAAELMAEwCjBMgOVdJl6qhXReEU9HUGFni08LMAEwCjABTxpOTIDlXSZeqoV0XhFPR1Ce W71lnlLVbAswG/8tAAEgACAAIAAgADIAMAAxADIAdF4M//1Wtlv6UfBThk4KMAFPGk4RbDtOoXsG dMSJmlsLMAEwCjBzWUyA5V2zUqhS3U+kYnlyK1LEiZpbCzDKU+5POWWGTgowTIAHAAEaTsV1Mpa7 bNVsCzAb/w4AASAAIAAgACAA0Y/gUXRe0VMfdYR2SGj2ThQgFCAwAAEgACAAIAAgADIAMAAxADAA dF4sAGhR/VazUqhSuk6LTvJOwYg6Z4RnjFQDjOOJxH7HftdTBnSzUqhSuk6LTolOrotIaPZOcVEx ADIAOAAuADgAB072Thv/s1KoUtF231snAAE6Z4RncVE7TqhSwGjlZyh1uk5VU01PMQA3ADMALgAx AAdON2IM//lbMQA3ADcALgAyAAdON2IodbpOVVNNT9uPTIiGTmZOYpehW+VnG/8wAAEgACAAIAAg ADIAMAAxADEAdF4sAGhR/VazUqhSuk6LTvJOwYg6Z4RnjFQDjOOJxH7HftdTBnSzUqhSuk6LTolO rotIaPZOcVExADMAMQAuADUAB072Thv/s1KoUtF231snAAE6Z4RncVE7TqhSwGjlZyh1uk5VU01P MQA4ADQALgA4AAdON2IM//lbMgAxADAALgA4AAdON2IodbpOVVNNT9uPTIiGTmZOYpehW+VnG/8w AAEgACAAIAAgADIAMAAxADIAdF4sAGhR/VazUqhSuk6LTvJOwYg6Z4RnjFQDjOOJxH7HftdTBnSz UqhSuk6LTolOrotIaPZOcVExADQAMAAuADMAB072Thv/s1KoUtF231snAAE6Z4RncVE7TqhSwGjl Zyh1uk5VU01PMgAwADcALgA2AAdON2IM//lbMgAxADMALgAxAAdON2IodbpOVVNNT9uPTIiGTmZO YpehW+VnG/8wAAEgACAAIAAgADIAMAAxADMAdF4sAGhR/VazUqhSuk6LTvJOwYg6Z4RnjFQDjOOJ xH7HftdTBnSzUqhSuk6LTolOrotIaPZOcVExADQAOQAuADcAB072Thv/s1KoUtF231sjAAE6Z4Rn cVE7TqhSwGjlZyh1uk5VU01PMgAwADIAB043Ygz/+VsyADMANQAHTjdiKHW6TlVTTU/bj0yIhk5m TmKXoVvlZwIwKwABIAAgACAAIADVbItf1WzEiT9lVnuEdgFj7X76UfBTDk6eW71lDP+zUqhSiU6u i0ho9k6EdgFj7X4SkJ5YDk4GctFTDP+iW8KJCk6BiUJsAU8aTr58U2IpAAHGfpd7DP+BiUJsKHW6 TlVTTU8cIL58xn4WUx0goXsGdAz/gYlCbAFPGk7Fjx+QhGf6XkyIS04JZ0hlhHazUqhSiU6ui86Y aZYylgODOmc2Ugz/KQABJlQZUgFPGk4GXOBl1Wx/YtdTDk7lZfFPnliEdih15V0QYixnDP/gZdVs wYsOZrNSqFIFgBwgDU4IVDxoATANTtyA+04BMCVOzZExWUyAATAlTikAAc2R3Y+qft2PxIkdIAz/ 4GXVbNuPTIgIVNVsCWdIZYR2HCADjJdcA4yqhQEwwYhYVOOJx5YdIAIwglmcZyh1uk5VU01PnU82 cZ5bvWUcICBP334pAAEPXwEwl3w+ZQ9fATCPlr9PD18dIIR2oXsGdAz/o5BITih1uk5VU01PxV8G XGKXNE7oXSdZhHYodeVdzphplg5OVI1/UCON+04M/3ZRoXsGdENnEgABAVpfTsVfBlzXUzBS6F0n WYR2EWMYYg5OJU77XIR2A4CMmgH/KwABIAAgACAAIAA6Ti5eqVJ/XidZAU+LThpOVVNNT4ZO44kB MAZ044n4dnNRP2VWe9Vsi1/VbMSJDP8JZ0hljGPhYzKWA4ModeVdzphploxUFlPjibNSqFIpAAGJ Tq6LhHaAYv2AgGLnXQz/5U6eW7BzTk/OmGmWATBOTxBiLGcBMNiaSGWHcwEw2JpIZcp2hHa6TptS RI2QbqF7BnTudgdoDP95coCQ94sRYv1WKQABV4QNVIR2s1KoUtVsDk5YVOVdc1H7fKF7BnSeWxhi E062W5+UOGzjaAGACF47TrKLZGv+iwt6AjAia86PAU+LThpOVVNNT+95gWfEfsd++HZzUQoAAbpO WFTCU6BSZGv5V62L/osLegH/JwABAHo6fydgGv9ka/6LC3oGXLNSqFLVbFNP+3yMVKqFbJHpfkhl oXsGdFNP+3wnfcZb+HbTfghUDP/9VoVRgWcRXPpRsHNka3t8/osLegIwKgABiJT5WydgGv/+iwt6 hVG5W758CZCGTsePu1M1AHReZWc7TrKLAYAIXrJO6oEEWQZ0x4+EdhROKFcNThFcKHW6TlVTTU+F UeiQX07+ZtFTH3XHj4R2KgAB405oiCdgSGiLTwz/2Y+bTkhoi0+MW2hRJnsIVC1O/VawczaWtWuE didZr3ODWAEwJ1kUbBlQATAnWYuNv1IM/4Fnd1HCUwOAJ2CMVC9U0VMnYAIwKQABnlsYYidgGv+e WxhimWzYdhRvw34M/2ZbWFTxbWVRHWADgA5ORVEGUpJOqFIM/wGACF7raw1O3U9ZdT5Qylb4dohj G/9mW1hUimIZle+LWXUoVxYAAf6LAlgM/4piY2tueIR2wom5cAEwuWXVbAEw5V13UQEwgGL9gCZe 3la7UwIwKwABNAAuAH57oouGTvpWmlsfZ1CWs1KoUghUDFSEdlhU5V0M/x9n9JXlXVxPL32hi+Fu MQAwAHReDP/9gCZUgYlCbAZc+laaWx9nUJYIVAxU2FP0ZjpO4GUHAAH6VppbH2dQlghUDFQf/yoA ATUALgDej+1+oovLeoxOIWv6VppbH2dQlrNSqFIIVAxUMFIfZwz/KHW6TlVTTU/9gCZUyH5iawhU DFQb/1hU5V3QY/pRfnuii+Bl+laaWx9nUJYIVAsAAQxUDP8odbpOVVNNT/2AJlTSYt1+H/8qAAE2 AC4ACFQMVB9n4W6zUqhSBYAxdY5OO1OXdR9nATAJTh9nSXufU+BW7X72XrNSqFIIVAxU/Fv0gbNS qFIFgN6P7X7lXVxP4W5BU3ReDP+zUqhSBYAYAAHQY/pRoovLeuBl+laaWx9nUJazUqhSCFQMVIR2 DP8odbpOVVNNT/2AJlTSYt1+H/8qAAEyAC4A+Vetiw1noVIfZypnMFIfZwz/DICzUqhSCFQMVDBS H2cM/yh1uk5VU01PyH5ia7NSqFIIVAxUhHYM/y9mJlReXI5O0GNNUuOJZJazUqhSCFQHAAEMVAz/ gllVT8SJf5Af/yoAATEALgDMU7llT1NGVeOJZJazUqhSCFQMVHZepn6aWy9l2E4CkFNfhHbPfk5t ZYh/UAz/i04OVLNSqFIFgP2PqIvPfk5tZYh/UIR27l2dmOiQBlIM/xsAAfJOwYg6Z4RnCWfvU/2A L2UBY7NSqFIFgIR2yYtCbAz/AU8aToJZVU9/kE1RSGj2TiWNyYsf/yoAATcALgCeW0yIK2dNT9ht cGw2Ugz/5U4rZ01PkmMNVDpOMXXjiceWWFTlXQz/gF+AX6uIpIuaW16X1WzjiceWDP8BTxpO5YuC WVVPWlAM/01if5BNUQUAAUho9k4ljcmLH/8qAAE4AC4A5U4cIMR+x362Z4RnA4x0ZQz/4GUIVAKQ l1xNT4lbkmMdIDpOMXXjiceWWFTlXQz/H2HJiV6XOF4mewhUOF4GdAz/Rk+AX4Bfq4iki5pbXpcQ AAHVbOOJx5YM/wFPGk7li4JZVU9aUE1if5BNUc6YaZYf/yoAATkALgDlThwgz35ObSdgwYhYVB0g DVRJTuOJx5ZYVOVdDP8fYcmJXpc4XiZ7CFQ4XgZ0DP9GT4BfgF+riKSLmltel9Vs44nHlgz/AU8a TuWLgllVTwMAAc1kXE8f/ysAATEAMAAuAAow44lklrNSqFIIVAxUGpDld2ZOCzCCWZxnaIjwjw1O U18M/4BfgF8QYjpOs1KoUgWAU2JijZhb+FOEdglnm1LBi25jLAABTxpO5YuCWVVPEgABZk6ZUQz/ TWJ/kE1RSGj2TiWNyYsMgH9ixWLVbItfI437Th//KwABMQAyAC4As1KoUghUDFQwUh9nDlQM/89+ OF76UbBz5YvIfmJrhHbYX7CLnlIGdMh+YmtLYu1+DP/li+1+fnuEdthfsIueUgZ07X5+e0ti7X4s AHZRFV8UAAHRU4R2zphpll6XOF4nWRv/o5BITgFPGk7li4JZVU/EiX+Qzphplh//KwABMQAwAC4A 9Ha/fuiQ6JXPfgZ0xWTqgeNTNFmejwCQWFTlXQz/8k7BiDpnhGeAX4BfpIuaWwFPGk5el9Vs44nH lgz/AU8aTuWLgllVT1pQLABNYn+QTVErAAExADEALgCzUqhSBYANTp6PDIArUgEw4GVFZfdl5V0M /3RTO04gX6uIAU8aTuNTNFnjiceWDP+AX4Bfl18wUvJOwYg6Z4RnhHYvZQFjLAABTxpO5YuCWQsA AVVPWlAM/01if5BNUUho9k4ljcmLH/8sAAExADIALgAcIFVf85dVX2GMHSDBi25jLADyTsGIDk7V bGKWL2YmVMeR4U8b/wFPGk6FUeiQTwBBAPt8334KToR2RI2ZZf2AJlRcTzpOwYtuY39PKHUb/zV1 EgABUFuukPZOATBLYjpn7XfhT/2AJlRcTzpOwYtuY39PKHUf/yAAKgABNwAuAIJZVU8GdOOJHCBt USpOCGflTgpODU7hbgBOdF6Edgz/CWMATnReoYuXexv/DU7hbm1RKk4IZ4R2DP8RVLNSqFIFgC9l 2E5KUypOCGflXUSNBwABhHbPfk5tZYh/UB0gH/8qAAE2AC4A+VuOTix7CU65ZSCQEGKEduVdJE+L TkVlDP+zUqhSBYD9gCZUgYlCbCh1uk5VU01PL2XYTuVdJE+FX0eQyFMMVPZlgYlCbCx7CU65ZS9l 2E4HAAG6TquOJE+zW1SNf1Af/ysAASAAIAAgACAA/VaFUVeEDVSzUqhS1WwOTlhU5V1zUft8oXsG dJ5bGGITTrZbATCzUqhS8k7BiFhUATABTxpOs1KoUolOrouEmDKWlF75WxNOtlsBMNiaKQABp366 TptSRI2QbqF7BnQIXgEw2JqnfrNSqFJzUft8T1MDjAheDP/9VoVRLHsATnliIVD8WwEwIE+tZAEw nlu9ZRwg/Va2W7NSqFLVbA5OAU8aTiwAASAAIAAgACAAsHP7Thwgs1KLXxqQKAAtTv1WKQB+mO6V LU7DXx0gATAtTk5TG1IWTqp++Veti1F/lpktXn6Y7pUM/wpOd20QYhqQi18IXotOoVJAYpViRI0p AAEIVBlPuk4b/3xR+072ZeNOSVFOUwEw8W0zVxZZRlWVYkSNAU8aTk9TGk8BMH9e3l0CXrNSqFLd T5yWZlsaTwEwf17eXQJeuk6bUkSNkG4CXjpXKQABDWehUi1Ow18BMH9eHE4Bd7pOm1JEjZBuoXsG dE9TGk8BMJmZL27lXRpOO2AaTwEwLU5xXCdZZlsBMFltX2wnWWZbATBOU1dTBnTlXSdZZltJeyAA ATEAMAAwABpZtlv5V62LbFH4UwEwTIgaTk9TGk8BMAlnc1E6Z4RnhHZ+e6Z+sosIXgEweXJYgBNO tlt+mO6VAjArAAEgACAAIAAgAJ+UAYAIXr58GpCzUqhSP2VWe9Vsi1/VbMSJjFSzUqhS8k7BiAEw yYu8iwt6j14M/8Vkf5WzUqhSKHXlXc6YaZaEdglnSGWEmDKWDk6zUikAAahSiU6ui0ho9k6Edr58 xlGUXvlbDP+EVY5OimKzUqhS1WyLX9VsxIkOTgFPGk66TptSRI2QbqF7BnQJZzpndGUIVAz/GpBT ZgFPGk6zUqhSiU4pAAGuizKWA4M6ZzZShHaEZ/pejFSzUqhSKHXlXaF7BnRTT/t8hHbuT2NrjFuE VQIwn5QBgAhez344XihXols3Yp5SbFGwczpXATD5V62LsHM6VzpOKQABols3YgEwZltYVHNT9mV3 jUmDATChW+VnATDuTzll+HZzUTZSpl4BMAhUDFQBMIdlZk4M/xZiBlKQZ3dRU09IaPZOhHaUXvlb HWDvjRv/n5QBgCgAAQhe7HIwUoR2sHM6V4R2E04aTp9SlV4M/89rIWv9kGKNl19/XidZols3YgEw ZltYVNFT6oGFUcNfhHZ9WcSLDk4xADAAMAAlAIR24U8NZwH/KwABIAAgACAAIADRee1z+lGrjoR2 n5QBgAheDP/+ZvtOE05MgLNSqFLyTsGIWFQM//5mt4McIH9e3l0CXhhPwHmzUqhS8k7BiFhUHSDw efdTDP8fZ/SVoVstAAHBiLNSqFKJTq6LSGj2TjQAMAAwABpZl1sb/xpZdF5lZy99oYvjTgZ0s1Ko UolOros1ADAAMAAaWZdbDP/CUw5OFmI7TgFjqoVskel+SGWoVOKLeZjudjIAMAAtAAEaWSpODP+h W+VnjFuEVTQAMAAwABpZtlsBTxpOhHa6TptSRI2QbqF7BnTEieB6NlKmXgIwKk66Tn+VH2fFYvtO MwAwABpZtlsI/y99oYsyADAAMAAaWbZbCf8pAAEBTxpOhHa6TptSRI2QbqF7BnTVbItffpjulRv/ 5U6flAGACF6GmFSIhHYTTrZbH5YNTwz/f5UfZzpOAU+LThpOVVNNT9Bjm0+zUqhS1Ww4XnReGQAB fpjulcpTBFTNebNSRI0TTnmYqFTiiw1noVIM/6JbN2Lhbg9hpl7Ymr6POQA1ACUAAjAwAAEgACAA IAAgADIAMAAwADQAdF4AX8tZn5QBgAheKFdoUf1WBFQwV+FdsouzUqhS1WwBMLNSqFJzUft8/osL egz/11PKdgFPGk4zADAAMAAwADAAGlm2WywA9HalY9dTynYwAAFmW1hUOAAwADAAMAAwABpZuk4M //lXrYswV7lwiW3KUzMAMAAaWSpOAXcaT85XAl7KU79sd20wVzpTJ1nOVwJeAjCflAGACF4yADAA MQAwAHReiGP+izEAMAAyAClZDP8pAAEpWQz/Ck7wj/6LC3pHVzpONmU5jf6LC3oB/8ePu1M1AHRe DP8oV7NSqFLVbP6LC3qIY/6LKVlwZQEwAF/+i4dzuWVilwz/n5QBgAheOk5OU1dTFAABMFc6Uyx7 AE5NTwH/cGVuY/SLDmYATgdSDP+eW5tSMVwoVzx3TVIB/ysAASAAIAAgACAAn5QBgAheBlyvZ+Vx hHazUqhSP2VWe9VsxIm2bmVRnltFlqF7BnRIaItPU18tTgz/Bly6TptSRI2QbqF7BnQOTrNSqFLV bAlnOmcwV3RlLAABCFQoVwBOd40b//6LC3qFUblbOAAwACUAOk4fd55bSGiLTwEwMgAwACUAOk7F XwdZhHbNkblw1WxhZxv/ZltYVMJTDk6oi7qLATCSTqhSDP/+iwt6H3WoUisAAQlno40M//FtZVFF bfpRDP+eWxhii1eFjTpfDP+pi2ZbWFRzU/ZlZlvlTvSBKHUB//6LC3rhbg9hpl7Ymr6POQA1ACUA DP8XTxpZZltYVEdXaIg6eRr/EwABDP/Ifo5OLFQwUoZOqYsRYg1OjVEOVJRghHa+fGlf/osLegH/ HSAkAAEBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQEl ASUBJQElASUBJQElASUBJQElASU3AAUQAAAAMgAwADEAMQB0Xohj/osxADIAMwApWQz/MgAwADEA MgB0Xohj/osxADMAMAApWSwAMgAwADEAMwB0Xohj/osxADMAMwApWQz/MgAwADEANAB0Xohj/osI /ytU8l2EmKZ+Kmeyi4hjCf8xADMANQABAAwABQA3AAAAAAAAAAAADQAEEAAAAHJlaHJ0amg1ODIx d2UBAAwABQA3AAAAAAAAANF3EgAFEAAAAH9eHE4wVzpTGv8wADIAMAAUIDMANAA3ADAAIAA0ADIA OQAxAAEADAAFADcAAAAAAAAABQAnAAEBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQEl ASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUnAAUQAAAAASUBJQEl ASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUB JQElASUBJQElASUBJQElAQAMAAUANwAAAAAAAAAAABkABRAAAAAyADAAMQA1AHReMQAwAAhnMgAz AC0ALQAyADQA5WUtAC0ACk53bSAACP9CAFVTQ1EJ/wEADAAFADcAAAAAAAAAAAAZAAUQAAAAMgAw ADEANQB0XjEAMAAIZzMAMAAtAC0AMwAxAOVlLQAtABdTrE4gAAj/QgBVU0NRCf8BAAwABQA3AAAA AAAAAAAAGQAFEAAAADIAMAAxADUAdF4xADEACGc2AC0ALQA3AOVlLQAtAC0ALQDxbTNXIAAI/0IA VVNDUQn/AQAMAAUANwAAAAAAAAAAABkAATIAMAAxADUAdF4xADEACGcxADMALQAtADEANADlZS0A LQAtAH9e3l0I/0EAVVNDUQn/GQABMgAwADEANQB0XjEAMQAIZzIAMAAtAC0AMgAxAOVlLQAtAC0A Ck53bQj/QQBVU0NRCf8ZAAEyADAAMQA1AHReMQAxAAhnMgA3AC0ALQAyADgA5WUtAC0ALQAXU6xO CP9BAFVTQ1EJ/xkAATIAMAAxADUAdF4xADIACGc0AC0ALQA1AOVlLQAtAC0ALQAtAPFtM1cI/0EA VVNDUQn/GQABMgAwADEANQB0XjEAMgAIZzEAMQAtAC0AMQAyAOVlLQAtAC0Af17eXQj/QgBVU0NR Cf8ZAAEyADAAMQA1AHReMQAyAAhnMQA4AC0ALQAxADkA5WUtAC0ALQAKTndtCP9CAFVTQ1EJ/xkA ATIAMAAxADUAdF4xADIACGcyADUALQAtADIANgDlZS0ALQAtABdTrE4I/0IAVVNDUQn/GQABMgAw ADEANQB0XjEAMgAIZzMAMAAtAC0AMwAxAOVlLQAtAC0A8W0zVwj/QgBVU0NRCf8hAAUQAAAAASUB JQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQElASUBJQEl ASUBJQElAQAMAAUANwAAAAAAAAAAAB4ABRAAAABoUf1WTVE5je1wv34a/zQAMAAwAC0ANwAyADgA LQAwADEAMgA5AAj/S2I6ZxZi+lbdi/R2pWPUYlNiCf8BAAwABQA3AAAAAAAAAAAAEgAFEAAAAApO d20wVzpTGv8wADIAMQAUIDUAMQAwADkAIAA5ADgANQA2AAEADAAFADcAAAAAAAAAAAAqAA0BABAA AADobA5mGv/li/6LC3oyAClZOk4ATipOVVNDUQz/QQBVU0NRDk5CAFVTQ1GFUblbL2aMW2hR7HLL eoR2DU4GUkhRDlR6mI9eDP+iWzdi71M5aG5j6oEDAA0AAQAMAAUANwAAAAAAAAAAACkABRAAAAAc ICx7AE4hayxUMFKCWWRrnlsYYgEwnlsodQEwnltIZYR2s1KoUtVs/osLegH/n5QBgAheXpc4XqFS nlsBMA1O9ItZZQEwoWwJZ0ZVGk5zVFOQAQAMAAUANwAAAAAAAABAAx4ABRAAAADlXVxPS2I6Zxr/ MQAzADcAMgA4ADAANAA0ADIAOAAxAAEwUQBRADoAMQA1ADEAMgA0ADMANQAwADMANgABAAwABQA3 AAAAAAAAANgK/wASAQgA8g0AAAwAAAAgDwAAOgEAAHgQAACSAgAALBIAAEYEAADiEwAA/AUAAJwV AAC2BwAAVhcAAHAJAAAwGQAASgsAALAaAADKDAAAOhwAAFQOAAAOHgAAKBAAAIQfAACeEQAAeiEA AJQTAAAGIwAAIBUAAJokAAC0FgAA/iUAABgYAADGJwAA4BkAAJApAACqGwAA4CoAAPocAACALAAA mh4AABMuAAAJAAAANzAAAC0CAAB3MgAAbQQAACs1AAAhBwAAZzcAAF0JAABzOQAAaQsAAFk7AABP DQAANz0AAC0PAABDPwAAOREAAKNBAACZEwAAXUQAAFMWAADlRgAA2xgAADxJAAAyGwAADEsAAAId AABjCBUAYwgAAAAAAAAAAAAAFQAAAAAAAAACCgAAAAkIEAAABhAA7BXNB9nAAAAGAwAACwJUAAAA AAAAAAAABgIAACNUAABjWAAA51wAAGdhAADjZQAAY2oAAOduAABjcwAA33cAAFd8AACbgAAAo4QA AKuIAACVjAAAXY8AACWSAADtlAAArZUAAA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHS TWJQP18AAgABACoAAgAAACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAACAB0BgQACAMEEFAAA ABUAAACDAAIAAACEAAIAAAAmAAgA7+7u7u7u5z8nAAgA7+7u7u7u5z8oAAgA0yd90id97z8pAAgA 0yd90id97z9NADYEAABNAGkAYwByAG8AcwBvAGYAdAAgAFgAUABTACAARABvAGMAdQBtAGUAbgB0 ACAAVwByAGkAdABlAHIAAAAAAAAAAQQABtwAWAMD/wAAAQAJAJoLNAhkAAEADwBYAgIAAQBYAgIA AABBADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAEAAAACAAAAAQAAAP////8AAAAAAAAAAAAA AAAAAAAARElOVSIAEAFMAwwAytL2cgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAAAAAA AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA AAAAAAAAAAAQAQAAU01USgAAAAAQAAABTQBpAGMAcgBvAHMAbwBmAHQAIABYAFAAUwAgAEQAbwBj AHUAbQBlAG4AdAAgAFcAcgBpAHQAZQByAAAASW5wdXRCaW4ARk9STVNPVVJDRQBSRVNETEwAVW5p cmVzRExMAEludGVybGVhdmluZwBPRkYASW1hZ2VUeXBlAEpQRUdNZWQAT3JpZW50YXRpb24AUE9S VFJBSVQAQ29sbGF0ZQBPRkYAUmVzb2x1dGlvbgBPcHRpb24xAFBhcGVyU2l6ZQBMRVRURVIAQ29s b3JNb2RlADI0YnBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAABN WERXAQEAAKEAIgAJAGQAAQAAAAAAggBYAsgADLZgC7Zg4D8MtmALtmDgPwEAVQACAAgAfQAMAAAA AACAUxYAAgCCAH0ADAABAAABAAAWAAMAggAAAg4AAAAAAAYCAAAAAAEAAAAIAhAAAAAAAAEAOwEA AAAAAAEPAAgCEAABAAAAAQA7AQAAAAAAAQ8ACAIQAAIAAAABAB0BAAAAAAABDwAIAhAAAwAAAAEA HQEAAAAAAAEPAAgCEAAEAAAAAQCVAQAAAACAARcACAIQAAUAAAABAO8BAAAAAMABFwAIAhAABgAA AAEAOwEAAAAAQAEPAAgCEAAHAAAAAQAdAQAAAAAAAQ8ACAIQAAgAAAABAB0BAAAAAAABDwAIAhAA CQAAAAEAHQEAAAAAAAEPAAgCEAAKAAAAAQAdAQAAAAAAAQ8ACAIQAAsAAAABAB0BAAAAAAABDwAI AhAADAAAAAEAHQEAAAAAAAEPAAgCEAANAAAAAQAdAQAAAAAAAQ8ACAIQAA4AAAABAB0BAAAAAAAB DwAIAhAADwAAAAEAHQEAAAAAAAEPAAgCEAAQAAAAAQAdAQAAAAAAAQ8ACAIQABEAAAABAB0BAAAA AAABDwAIAhAAEgAAAAEAHQEAAAAAAAEPAAgCEAATAAAAAQAdAQAAAAAAAQ8ACAIQABQAAAABAB0B AAAAAAABDwAIAhAAFQAAAAEAHQEAAAAAAAEPAAgCEAAWAAAAAQAdAQAAAAAAAQ8ACAIQABcAAAAB AB0BAAAAAAABDwAIAhAAGAAAAAEAHQEAAAAAAAEPAAgCEAAZAAAAAQAdAQAAAAAAAQ8ACAIQABoA AAABAB0BAAAAAAABDwAIAhAAGwAAAAEAHQEAAAAAAAEPAAgCEAAcAAAAAQAdAQAAAAAAAQ8ACAIQ AB0AAAABAB0BAAAAAAABDwAIAhAAHgAAAAEAHQEAAAAAAAEPAAgCEAAfAAAAAQAdAQAAAAAAAQ8A /QAKAAAAAAAdAPsAAAABAgYAAQAAAB0A/QAKAAQAAAAmAAAAAAD9AAoABQAAACYAAQAAAAECBgAG AAAAIQD9AAoABwAAACMA/wAAAP0ACgAIAAAAIwAAAQAA/QAKAAkAAAAjAAEBAAABAgYACgAAACIA /QAKAAsAAAAlAAIBAAD9AAoADAAAACUAAwEAAP0ACgANAAAAJQAEAQAA/QAKAA4AAAAlAAUBAAD9 AAoADwAAACIABgEAAP0ACgAQAAAAIgAHAQAA/QAKABEAAAAiAAgBAAD9AAoAEgAAACIACQEAAAEC BgATAAAAHgD9AAoAFAAAACQADQEAAP0ACgAVAAAAHwCgAAAA/QAKABYAAAAfAKEAAAABAgYAFwAA AB8A/QAKABgAAAAfAKIAAAABAgYAGQAAAB8A/QAKABoAAAAfAKMAAAD9AAoAGwAAAB8ApAAAAAEC BgAcAAAAHwD9AAoAHQAAAB8ApQAAAP0ACgAeAAAAHwCmAAAA/QAKAB8AAAAnAP0AAADXAEQACAQA AGwCDgAKAAAAAAAOAA4ACgAOAA4ADgAKAA4ADgAOAA4ADgAOAA4ADgAKAA4ADgAOAAoADgAKAA4A DgAKAA4ADgAIAhAAIAAAAAEAHQEAAAAAAAEPAAgCEAAhAAAAAQAdAQAAAAAAAQ8ACAIQACIAAAAB AB0BAAAAAAABDwAIAhAAIwAAAAEAHQEAAAAAAAEPAAgCEAAkAAAAAQAdAQAAAAAAAQ8ACAIQACUA AAABAB0BAAAAAAABDwAIAhAAJgAAAAEAHQEAAAAAAAEPAAgCEAAnAAAAAQAdAQAAAAAAAQ8ACAIQ ACgAAAABAB0BAAAAAAABDwAIAhAAKQAAAAEAHQEAAAAAAAEPAAgCEAAqAAAAAQAdAQAAAAAAAQ8A CAIQACsAAAABAB0BAAAAAAABDwAIAhAALAAAAAEAHQEAAAAAAAEPAAgCEAAtAAAAAQAdAQAAAAAA AQ8ACAIQAC4AAAABAB0BAAAAAAABDwAIAhAALwAAAAEAHQEAAAAAAAEPAAgCEAAwAAAAAQAdAQAA AAAAAQ8ACAIQADEAAAABAB0BAAAAAAABDwAIAhAAMgAAAAEAHQEAAAAAAAEPAAgCEAAzAAAAAQAd AQAAAAAAAQ8ACAIQADQAAAABAB0BAAAAAAABDwAIAhAANQAAAAEAHQEAAAAAAAEPAAgCEAA2AAAA AQAdAQAAAAAAAQ8ACAIQADcAAAABAB0BAAAAAAABDwAIAhAAOAAAAAEAHQEAAAAAAAEPAAgCEAA5 AAAAAQAdAQAAAAAAAQ8ACAIQADoAAAABAB0BAAAAAAABDwAIAhAAOwAAAAEAHQEAAAAAAAEPAAgC EAA8AAAAAQAdAQAAAAAAAQ8ACAIQAD0AAAABAB0BAAAAAAABDwAIAhAAPgAAAAEAHQEAAAAAAAEP AAgCEAA/AAAAAQAdAQAAAAAAAQ8A/QAKACAAAAAfAAIAAAD9AAoAIQAAAB8ApwAAAP0ACgAiAAAA HwCoAAAA/QAKACMAAAAfAKkAAAD9AAoAJAAAAB8AfgAAAP0ACgAlAAAAHwB/AAAA/QAKACYAAAAf AIAAAAD9AAoAJwAAAB8AqgAAAP0ACgAoAAAAHwCrAAAA/QAKACkAAAAfAIEAAAD9AAoAKgAAAB8A ggAAAP0ACgArAAAAHwCDAAAA/QAKACwAAAAfAKwAAAD9AAoALQAAAB8ArQAAAP0ACgAuAAAAHwCu AAAA/QAKAC8AAAAfAK8AAAD9AAoAMAAAAB8AsAAAAP0ACgAxAAAAHwCxAAAA/QAKADIAAAAfALIA AAD9AAoAMwAAAB8AswAAAP0ACgA0AAAAHwC0AAAA/QAKADUAAAAfALUAAAD9AAoANgAAAB8AtgAA AP0ACgA3AAAAHwC3AAAA/QAKADgAAAAfALgAAAD9AAoAOQAAAB8AuQAAAP0ACgA6AAAAHwC6AAAA /QAKADsAAAAfALsAAAD9AAoAPAAAAB8AvAAAAP0ACgA9AAAAHwC9AAAA/QAKAD4AAAAfAL4AAAAB AgYAPwAAAB8A1wBEADwEAABsAg4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4A DgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ACAIQAEAAAAABAB0BAAAAAAABDwAIAhAAQQAAAAEAHQEA AAAAAAEPAAgCEABCAAAAAQAdAQAAAAAAAQ8ACAIQAEMAAAABAB0BAAAAAAABDwAIAhAARAAAAAEA HQEAAAAAAAEPAAgCEABFAAAAAQAdAQAAAAAAAQ8ACAIQAEYAAAABAB0BAAAAAAABDwAIAhAARwAA AAEAHQEAAAAAAAEPAAgCEABIAAAAAQAdAQAAAAAAAQ8ACAIQAEkAAAABAB0BAAAAAAABDwAIAhAA SgAAAAEAHQEAAAAAAAEPAAgCEABLAAAAAQAdAQAAAAAAAQ8ACAIQAEwAAAABAB0BAAAAAAABDwAI AhAATQAAAAEAHQEAAAAAAAEPAAgCEABOAAAAAQAdAQAAAAAAAQ8ACAIQAE8AAAABAB0BAAAAAAAB DwAIAhAAUAAAAAEAHQEAAAAAAAEPAAgCEABRAAAAAQAdAQAAAAAAAQ8ACAIQAFIAAAABAB0BAAAA AAABDwAIAhAAUwAAAAEAHQEAAAAAAAEPAAgCEABUAAAAAQAdAQAAAAAAAQ8ACAIQAFUAAAABAB0B AAAAAAABDwAIAhAAVgAAAAEAHQEAAAAAAAEPAAgCEABXAAAAAQAdAQAAAAAAAQ8ACAIQAFgAAAAB AB0BAAAAAAABDwAIAhAAWQAAAAEAHQEAAAAAAAEPAAgCEABaAAAAAQAdAQAAAAAAAQ8ACAIQAFsA AAABAB0BAAAAAAABDwAIAhAAXAAAAAEAHQEAAAAAAAEPAAgCEABdAAAAAQAdAQAAAAAAAQ8ACAIQ AF4AAAABAB0BAAAAAAABDwAIAhAAXwAAAAEAHQEAAAAAAAEPAP0ACgBAAAAAHwADAAAA/QAKAEEA AAAfAL8AAAD9AAoAQgAAAB8AwAAAAP0ACgBDAAAAHwDBAAAA/QAKAEQAAAAfAMIAAAD9AAoARQAA AB8AwwAAAAECBgBGAAAAHwD9AAoARwAAAB8ABAAAAP0ACgBIAAAAHwAFAAAA/QAKAEkAAAAfAAYA AAD9AAoASgAAAB8ABwAAAP0ACgBLAAAAHwAIAAAA/QAKAEwAAAAnAP4AAAD9AAoATQAAAB8ACQAA AP0ACgBOAAAAHwCEAAAA/QAKAE8AAAAfAAoAAAD9AAoAUAAAAB8ACwAAAP0ACgBRAAAAHwAMAAAA /QAKAFIAAAAfAA0AAAD9AAoAUwAAAB8ADgAAAP0ACgBUAAAAHwAPAAAA/QAKAFUAAAAfABAAAAD9 AAoAVgAAAB8AEQAAAP0ACgBXAAAAHwASAAAA/QAKAFgAAAAfABMAAAABAgYAWQAAAB8A/QAKAFoA AAAfABQAAAD9AAoAWwAAAB8AFQAAAP0ACgBcAAAAHwAWAAAA/QAKAF0AAAAfABcAAAD9AAoAXgAA AB8AGAAAAP0ACgBfAAAAHwAZAAAA1wBEADgEAABsAg4ADgAOAA4ADgAOAAoADgAOAA4ADgAOAA4A DgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ACgAOAA4ADgAOAA4ACAIQAGAAAAABAB0BAAAAAAABDwAI AhAAYQAAAAEAHQEAAAAAAAEPAAgCEABiAAAAAQAdAQAAAAAAAQ8ACAIQAGMAAAABAB0BAAAAAAAB DwAIAhAAZAAAAAEAHQEAAAAAAAEPAAgCEABlAAAAAQAdAQAAAAAAAQ8ACAIQAGYAAAABAB0BAAAA AAABDwAIAhAAZwAAAAEAHQEAAAAAAAEPAAgCEABoAAAAAQAdAQAAAAAAAQ8ACAIQAGkAAAABAB0B AAAAAAABDwAIAhAAagAAAAEAHQEAAAAAAAEPAAgCEABrAAAAAQAdAQAAAAAAAQ8ACAIQAGwAAAAB AB0BAAAAAAABDwAIAhAAbQAAAAEAHQEAAAAAAAEPAAgCEABuAAAAAQAdAQAAAAAAAQ8ACAIQAG8A AAABAB0BAAAAAAABDwAIAhAAcAAAAAEAHQEAAAAAAAEPAAgCEABxAAAAAQAdAQAAAAAAAQ8ACAIQ AHIAAAABAB0BAAAAAAABDwAIAhAAcwAAAAEAHQEAAAAAAAEPAAgCEAB0AAAAAQAdAQAAAAAAAQ8A CAIQAHUAAAABAB0BAAAAAAABDwAIAhAAdgAAAAEAHQEAAAAAAAEPAAgCEAB3AAAAAQAdAQAAAAAA AQ8ACAIQAHgAAAABAB0BAAAAAAABDwAIAhAAeQAAAAEAHQEAAAAAAAEPAAgCEAB6AAAAAQAdAQAA AAAAAQ8ACAIQAHsAAAABAB0BAAAAAAABDwAIAhAAfAAAAAEAHQEAAAAAAAEPAAgCEAB9AAAAAQAd AQAAAAAAAQ8ACAIQAH4AAAABAB0BAAAAAAABDwAIAhAAfwAAAAEAHQEAAAAAAAEPAP0ACgBgAAAA HwAaAAAA/QAKAGEAAAAfABsAAAD9AAoAYgAAAB8AHAAAAAECBgBjAAAAHwD9AAoAZAAAAB8AHQAA AP0ACgBlAAAAHwAeAAAA/QAKAGYAAAAfAB8AAAD9AAoAZwAAAB8AIAAAAP0ACgBoAAAAHwAhAAAA /QAKAGkAAAAfACIAAAD9AAoAagAAAB8AIwAAAP0ACgBrAAAAHwAkAAAA/QAKAGwAAAAfACUAAAD9 AAoAbQAAAB8AhQAAAAECBgBuAAAAHwD9AAoAbwAAAB8AJgAAAP0ACgBwAAAAHwAnAAAA/QAKAHEA AAAfACgAAAD9AAoAcgAAAB8AKQAAAP0ACgBzAAAAHwDEAAAA/QAKAHQAAAAfAMUAAAD9AAoAdQAA AB8AxgAAAP0ACgB2AAAAHwDHAAAA/QAKAHcAAAAfAMgAAAD9AAoAeAAAAB8AyQAAAAECBgB5AAAA HwD9AAoAegAAAB8AhgAAAP0ACgB7AAAAHwAqAAAA/QAKAHwAAAAfAMoAAAD9AAoAfQAAAB8AywAA AP0ACgB+AAAAHwArAAAA/QAKAH8AAAAfACwAAADXAEQANAQAAGwCDgAOAA4ACgAOAA4ADgAOAA4A DgAOAA4ADgAOAAoADgAOAA4ADgAOAA4ADgAOAA4ADgAKAA4ADgAOAA4ADgAIAhAAgAAAAAEAHQEA AAAAAAEPAAgCEACBAAAAAQAdAQAAAAAAAQ8ACAIQAIIAAAABAB0BAAAAAAABDwAIAhAAgwAAAAEA HQEAAAAAAAEPAAgCEACEAAAAAQAdAQAAAAAAAQ8ACAIQAIUAAAABAB0BAAAAAAABDwAIAhAAhgAA AAEAHQEAAAAAAAEPAAgCEACHAAAAAQAdAQAAAAAAAQ8ACAIQAIgAAAABAB0BAAAAAAABDwAIAhAA iQAAAAEAHQEAAAAAAAEPAAgCEACKAAAAAQAdAQAAAAAAAQ8ACAIQAIsAAAABAB0BAAAAAAABDwAI AhAAjAAAAAEAHQEAAAAAAAEPAAgCEACNAAAAAQAdAQAAAAAAAQ8ACAIQAI4AAAABAB0BAAAAAAAB DwAIAhAAjwAAAAEAHQEAAAAAAAEPAAgCEACQAAAAAQAdAQAAAAAAAQ8ACAIQAJEAAAABAB0BAAAA AAABDwAIAhAAkgAAAAEAHQEAAAAAAAEPAAgCEACTAAAAAQAdAQAAAAAAAQ8ACAIQAJQAAAABAB0B AAAAAAABDwAIAhAAlQAAAAEAHQEAAAAAAAEPAAgCEACWAAAAAQAdAQAAAAAAAQ8ACAIQAJcAAAAB AB0BAAAAAAABDwAIAhAAmAAAAAEAHQEAAAAAAAEPAAgCEACZAAAAAQAdAQAAAAAAAQ8ACAIQAJoA AAABAB0BAAAAAAABDwAIAhAAmwAAAAEAHQEAAAAAAAEPAAgCEACcAAAAAQAdAQAAAAAAAQ8ACAIQ AJ0AAAABAB0BAAAAAAABDwAIAhAAngAAAAEAHQEAAAAAAAEPAAgCEACfAAAAAQAdAQAAAAAAAQ8A /QAKAIAAAAAfAC0AAAD9AAoAgQAAAB8ALgAAAP0ACgCCAAAAHwAvAAAA/QAKAIMAAAAfADAAAAD9 AAoAhAAAAB8AhwAAAAECBgCFAAAAHwD9AAoAhgAAAB8AMQAAAP0ACgCHAAAAHwDMAAAA/QAKAIgA AAAfAM0AAAD9AAoAiQAAAB8AMgAAAP0ACgCKAAAAHwAzAAAA/QAKAIsAAAAfADQAAAD9AAoAjAAA AB8ANQAAAP0ACgCNAAAAHwA2AAAA/QAKAI4AAAAfAM4AAAD9AAoAjwAAAB8AzwAAAP0ACgCQAAAA HwDQAAAA/QAKAJEAAAAfANEAAAD9AAoAkgAAAB8A0gAAAP0ACgCTAAAAHwDTAAAA/QAKAJQAAAAf ANQAAAD9AAoAlQAAAB8A1QAAAP0ACgCWAAAAHwA3AAAA/QAKAJcAAAAfANYAAAD9AAoAmAAAAB8A 1wAAAAECBgCZAAAAHwD9AAoAmgAAAB8AOAAAAP0ACgCbAAAAHwA5AAAA/QAKAJwAAAAfADoAAAD9 AAoAnQAAAB8AOwAAAP0ACgCeAAAAHwA8AAAA/QAKAJ8AAAAfAD0AAADXAEQAOAQAAGwCDgAOAA4A DgAOAAoADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAKAA4ADgAOAA4ADgAI AhAAoAAAAAEAHQEAAAAAAAEPAAgCEAChAAAAAQAdAQAAAAAAAQ8ACAIQAKIAAAABAB0BAAAAAAAB DwAIAhAAowAAAAEAHQEAAAAAAAEPAAgCEACkAAAAAQAdAQAAAAAAAQ8ACAIQAKUAAAABAB0BAAAA AAABDwAIAhAApgAAAAEAHQEAAAAAAAEPAAgCEACnAAAAAQAdAQAAAAAAAQ8ACAIQAKgAAAABAB0B AAAAAAABDwAIAhAAqQAAAAEAHQEAAAAAAAEPAAgCEACqAAAAAQAdAQAAAAAAAQ8ACAIQAKsAAAAB AB0BAAAAAAABDwAIAhAArAAAAAEAHQEAAAAAAAEPAAgCEACtAAAAAQAdAQAAAAAAAQ8ACAIQAK4A AAABAB0BAAAAAAABDwAIAhAArwAAAAEAHQEAAAAAAAEPAAgCEACwAAAAAQAdAQAAAAAAAQ8ACAIQ ALEAAAABAB0BAAAAAAABDwAIAhAAsgAAAAEAHQEAAAAAAAEPAAgCEACzAAAAAQAdAQAAAAAAAQ8A CAIQALQAAAABAB0BAAAAAAABDwAIAhAAtQAAAAEAHQEAAAAAAAEPAAgCEAC2AAAAAQAdAQAAAAAA AQ8ACAIQALcAAAABAB0BAAAAAAABDwAIAhAAuAAAAAEAHQEAAAAAAAEPAAgCEAC5AAAAAQAdAQAA AAAAAQ8ACAIQALoAAAABAB0BAAAAAAABDwAIAhAAuwAAAAEAHQEAAAAAAAEPAAgCEAC8AAAAAQAd AQAAAAAAAQ8ACAIQAL0AAAABAB0BAAAAAAABDwAIAhAAvgAAAAEAHQEAAAAAAAEPAAgCEAC/AAAA AQAdAQAAAAAAAQ8A/QAKAKAAAAAfAD4AAAD9AAoAoQAAAB8APwAAAP0ACgCiAAAAHwBAAAAAAQIG AKMAAAAfAP0ACgCkAAAAHwCIAAAA/QAKAKUAAAAfAEEAAAD9AAoApgAAAB8AQgAAAP0ACgCnAAAA HwBDAAAA/QAKAKgAAAAfAEQAAAD9AAoAqQAAAB8ARQAAAP0ACgCqAAAAHwBGAAAA/QAKAKsAAAAf AEcAAAD9AAoArAAAAB8ASAAAAP0ACgCtAAAAJwAKAQAA/QAKAK4AAAAnAIkAAAD9AAoArwAAAB8A igAAAP0ACgCwAAAAHwCLAAAA/QAKALEAAAAfAFsAAAD9AAoAsgAAAB8AXAAAAP0ACgCzAAAAHwBd AAAA/QAKALQAAAAfAF4AAAD9AAoAtQAAAB8AXwAAAP0ACgC2AAAAHwCMAAAA/QAKALcAAAAfAGAA AAD9AAoAuAAAAB8AYQAAAP0ACgC5AAAAHwBiAAAA/QAKALoAAAAfANgAAAD9AAoAuwAAAB8AzwAA AP0ACgC8AAAAHwDZAAAA/QAKAL0AAAAfANoAAAD9AAoAvgAAAB8A2wAAAP0ACgC/AAAAHwDcAAAA 1wBEADwEAABsAg4ADgAOAAoADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAO AA4ADgAOAA4ADgAOAA4ACAIQAMAAAAABAB0BAAAAAAABDwAIAhAAwQAAAAEAHQEAAAAAAAEPAAgC EADCAAAAAQAdAQAAAAAAAQ8ACAIQAMMAAAABAB0BAAAAAAABDwAIAhAAxAAAAAEAHQEAAAAAAAEP AAgCEADFAAAAAQAdAQAAAAAAAQ8ACAIQAMYAAAABAB0BAAAAAAABDwAIAhAAxwAAAAEAHQEAAAAA AAEPAAgCEADIAAAAAQAdAQAAAAAAAQ8ACAIQAMkAAAABAB0BAAAAAAABDwAIAhAAygAAAAEAHQEA AAAAAAEPAAgCEADLAAAAAQAdAQAAAAAAAQ8ACAIQAMwAAAABAB0BAAAAAAABDwAIAhAAzQAAAAEA HQEAAAAAAAEPAAgCEADOAAAAAQAdAQAAAAAAAQ8ACAIQAM8AAAABAB0BAAAAAAABDwAIAhAA0AAA AAEAHQEAAAAAAAEPAAgCEADRAAAAAQAdAQAAAAAAAQ8ACAIQANIAAAABAB0BAAAAAAABDwAIAhAA 0wAAAAEAHQEAAAAAAAEPAAgCEADUAAAAAQAdAQAAAAAAAQ8ACAIQANUAAAABAB0BAAAAAAABDwAI AhAA1gAAAAEAHQEAAAAAAAEPAAgCEADXAAAAAQAdAQAAAAAAAQ8ACAIQANgAAAABAB0BAAAAAAAB DwAIAhAA2QAAAAEAHQEAAAAAAAEPAAgCEADaAAAAAQAdAQAAAAAAAQ8ACAIQANsAAAABAB0BAAAA AAABDwAIAhAA3AAAAAEAHQEAAAAAAAEPAAgCEADdAAAAAQAdAQAAAAAAAQ8ACAIQAN4AAAABACwB AAAAAEABDwAIAhAA3wAAAAEAHQEAAAAAAAEPAAECBgDAAAAAHwD9AAoAwQAAAB8AjQAAAP0ACgDC AAAAHwBJAAAA/QAKAMMAAAAfAEoAAAD9AAoAxAAAAB8ASwAAAP0ACgDFAAAAHwBMAAAA/QAKAMYA AAAfAE0AAAD9AAoAxwAAAB8ATgAAAP0ACgDIAAAAHwBPAAAA/QAKAMkAAAAfAFAAAAABAgYAygAA AB8A/QAKAMsAAAAfAI4AAAD9AAoAzAAAAB8AUQAAAP0ACgDNAAAAHwBSAAAA/QAKAM4AAAAfAI8A AAD9AAoAzwAAAB8AUwAAAP0ACgDQAAAAHwCQAAAA/QAKANEAAAAfAFQAAAD9AAoA0gAAAB8AVQAA AP0ACgDTAAAAHwBWAAAA/QAKANQAAAAfAFcAAAD9AAoA1QAAAB8AWAAAAP0ACgDWAAAAHwBZAAAA /QAKANcAAAAfAFoAAAABAgYA2AAAAB8A/QAKANkAAAAfAGMAAAD9AAoA2gAAAB8AZAAAAP0ACgDb AAAAHwBlAAAA/QAKANwAAAAfAGYAAAD9AAoA3QAAAB8AZwAAAP0ACgDeAAAAHwBoAAAA/QAKAN8A AAAfAGkAAADXAEQANAQAAGwCCgAOAA4ADgAOAA4ADgAOAA4ADgAKAA4ADgAOAA4ADgAOAA4ADgAO AA4ADgAOAA4ACgAOAA4ADgAOAA4ADgAIAhAA4AAAAAEAHQEAAAAAAAEPAAgCEADhAAAAAQAdAQAA AAAAAQ8ACAIQAOIAAAABAB0BAAAAAAABDwAIAhAA4wAAAAEAHQEAAAAAAAEPAAgCEADkAAAAAQAd AQAAAAAAAQ8ACAIQAOUAAAABAB0BAAAAAAABDwAIAhAA5gAAAAEAHQEAAAAAAAEPAAgCEADnAAAA AQAdAQAAAAAAAQ8ACAIQAOgAAAABAB0BAAAAAAABDwAIAhAA6QAAAAEAHQEAAAAAAAEPAAgCEADq AAAAAQAdAQAAAAAAAQ8ACAIQAOsAAAABAB0BAAAAAAABDwAIAhAA7AAAAAEAHQEAAAAAAAEPAAgC EADtAAAAAQAdAQAAAAAAAQ8ACAIQAO4AAAABAB0BAAAAAAABDwAIAhAA7wAAAAEAHQEAAAAAAAEP AAgCEADwAAAAAQAdAQAAAAAAAQ8ACAIQAPEAAAABAB0BAAAAAAABDwAIAhAA8gAAAAEAHQEAAAAA AAEPAAgCEADzAAAAAQAdAQAAAAAAAQ8ACAIQAPQAAAABAB0BAAAAAAABDwAIAhAA9QAAAAEAHQEA AAAAAAEPAAgCEAD2AAAAAQAdAQAAAAAAAQ8ACAIQAPcAAAABAB0BAAAAAAABDwAIAhAA+AAAAAEA HQEAAAAAAAEPAAgCEAD5AAAAAQAdAQAAAAAAAQ8ACAIQAPoAAAABAB0BAAAAAAABDwAIAhAA+wAA AAEAHQEAAAAAAAEPAAgCEAD8AAAAAQAdAQAAAAAAAQ8ACAIQAP0AAAABAB0BAAAAAAABDwAIAhAA /gAAAAEAHQEAAAAAAAEPAAgCEAD/AAAAAQAdAQAAAAAAAQ8A/QAKAOAAAAAfAN0AAAD9AAoA4QAA ACAA3gAAAP0ACgDiAAAAHwBqAAAAAQIGAOMAAAAfAP0ACgDkAAAAHwBrAAAA/QAKAOUAAAAfAJEA AAD9AAoA5gAAAB8AbAAAAP0ACgDnAAAAHwBtAAAA/QAKAOgAAAAfAG4AAAD9AAoA6QAAAB8AbwAA AP0ACgDqAAAAHwBwAAAA/QAKAOsAAAAfAHEAAAD9AAoA7AAAAB8AcgAAAP0ACgDtAAAAHwCSAAAA /QAKAO4AAAAfAJMAAAABAgYA7wAAAB8A/QAKAPAAAAAfAHMAAAD9AAoA8QAAAB8AdAAAAP0ACgDy AAAAHwB1AAAA/QAKAPMAAAAfAHYAAAD9AAoA9AAAAB8AdwAAAP0ACgD1AAAAHwB4AAAA/QAKAPYA AAAfAN8AAAD9AAoA9wAAAB8A4AAAAP0ACgD4AAAAHwB5AAAA/QAKAPkAAAAfAHoAAAABAgYA+gAA AB8A/QAKAPsAAAAfAHsAAAD9AAoA/AAAAB8AlAAAAP0ACgD9AAAAHwB8AAAA/QAKAP4AAAAfAJUA AAD9AAoA/wAAAB8AlgAAANcARAA0BAAAbAIOAA4ADgAKAA4ADgAOAA4ADgAOAA4ADgAOAA4ADgAK AA4ADgAOAA4ADgAOAA4ADgAOAA4ACgAOAA4ADgAOAAgCEAAAAQAAAQAdAQAAAAAAAQ8ACAIQAAEB AAABAB0BAAAAAAABDwAIAhAAAgEAAAEAHQEAAAAAAAEPAAgCEAADAQAAAQAdAQAAAAAAAQ8ACAIQ AAQBAAABAB0BAAAAAAABDwAIAhAABQEAAAEAHQEAAAAAAAEPAAgCEAAGAQAAAQAdAQAAAAAAAQ8A CAIQAAcBAAABAB0BAAAAAAABDwAIAhAACAEAAAEAHQEAAAAAAAEPAAgCEAAJAQAAAQAdAQAAAAAA AQ8ACAIQAAoBAAABAB0BAAAAAAABDwAIAhAACwEAAAEAHQEAAAAAAAEPAAgCEAAMAQAAAQAdAQAA AAAAAQ8ACAIQAA0BAAABAB0BAAAAAAABDwAIAhAADgEAAAEAHQEAAAAAAAEPAAgCEAAPAQAAAQAd AQAAAAAAAQ8ACAIQABABAAABAB0BAAAAAAABDwAIAhAAEQEAAAEAHQEAAAAAAAEPAAgCEAASAQAA AQAdAQAAAAAAAQ8ACAIQABMBAAABAB0BAAAAAAABDwAIAhAAFAEAAAEAHQEAAAAAAAEPAAgCEAAV AQAAAQAdAQAAAAAAAQ8ACAIQABYBAAABAB0BAAAAAAABDwAIAhAAFwEAAAEAHQEAAAAAAAEPAAgC EAAYAQAAAQAdAQAAAAAAAQ8ACAIQABkBAAABAB0BAAAAAAABDwAIAhAAGgEAAAEAHQEAAAAAAAEP AAgCEAAbAQAAAQAdAQAAAAAAAQ8ACAIQABwBAAABAB0BAAAAAAABDwAIAhAAHQEAAAEAHQEAAAAA AAEPAAgCEAAeAQAAAQAdAQAAAAAAAQ8ACAIQAB8BAAABAB0BAAAAAAABDwD9AAoAAAEAAB8AlwAA AP0ACgABAQAAHwCYAAAA/QAKAAIBAAAfAJkAAAD9AAoAAwEAAB8AmgAAAP0ACgAEAQAAHwCbAAAA /QAKAAUBAAAfAJwAAAD9AAoABgEAAB8AnQAAAP0ACgAHAQAAJwD9AAAA/QAKAAgBAAAkAJ4AAAD9 AAoACQEAAB8A4QAAAP0ACgAKAQAAHwDiAAAA/QAKAAsBAAAfAH0AAAABAgYADAEAAB8A/QAKAA0B AAAfAOMAAAD9AAoADgEAAB8A5AAAAP0ACgAPAQAAHwDlAAAA/QAKABABAAAfAOYAAAABAgYAEQEA AB8A/QAKABIBAAAfAOcAAAD9AAoAEwEAAB8A6AAAAP0ACgAUAQAAHwDpAAAA/QAKABUBAAAfAOoA AAD9AAoAFgEAAB8A6wAAAAECBgAXAQAAHwD9AAoAGAEAAB8A7AAAAP0ACgAZAQAAHwDtAAAA/QAK ABoBAAAfAO4AAAD9AAoAGwEAAB8A7wAAAP0ACgAcAQAAHwDwAAAAAQIGAB0BAAAfAP0ACgAeAQAA HwDxAAAA/QAKAB8BAAAfAPIAAADXAEQAMAQAAGwCDgAOAA4ADgAOAA4ADgAOAA4ADgAOAA4ACgAO AA4ADgAOAAoADgAOAA4ADgAOAAoADgAOAA4ADgAOAAoADgAIAhAAIAEAAAEAHQEAAAAAAAEPAAgC EAAhAQAAAQAdAQAAAAAAAQ8ACAIQACIBAAABAB0BAAAAAAABDwAIAhAAIwEAAAEAHQEAAAAAAAEP AAgCEAAkAQAAAQAdAQAAAAAAAQ8ACAIQACUBAAABAB0BAAAAAAABDwAIAhAAJgEAAAEAHQEAAAAA AAEPAAgCEAAnAQAAAQAdAQAAAAAAAQ8ACAIQACgBAAABAB0BAAAAAAABDwAIAhAAKQEAAAEAHQEA AAAAAAEPAAgCEAAqAQAAAQAdAQAAAAAAAQ8ACAIQACsBAAABAB0BAAAAAAABDwAIAhAALAEAAAEA HQEAAAAAAAEPAAgCEAAtAQAAAQAdAQAAAAAAAQ8ACAIQAC4BAAABAB0BAAAAAAABDwAIAhAALwEA AAEAHQEAAAAAAAEPAAgCEAAwAQAAAQAdAQAAAAAgAQ8ACAIQADEBAAABAB0BAAAAACABDwAIAhAA MgEAAAEAHQEAAAAAIAEPAAgCEAAzAQAAAQAdAQAAAAAAAQ8ACAIQADQBAAABAB0BAAAAACABDwAI AhAANQEAAAEAHQEAAAAAIAEPAAgCEAA2AQAAAQAdAQAAAAAgAQ8ACAIQADcBAAABAB0BAAAAACAB DwAIAhAAOAEAAAEAHQEAAAAAIAEPAAgCEAA5AQAAAQAdAQAAAAAgAQ8ACAIQADoBAAABAB0BAAAA ACABDwAIAhAAOwEAAAEAHQEAAAAAIAEPAAgCEAA8AQAAAQAdAQAAAAAgAQ8ACAIQAD0BAAABAB0B AAAAACABDwAIAhAAPgEAAAEAHQEAAAAAIAEPAAgCEAA/AQAAAQAdAQAAAAAgAQ8A/QAKACABAAAf APoAAAD9AAoAIQEAAB8A8wAAAP0ACgAiAQAAHwD0AAAAAQIGACMBAAAfAP0ACgAkAQAAHwD1AAAA /QAKACUBAAAfAPYAAAD9AAoAJgEAAB8A9wAAAP0ACgAnAQAAHwAOAQAA/QAKACgBAAAfAPgAAAD9 AAoAKQEAACcA/gAAAP0ACgAqAQAAHwCfAAAA/QAKACsBAAAfAAsBAAD9AAoALAEAAB8ADAEAAP0A CgAtAQAAHwD8AAAA/QAKAC4BAAAfAA8BAAD9AAoALwEAACcA+QAAAAECBgAwAQAAGQABAgYAMQEA ABkAAQIGADIBAAAZAAECBgAzAQAAGQABAgYANAEAABkAAQIGADUBAAAZAAECBgA2AQAAGQABAgYA NwEAABkAAQIGADgBAAAZAAECBgA5AQAAGQABAgYAOgEAABkAAQIGADsBAAAZAAECBgA8AQAAGQAB AgYAPQEAABkAAQIGAD4BAAAZAAECBgA/AQAAGQDXAEQA/AMAAGwCDgAOAA4ACgAOAA4ADgAOAA4A DgAOAA4ADgAOAA4ADgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAIAhAAQAEAAAEAHQEA AAAAIAEPAAgCEABBAQAAAQAdAQAAAAAgAQ8ACAIQAEIBAAABAB0BAAAAACABDwAIAhAAQwEAAAEA HQEAAAAAIAEPAAgCEABEAQAAAQAsAQAAAAAgAQ8ACAIQAEUBAAABACwBAAAAACABDwAIAhAARgEA AAEALAEAAAAAIAEPAAgCEABHAQAAAQAsAQAAAAAgAQ8ACAIQAEgBAAABACwBAAAAACABDwAIAhAA SQEAAAEALAEAAAAAIAEPAAgCEABKAQAAAQAdAQAAAAAgAQ8ACAIQAEsBAAABAB0BAAAAACABDwAI AhAATAEAAAEAHQEAAAAAIAEPAAgCEABNAQAAAQAdAQAAAAAgAQ8ACAIQAE4BAAABAB0BAAAAACAB DwAIAhAATwEAAAEAHQEAAAAAIAEPAAgCEABQAQAAAQAdAQAAAAAgAQ8ACAIQAFEBAAABAB0BAAAA ACABDwAIAhAAUgEAAAEAHQEAAAAAIAEPAAgCEABTAQAAAQAdAQAAAAAgAQ8ACAIQAFQBAAABAB0B AAAAACABDwAIAhAAVQEAAAEAHQEAAAAAIAEPAAgCEABWAQAAAQAdAQAAAAAgAQ8ACAIQAFcBAAAB AB0BAAAAACABDwAIAhAAWAEAAAEAHQEAAAAAIAEPAAgCEABZAQAAAQAdAQAAAAAgAQ8ACAIQAFoB AAABAB0BAAAAACABDwAIAhAAWwEAAAEAHQEAAAAAIAEPAAgCEABcAQAAAQAdAQAAAAAgAQ8ACAIQ AF0BAAABAB0BAAAAACABDwAIAhAAXgEAAAEAHQEAAAAAIAEPAAgCEABfAQAAAQAdAQAAAAAgAQ8A AQIGAEABAAAZAAECBgBBAQAAGQABAgYAQgEAABwAAQIGAEMBAAAcAAECBgBEAQAAGgABAgYARQEA ABoAAQIGAEYBAAAaAAECBgBHAQAAGgABAgYASAEAABoAAQIGAEkBAAAbAAECBgBKAQAAGQABAgYA SwEAABkAAQIGAEwBAAAZAAECBgBNAQAAGQABAgYATgEAABkAAQIGAE8BAAAZAAECBgBQAQAAGQAB AgYAUQEAABkAAQIGAFIBAAAZAAECBgBTAQAAGQABAgYAVAEAABkAAQIGAFUBAAAZAAECBgBWAQAA GQABAgYAVwEAABkAAQIGAFgBAAAZAAECBgBZAQAAGQABAgYAWgEAABkAAQIGAFsBAAAZAAECBgBc AQAAGQABAgYAXQEAABkAAQIGAF4BAAAZAAECBgBfAQAAGQDXAEQAwAMAAGwCCgAKAAoACgAKAAoA CgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAIAhAAYAEA AAEAHQEAAAAAIAEPAAgCEABhAQAAAQAdAQAAAAAgAQ8ACAIQAGIBAAABAB0BAAAAACABDwAIAhAA YwEAAAEAHQEAAAAAIAEPAAgCEABkAQAAAQAdAQAAAAAgAQ8ACAIQAGUBAAABAB0BAAAAACABDwAI AhAAZgEAAAEAHQEAAAAAIAEPAAgCEABnAQAAAQAdAQAAAAAgAQ8ACAIQAGgBAAABAB0BAAAAACAB DwAIAhAAaQEAAAEAHQEAAAAAIAEPAAgCEABqAQAAAQAdAQAAAAAgAQ8ACAIQAGsBAAABAB0BAAAA ACABDwAIAhAAbAEAAAEAHQEAAAAAIAEPAAgCEABtAQAAAQAdAQAAAAAgAQ8ACAIQAG4BAAABAB0B AAAAACABDwAIAhAAbwEAAAEAHQEAAAAAIAEPAAgCEABwAQAAAQAdAQAAAAAgAQ8ACAIQAHEBAAAB AB0BAAAAACABDwAIAhAAcgEAAAEAHQEAAAAAIAEPAAgCEABzAQAAAQAdAQAAAAAgAQ8ACAIQAHQB AAABAB0BAAAAACABDwAIAhAAdQEAAAEAHQEAAAAAIAEPAAgCEAB2AQAAAQAdAQAAAAAgAQ8ACAIQ AHcBAAABAB0BAAAAACABDwAIAhAAeAEAAAEAHQEAAAAAIAEPAAgCEAB5AQAAAQAdAQAAAAAgAQ8A CAIQAHoBAAABAB0BAAAAACABDwAIAhAAewEAAAEAHQEAAAAAIAEPAAgCEAB8AQAAAQAdAQAAAAAg AQ8ACAIQAH0BAAABAB0BAAAAACABDwAIAhAAfgEAAAEAHQEAAAAAIAEPAAgCEAB/AQAAAQAdAQAA AAAgAQ8AAQIGAGABAAAZAAECBgBhAQAAGQABAgYAYgEAABkAAQIGAGMBAAAZAAECBgBkAQAAGQAB AgYAZQEAABkAAQIGAGYBAAAZAAECBgBnAQAAGQABAgYAaAEAABkAAQIGAGkBAAAZAAECBgBqAQAA GQABAgYAawEAABkAAQIGAGwBAAAZAAECBgBtAQAAGQABAgYAbgEAABkAAQIGAG8BAAAZAAECBgBw AQAAGQABAgYAcQEAABkAAQIGAHIBAAAZAAECBgBzAQAAGQABAgYAdAEAABkAAQIGAHUBAAAZAAEC BgB2AQAAGQABAgYAdwEAABkAAQIGAHgBAAAZAAECBgB5AQAAGQABAgYAegEAABkAAQIGAHsBAAAZ AAECBgB8AQAAGQABAgYAfQEAABkAAQIGAH4BAAAZAAECBgB/AQAAGQDXAEQAwAMAAGwCCgAKAAoA CgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAI AhAAgAEAAAEAHQEAAAAAIAEPAAgCEACBAQAAAQAdAQAAAAAgAQ8ACAIQAIIBAAABAB0BAAAAACAB DwAIAhAAgwEAAAEAHQEAAAAAIAEPAAgCEACEAQAAAQAdAQAAAAAgAQ8ACAIQAIUBAAABAB0BAAAA ACABDwAIAhAAhgEAAAEAHQEAAAAAIAEPAAgCEACHAQAAAQAdAQAAAAAgAQ8ACAIQAIgBAAABAB0B AAAAACABDwAIAhAAiQEAAAEAHQEAAAAAIAEPAAgCEACKAQAAAQAdAQAAAAAgAQ8ACAIQAIsBAAAB AB0BAAAAACABDwAIAhAAjAEAAAEAHQEAAAAAIAEPAAgCEACNAQAAAQAdAQAAAAAgAQ8ACAIQAI4B AAABAB0BAAAAACABDwAIAhAAjwEAAAEAHQEAAAAAIAEPAAgCEACQAQAAAQAdAQAAAAAgAQ8ACAIQ AJEBAAABAB0BAAAAACABDwAIAhAAkgEAAAEAHQEAAAAAIAEPAAgCEACTAQAAAQAdAQAAAAAgAQ8A CAIQAJQBAAABAB0BAAAAACABDwAIAhAAlQEAAAEAHQEAAAAAIAEPAAgCEACWAQAAAQAdAQAAAAAg AQ8ACAIQAJcBAAABAB0BAAAAACABDwAIAhAAmAEAAAEAHQEAAAAAIAEPAAgCEACZAQAAAQAdAQAA AAAgAQ8ACAIQAJoBAAABAB0BAAAAACABDwAIAhAAmwEAAAEAHQEAAAAAIAEPAAgCEACcAQAAAQAd AQAAAAAgAQ8ACAIQAJ0BAAABAB0BAAAAACABDwAIAhAAngEAAAEAHQEAAAAAIAEPAAgCEACfAQAA AQAdAQAAAAAgAQ8AAQIGAIABAAAZAAECBgCBAQAAGQABAgYAggEAABkAAQIGAIMBAAAZAAECBgCE AQAAGQABAgYAhQEAABkAAQIGAIYBAAAZAAECBgCHAQAAGQABAgYAiAEAABkAAQIGAIkBAAAZAAEC BgCKAQAAGQABAgYAiwEAABkAAQIGAIwBAAAZAAECBgCNAQAAGQABAgYAjgEAABkAAQIGAI8BAAAZ AAECBgCQAQAAGQABAgYAkQEAABkAAQIGAJIBAAAZAAECBgCTAQAAGQABAgYAlAEAABkAAQIGAJUB AAAZAAECBgCWAQAAGQABAgYAlwEAABkAAQIGAJgBAAAZAAECBgCZAQAAGQABAgYAmgEAABkAAQIG AJsBAAAZAAECBgCcAQAAGADXAEQAogMAAGwCCgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA CgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAAAAAAIAhAAoAEBAAEAHQEAAAAAIAEPAAgCEACh AQEAAQAdAQAAAAAgAQ8ACAIQAKIBAQABAB0BAAAAACABDwAIAhAAowEBAAEAHQEAAAAAIAEPAAgC EACkAQEAAQAdAQAAAAAgAQ8ACAIQAKUBAQABAB0BAAAAACABDwAIAhAApgEBAAEAHQEAAAAAIAEP AAgCEACnAQEAAQAdAQAAAAAgAQ8ACAIQAKgBAQABAB0BAAAAACABDwAIAhAAqQEBAAEAHQEAAAAA IAEPAAgCEACqAQEAAQAdAQAAAAAgAQ8ACAIQAKsBAQABAB0BAAAAACABDwAIAhAArAEBAAEAHQEA AAAAIAEPAAgCEACtAQEAAQAdAQAAAAAgAQ8ACAIQAK4BAQABAB0BAAAAACABDwAIAhAArwEBAAEA HQEAAAAAIAEPAAgCEACwAQEAAQAdAQAAAAAgAQ8ACAIQALEBAQABAB0BAAAAACABDwAIAhAAsgEB AAEAHQEAAAAAIAEPAAgCEACzAQEAAQAdAQAAAAAgAQ8ACAIQALQBAQABAB0BAAAAACABDwAIAhAA tQEBAAEAHQEAAAAAIAEPAAgCEAC2AQEAAQAdAQAAAAAgAQ8ACAIQALcBAQABAB0BAAAAACABDwAI AhAAuAEBAAEAHQEAAAAAIAEPAAgCEAC5AQEAAQAdAQAAAAAgAQ8ACAIQALoBAQABAB0BAAAAACAB DwAIAhAAuwEBAAEAHQEAAAAAIAEPAAgCEAC8AQEAAQAdAQAAAAAgAQ8ACAIQAL0BAQABAB0BAAAA ACABDwAIAhAAvgEBAAEAHQEAAAAAIAEPAAgCEAC/AQEAAQAdAQAAAAAgAQ8A1wBEAIACAABsAgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAACAIQAMABAQABAB0BAAAAACABDwAIAhAAwQEBAAEAHQEAAAAAIAEPAAgCEADCAQEAAQAdAQAA AAAgAQ8ACAIQAMMBAQABAB0BAAAAACABDwAIAhAAxAEBAAEAHQEAAAAAIAEPAAgCEADFAQEAAQAd AQAAAAAgAQ8ACAIQAMYBAQABAB0BAAAAACABDwAIAhAAxwEBAAEAHQEAAAAAIAEPAAgCEADIAQEA AQAdAQAAAAAgAQ8ACAIQAMkBAQABAB0BAAAAACABDwAIAhAAygEBAAEAHQEAAAAAIAEPAAgCEADL AQEAAQAdAQAAAAAgAQ8ACAIQAMwBAQABAB0BAAAAACABDwAIAhAAzQEBAAEAHQEAAAAAIAEPAAgC EADOAQEAAQAdAQAAAAAgAQ8ACAIQAM8BAQABAB0BAAAAACABDwAIAhAA0AEBAAEAHQEAAAAAIAEP AAgCEADRAQEAAQAdAQAAAAAgAQ8ACAIQANIBAQABAB0BAAAAACABDwAIAhAA0wEBAAEAHQEAAAAA IAEPAAgCEADUAQEAAQAdAQAAAAAgAQ8ACAIQANUBAQABAB0BAAAAACABDwAIAhAA1gEBAAEAHQEA AAAAIAEPAAgCEADXAQEAAQAdAQAAAAAgAQ8ACAIQANgBAQABAB0BAAAAACABDwAIAhAA2QEBAAEA HQEAAAAAIAEPAAgCEADaAQEAAQAdAQAAAAAgAQ8ACAIQANsBAQABAB0BAAAAACABDwAIAhAA3AEB AAEAHQEAAAAAIAEPAAgCEADdAQEAAQAdAQAAAAAgAQ8ACAIQAN4BAQABAB0BAAAAACABDwAIAhAA 3wEBAAEAHQEAAAAAIAEPANcARACAAgAAbAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgCEADgAQEAAQAdAQAAAAAgAQ8ACAIQAOEB AQABAB0BAAAAACABDwAIAhAA4gEBAAEAHQEAAAAAIAEPAAgCEADjAQEAAQAdAQAAAAAgAQ8ACAIQ AOQBAQABAB0BAAAAACABDwAIAhAA5QEBAAEAHQEAAAAAIAEPAAgCEADmAQEAAQAdAQAAAAAgAQ8A CAIQAOcBAQABAB0BAAAAACABDwAIAhAA6AEBAAEAHQEAAAAAIAEPAAgCEADpAQEAAQAdAQAAAAAg AQ8ACAIQAOoBAQABAB0BAAAAACABDwAIAhAA6wEBAAEAHQEAAAAAIAEPAAgCEADsAQEAAQAdAQAA AAAgAQ8ACAIQAO0BAQABAB0BAAAAACABDwAIAhAA7gEBAAEAHQEAAAAAIAEPAAgCEADvAQEAAQAd AQAAAAAgAQ8ACAIQAPABAQABAB0BAAAAACABDwAIAhAA8QEBAAEAHQEAAAAAIAEPAAgCEADyAQEA AQArAgAAAABgAQ8ACAIQAPMBAQABAB0BAAAAACABDwAIAhAA9AEBAAEAHQEAAAAAIAEPAAgCEAD1 AQEAAQAdAQAAAAAgAQ8ACAIQAPYBAQABAB0BAAAAACABDwAIAhAA9wEBAAEAHQEAAAAAIAEPAAgC EAD4AQEAAQAdAQAAAAAgAQ8ACAIQAPkBAQABAB0BAAAAAAABDwAIAhAA+gEBAAEAHQEAAAAAIAEP AAgCEAD7AQEAAQAdAQAAAAAgAQ8ACAIQAPwBAQABAB0BAAAAACABDwAIAhAA/QEBAAEAHQEAAAAA IAEPAAgCEAD+AQEAAQAdAQAAAAAgAQ8ACAIQAP8BAQABAB0BAAAAACABDwDXAEQAgAIAAGwCAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAIAhAAAAIBAAEAHQEAAAAAIAEPAAgCEAABAgEAAQAdAQAAAAAgAQ8ACAIQAAICAQABAB0BAAAA ACABDwAIAhAAAwIBAAEAHQEAAAAAAAEPAAgCEAAEAgEAAQAdAQAAAAAgAQ8ACAIQAAUCAQABAB0B AAAAAAABDwDXABAAeAAAAGQAAAAAAAAAAAAAAD4CEgC2BgAAAABAAAAAZAAAAAAAAAAdAA8AAxcA AAAAAAEAFwAXAAAAmQACAAAJ7wAGAAUANwAAAAoAAAAJCBAAAAYQAOwVzQfZwAAABgMAAAsCEAAA AAAAAAAAAAAAAAC2lgAADQACAAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEA KgACAAAAKwACAAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAAHQGBAAIAwQQUAAAAFQAAAIMAAgAA AIQAAgAAAKEAIgAAAB0BAQABAAEABAEAAAAAAAAAAAAA4D8AAAAAAADgPwEAVQACAAgAAAIOAAAA AAAAAAAAAAAAAAAAPgISALYAAAAAAEAAAAAAAAAAAAAAAB0ADwADAAAAAAAAAQAAAAAAAADvAAYA BQA3AAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAA6AAAAAAAAAABAEMAbwBtAHAA TwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAC AP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAABqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXAAAAUAAAAAsAAABYAAAAEAAAAGAAAAAT AAAAaAAAABYAAABwAAAADQAAAHgAAAAMAAAAmQAAAAIAAACoAwAAAwAAAOYVCwALAAAAAAAAAAsA AAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAACAAAACgAAAGtmZ2lqNXNsOQAHAAAAU2hlZXQxAAwQ AAACAAAAHgAAAAcAAAC5pNf3se0AAwAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/ AwoAAP////8gCAIAAAAAAMAAAAAAAABGHgAAAE1pY3Jvc29mdCBPZmZpY2UgRXhjZWwguaTX97Ht AAYAAABCaWZmOAAOAAAARXhjZWwuU2hlZXQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=aeimqu946_6888_291137520.184564-- From penguin-kernel@I-love.SAKURA.ne.jp Sun Sep 20 02:03:39 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A17457F47 for ; Sun, 20 Sep 2015 02:03:39 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 1F17CAC003 for ; Sun, 20 Sep 2015 00:03:39 -0700 (PDT) X-ASG-Debug-ID: 1442732616-04cbb033b12a160001-NocioJ Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by cuda.sgi.com with ESMTP id cqIcWH0OId05Kidm (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 20 Sep 2015 00:03:37 -0700 (PDT) X-Barracuda-Envelope-From: penguin-kernel@I-love.SAKURA.ne.jp X-Barracuda-Apparent-Source-IP: 202.181.97.72 Received: from fsav402.sakura.ne.jp (fsav402.sakura.ne.jp [133.242.250.101]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8K73Sim058292; Sun, 20 Sep 2015 16:03:28 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav402.sakura.ne.jp (F-Secure/virusgw_smtp/412/fsav402.sakura.ne.jp); Sun, 20 Sep 2015 16:03:28 +0900 (JST) X-Virus-Status: clean(F-Secure/virusgw_smtp/412/fsav402.sakura.ne.jp) Received: from ccsecurity.localdomain (softbank126074231104.bbtec.net [126.74.231.104]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8K73LG6058226 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 20 Sep 2015 16:03:28 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) From: Tetsuo Handa To: david@fromorbit.com Cc: xfs@oss.sgi.com, linux-mm@kvack.org, Tetsuo Handa , Michal Hocko Subject: [PATCH 2/2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks Date: Sun, 20 Sep 2015 16:03:14 +0900 X-ASG-Orig-Subj: [PATCH 2/2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks Message-Id: <1442732594-4205-2-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1442732594-4205-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> References: <1442732594-4205-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> X-Barracuda-Connect: www262.sakura.ne.jp[202.181.97.72] X-Barracuda-Start-Time: 1442732616 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22716 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header This patch adds comm name and pid to warning messages printed by kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory(). This will help telling which memory allocations (e.g. kernel worker threads, OOM victim tasks, neither) are stalling. [ 135.568662] Out of memory: Kill process 9593 (a.out) score 998 or sacrifice child [ 135.570195] Killed process 9593 (a.out) total-vm:4700kB, anon-rss:488kB, file-rss:0kB [ 137.473691] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 137.497662] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 137.598219] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 139.494529] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 139.517196] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 139.616396] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 141.512753] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 141.531421] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 141.633574] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) (Strictly speaking, we want task_lock()/task_unlock() when reading comm name.) Signed-off-by: Tetsuo Handa Cc: Michal Hocko --- fs/xfs/kmem.c | 6 ++++-- fs/xfs/xfs_buf.c | 3 ++- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c index 1fcf90d..95a5b76 100644 --- a/fs/xfs/kmem.c +++ b/fs/xfs/kmem.c @@ -54,8 +54,9 @@ kmem_alloc(size_t size, xfs_km_flags_t flags) if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; if (!(++retries % 100)) - xfs_err(NULL, + xfs_err(NULL, "%s(%u) " "possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, __func__, lflags); congestion_wait(BLK_RW_ASYNC, HZ/50); } while (1); @@ -119,8 +120,9 @@ kmem_zone_alloc(kmem_zone_t *zone, xfs_km_flags_t flags) if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; if (!(++retries % 100)) - xfs_err(NULL, + xfs_err(NULL, "%s(%u) " "possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, __func__, lflags); congestion_wait(BLK_RW_ASYNC, HZ/50); } while (1); diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index cbd4f91..5deb629 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -353,8 +353,9 @@ retry: * handle buffer allocation failures we can't do much. */ if (!(++retries % 100)) - xfs_err(NULL, + xfs_err(NULL, "%s(%u) " "possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, __func__, gfp_mask); XFS_STATS_INC(xb_page_retries); -- 1.8.3.1 From penguin-kernel@I-love.SAKURA.ne.jp Sun Sep 20 02:03:41 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 99EC57F47 for ; Sun, 20 Sep 2015 02:03:41 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 23CB8AC003 for ; Sun, 20 Sep 2015 00:03:37 -0700 (PDT) X-ASG-Debug-ID: 1442732614-04cbb033b02a150001-NocioJ Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by cuda.sgi.com with ESMTP id S27eRWFKsEjLEIEB (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 20 Sep 2015 00:03:35 -0700 (PDT) X-Barracuda-Envelope-From: penguin-kernel@I-love.SAKURA.ne.jp X-Barracuda-Apparent-Source-IP: 202.181.97.72 Received: from fsav303.sakura.ne.jp (fsav303.sakura.ne.jp [153.120.85.134]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8K73Q4e058265; Sun, 20 Sep 2015 16:03:26 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav303.sakura.ne.jp (F-Secure/fsigk_smtp/522/fsav303.sakura.ne.jp); Sun, 20 Sep 2015 16:03:26 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/522/fsav303.sakura.ne.jp) Received: from ccsecurity.localdomain (softbank126074231104.bbtec.net [126.74.231.104]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8K73LG5058226 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 20 Sep 2015 16:03:26 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) From: Tetsuo Handa To: david@fromorbit.com Cc: xfs@oss.sgi.com, linux-mm@kvack.org, Tetsuo Handa , Michal Hocko Subject: [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations Date: Sun, 20 Sep 2015 16:03:13 +0900 X-ASG-Orig-Subj: [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations Message-Id: <1442732594-4205-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> X-Mailer: git-send-email 1.8.3.1 X-Barracuda-Connect: www262.sakura.ne.jp[202.181.97.72] X-Barracuda-Start-Time: 1442732615 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22716 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory() are doing open-coded __GFP_NOFAIL allocations with warning messages as a canary. But since small !__GFP_NOFAIL allocations retry forever inside memory allocator unless TIF_MEMDIE is set, the canary does not help even if allocations are stalling. Thus, this patch adds __GFP_NORETRY so that we can know possibility of allocation deadlock. If a patchset which makes small !__GFP_NOFAIL !__GFP_FS allocations not retry inside memory allocator is merged, warning messages by warn_alloc_failed() will dominate warning messages by the canary because each thread calls warn_alloc_failed() for approximately every 2 milliseconds. Thus, this patch also adds __GFP_NOWARN so that we won't flood kernel logs by these open-coded __GFP_NOFAIL allocations. Next patch compensates for lack of comm name and pid by addding them to the canary. Signed-off-by: Tetsuo Handa Cc: Michal Hocko --- fs/xfs/kmem.c | 4 ++-- fs/xfs/xfs_buf.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c index a7a3a63..1fcf90d 100644 --- a/fs/xfs/kmem.c +++ b/fs/xfs/kmem.c @@ -46,7 +46,7 @@ void * kmem_alloc(size_t size, xfs_km_flags_t flags) { int retries = 0; - gfp_t lflags = kmem_flags_convert(flags); + gfp_t lflags = kmem_flags_convert(flags) | __GFP_NORETRY | __GFP_NOWARN; void *ptr; do { @@ -111,7 +111,7 @@ void * kmem_zone_alloc(kmem_zone_t *zone, xfs_km_flags_t flags) { int retries = 0; - gfp_t lflags = kmem_flags_convert(flags); + gfp_t lflags = kmem_flags_convert(flags) | __GFP_NORETRY | __GFP_NOWARN; void *ptr; do { diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index 8ecffb3..cbd4f91 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -289,7 +289,7 @@ xfs_buf_allocate_memory( { size_t size; size_t nbytes, offset; - gfp_t gfp_mask = xb_to_gfp(flags); + gfp_t gfp_mask = xb_to_gfp(flags) | __GFP_NORETRY | __GFP_NOWARN; unsigned short page_count, i; xfs_off_t start, end; int error; -- 1.8.3.1 From david@fromorbit.com Sun Sep 20 18:12:26 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id C84587F37 for ; Sun, 20 Sep 2015 18:12:26 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id A29FC304032 for ; Sun, 20 Sep 2015 16:12:23 -0700 (PDT) X-ASG-Debug-ID: 1442790738-04bdf0462638460001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id JUMBT0NZC8XA6ODW for ; Sun, 20 Sep 2015 16:12:18 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D4CADSPP9VPOV8LHldgySBPYZZokwGinKRIQQCAoElTQEBAQEBAQcBAQEBQT+EJAEBBA4sHA8UEAgDDgoJJQ8FJQMHGhOILclTASsZhhOFRIUNB4QsBZIUg1CNA4FRhDWIeowegyaBUCwziW0BAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 21 Sep 2015 08:41:47 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Zdnlq-0004DV-VK; Mon, 21 Sep 2015 09:11:46 +1000 Date: Mon, 21 Sep 2015 09:11:46 +1000 From: Dave Chinner To: Tetsuo Handa Cc: xfs@oss.sgi.com, linux-mm@kvack.org, Michal Hocko Subject: Re: [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations Message-ID: <20150920231146.GX3902@dastard> X-ASG-Orig-Subj: Re: [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations References: <1442732594-4205-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442732594-4205-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442790738 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22735 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Sun, Sep 20, 2015 at 04:03:13PM +0900, Tetsuo Handa wrote: > kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory() are doing > open-coded __GFP_NOFAIL allocations with warning messages as a canary. > But since small !__GFP_NOFAIL allocations retry forever inside memory > allocator unless TIF_MEMDIE is set, the canary does not help even if > allocations are stalling. Thus, this patch adds __GFP_NORETRY so that > we can know possibility of allocation deadlock. > > If a patchset which makes small !__GFP_NOFAIL !__GFP_FS allocations not > retry inside memory allocator is merged, warning messages by > warn_alloc_failed() will dominate warning messages by the canary > because each thread calls warn_alloc_failed() for approximately > every 2 milliseconds. Thus, this patch also adds __GFP_NOWARN so that > we won't flood kernel logs by these open-coded __GFP_NOFAIL allocations. Please, at minimum, look at the code you are modifying. __GFP_NOWARN is already set by both kmem_flags_convert() and xb_to_gfp(), precisely for this reason. Any changes to the default gfp flags we use need to be inside those wrappers - that's why they exist. Further, xb_to_gfp() may already return just "__GFP_NORETRY | __GFP_NOWARN", so appending them unconditionally is clearly not the best approach. Further, fundamentally changing the allocation behaviour of the filesystem requires some indication of the testing and characterisation of how the change has impacted low memory balance and performance of the filesystem. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Sep 20 18:19:02 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id CDC7A7F37 for ; Sun, 20 Sep 2015 18:19:02 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 937D9304039 for ; Sun, 20 Sep 2015 16:19:02 -0700 (PDT) X-ASG-Debug-ID: 1442791139-04bdf04622385b0001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id GBCzYODdU6mrDthg for ; Sun, 20 Sep 2015 16:19:00 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BUCQAQPv9VPOV8LHldgySBPYZZokwGinKRIQICAQECgSVNAQEBAQEBBwEBAQFBP4QkAQEEJxMcIxAIAw4KCSUPBSUDBxoTiC3JVQEBCAIBHxmGE4VEhQ0HhCwFjH2IZ40DjwCMHoJ0HBaBUCwziW0BAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 21 Sep 2015 08:48:59 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Zdnso-0004E6-ON; Mon, 21 Sep 2015 09:18:58 +1000 Date: Mon, 21 Sep 2015 09:18:58 +1000 From: Dave Chinner To: Tetsuo Handa Cc: xfs@oss.sgi.com, linux-mm@kvack.org, Michal Hocko Subject: Re: [PATCH 2/2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks Message-ID: <20150920231858.GY3902@dastard> X-ASG-Orig-Subj: Re: [PATCH 2/2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks References: <1442732594-4205-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <1442732594-4205-2-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442732594-4205-2-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442791139 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22735 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Sun, Sep 20, 2015 at 04:03:14PM +0900, Tetsuo Handa wrote: > This patch adds comm name and pid to warning messages printed by > kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory(). > This will help telling which memory allocations (e.g. kernel worker > threads, OOM victim tasks, neither) are stalling. > > [ 135.568662] Out of memory: Kill process 9593 (a.out) score 998 or sacrifice child > [ 135.570195] Killed process 9593 (a.out) total-vm:4700kB, anon-rss:488kB, file-rss:0kB > [ 137.473691] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 137.497662] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 137.598219] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 139.494529] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 139.517196] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 139.616396] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 141.512753] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 141.531421] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 141.633574] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > > (Strictly speaking, we want task_lock()/task_unlock() when reading comm name.) > > Signed-off-by: Tetsuo Handa > Cc: Michal Hocko > --- > fs/xfs/kmem.c | 6 ++++-- > fs/xfs/xfs_buf.c | 3 ++- > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c > index 1fcf90d..95a5b76 100644 > --- a/fs/xfs/kmem.c > +++ b/fs/xfs/kmem.c > @@ -54,8 +54,9 @@ kmem_alloc(size_t size, xfs_km_flags_t flags) > if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) > return ptr; > if (!(++retries % 100)) > - xfs_err(NULL, > + xfs_err(NULL, "%s(%u) " > "possible memory allocation deadlock in %s (mode:0x%x)", > + current->comm, current->pid, > __func__, lflags); The format string will fit on a single line: "%s(%u): Possible memory allocation deadlock in %s (mode:0x%x)", Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Sun Sep 20 20:20:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 1DD937F37 for ; Sun, 20 Sep 2015 20:20:05 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id DE7918F8033 for ; Sun, 20 Sep 2015 18:20:01 -0700 (PDT) X-ASG-Debug-ID: 1442798392-04bdf046223a560001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id AG67sAYn9sGkPdiN for ; Sun, 20 Sep 2015 18:19:52 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BUCQBZWv9VPOV8LHldgySBPYZZokwGinKRIQICAQECgSZNAQEBAQEBBwEBAQFBP4QkAQEEOhwjEAgDDgoJJQ8FJQMHGhOILclYAQEIAiAZhhOFRIUNB4QsAQSVZI0Dmx6EdiwziW0BAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 21 Sep 2015 10:49:51 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Zdplm-0004OD-A1; Mon, 21 Sep 2015 11:19:50 +1000 Date: Mon, 21 Sep 2015 11:19:50 +1000 From: Dave Chinner To: Jan Kara Cc: fstests@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [PATCH] fstests: Add test of rename Message-ID: <20150921011950.GK26895@dastard> X-ASG-Orig-Subj: Re: [PATCH] fstests: Add test of rename References: <1440495730-14093-1-git-send-email-jack@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1440495730-14093-1-git-send-email-jack@suse.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442798392 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22739 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Aug 25, 2015 at 11:42:10AM +0200, Jan Kara wrote: > Test renaming of various entry types in directories of various sizes. > Check that filesystem didn't get corrupted. > > Signed-off-by: Jan Kara > --- > tests/generic/326 | 93 +++++++++++++++++++++++++++++++++++++++++++++++++++++ > tests/generic/group | 1 + > 2 files changed, 94 insertions(+) > create mode 100755 tests/generic/326 Missing an output file. I'll fix it on commit. > +if _check_scratch_fs; then > + _echofull "Scratch fs is fine after renames" > + status=0 > +fi This happens automatically now as a result of _require_scratch being called, so I'll remove it. Cheers, Dave. -- Dave Chinner david@fromorbit.com From penguin-kernel@I-love.SAKURA.ne.jp Sun Sep 20 20:23:50 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 8D8607F37 for ; Sun, 20 Sep 2015 20:23:50 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 6A453304032 for ; Sun, 20 Sep 2015 18:23:46 -0700 (PDT) X-ASG-Debug-ID: 1442798622-04cb6c6b0637930001-NocioJ Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by cuda.sgi.com with ESMTP id hdFU7xUtgdWbORpy (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 20 Sep 2015 18:23:45 -0700 (PDT) X-Barracuda-Envelope-From: penguin-kernel@I-love.SAKURA.ne.jp X-Barracuda-Apparent-Source-IP: 202.181.97.72 Received: from fsav301.sakura.ne.jp (fsav301.sakura.ne.jp [153.120.85.132]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8L1Nb8E042823; Mon, 21 Sep 2015 10:23:37 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav301.sakura.ne.jp (F-Secure/fsigk_smtp/522/fsav301.sakura.ne.jp); Mon, 21 Sep 2015 10:23:37 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/522/fsav301.sakura.ne.jp) Received: from AQUA (softbank126074231104.bbtec.net [126.74.231.104]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8L1NbHh042820; Mon, 21 Sep 2015 10:23:37 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) To: david@fromorbit.com Cc: xfs@oss.sgi.com, linux-mm@kvack.org, mhocko@suse.com Subject: Re: [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations From: Tetsuo Handa X-ASG-Orig-Subj: Re: [PATCH 1/2] xfs: Add __GFP_NORETRY and __GFP_NOWARN to open-coded __GFP_NOFAIL allocations References: <1442732594-4205-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <20150920231146.GX3902@dastard> In-Reply-To: <20150920231146.GX3902@dastard> Message-Id: <201509211023.GED18760.HOSMFFOFLtJOVQ@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Mon, 21 Sep 2015 10:23:37 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Barracuda-Connect: www262.sakura.ne.jp[202.181.97.72] X-Barracuda-Start-Time: 1442798624 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-ASG-Whitelist: Body =?UTF-8?B?aHR0cDovL21hcmNcLmluZm8vXD8=?= X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Dave Chinner wrote: > On Sun, Sep 20, 2015 at 04:03:13PM +0900, Tetsuo Handa wrote: > > kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory() are doing > > open-coded __GFP_NOFAIL allocations with warning messages as a canary. > > But since small !__GFP_NOFAIL allocations retry forever inside memory > > allocator unless TIF_MEMDIE is set, the canary does not help even if > > allocations are stalling. Thus, this patch adds __GFP_NORETRY so that > > we can know possibility of allocation deadlock. > > > > If a patchset which makes small !__GFP_NOFAIL !__GFP_FS allocations not > > retry inside memory allocator is merged, warning messages by > > warn_alloc_failed() will dominate warning messages by the canary > > because each thread calls warn_alloc_failed() for approximately > > every 2 milliseconds. Thus, this patch also adds __GFP_NOWARN so that > > we won't flood kernel logs by these open-coded __GFP_NOFAIL allocations. > > Please, at minimum, look at the code you are modifying. __GFP_NOWARN > is already set by both kmem_flags_convert() and xb_to_gfp(), > precisely for this reason. Any changes to the default gfp flags we > use need to be inside those wrappers - that's why they exist. Indeed. > > Further, xb_to_gfp() may already return just "__GFP_NORETRY | > __GFP_NOWARN", so appending them unconditionally is clearly not the > best approach. I see. > > Further, fundamentally changing the allocation behaviour of the > filesystem requires some indication of the testing and > characterisation of how the change has impacted low memory balance > and performance of the filesystem. Well, I don't have rich environment for evaluating how the change impacts low memory balance and performance of the filesystem. Therefore, I cancel this patch. Please reply if you have comments on "[RFC 0/8] Allow GFP_NOFS allocation to fail" patchset ( http://marc.info/?l=linux-mm&m=143876830616538 )? From penguin-kernel@I-love.SAKURA.ne.jp Sun Sep 20 20:24:13 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id C2E357F37 for ; Sun, 20 Sep 2015 20:24:13 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 913D3304032 for ; Sun, 20 Sep 2015 18:24:13 -0700 (PDT) X-ASG-Debug-ID: 1442798650-04bdf046283a660001-NocioJ Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by cuda.sgi.com with ESMTP id cDeMquz12QU3tL3P (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 20 Sep 2015 18:24:11 -0700 (PDT) X-Barracuda-Envelope-From: penguin-kernel@I-love.SAKURA.ne.jp X-Barracuda-Apparent-Source-IP: 202.181.97.72 Received: from fsav410.sakura.ne.jp (fsav410.sakura.ne.jp [133.242.250.109]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8L1O4gf042886; Mon, 21 Sep 2015 10:24:04 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav410.sakura.ne.jp (F-Secure/fsigk_smtp/520/fsav410.sakura.ne.jp); Mon, 21 Sep 2015 10:24:04 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/520/fsav410.sakura.ne.jp) Received: from ccsecurity.localdomain (softbank126074231104.bbtec.net [126.74.231.104]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8L1O0qu042880 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 Sep 2015 10:24:04 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) From: Tetsuo Handa To: david@fromorbit.com Cc: xfs@oss.sgi.com, linux-mm@kvack.org, Tetsuo Handa , Michal Hocko Subject: [PATCH v2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks Date: Mon, 21 Sep 2015 10:23:57 +0900 X-ASG-Orig-Subj: [PATCH v2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks Message-Id: <1442798637-5941-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <20150920231858.GY3902@dastard> References: <20150920231858.GY3902@dastard> X-Barracuda-Connect: www262.sakura.ne.jp[202.181.97.72] X-Barracuda-Start-Time: 1442798650 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22739 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header This patch adds comm name and pid to warning messages printed by kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory(). This will help telling which memory allocations (e.g. kernel worker threads, OOM victim tasks, neither) are stalling because these functions are passing __GFP_NOWARN which suppresses not only backtrace but comm name and pid. [ 135.568662] Out of memory: Kill process 9593 (a.out) score 998 or sacrifice child [ 135.570195] Killed process 9593 (a.out) total-vm:4700kB, anon-rss:488kB, file-rss:0kB [ 137.473691] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 137.497662] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 137.598219] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 139.494529] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 139.517196] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 139.616396] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 141.512753] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 141.531421] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) [ 141.633574] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) (Strictly speaking, we want task_lock()/task_unlock() when reading comm name.) Signed-off-by: Tetsuo Handa Cc: Michal Hocko --- fs/xfs/kmem.c | 10 ++++++---- fs/xfs/xfs_buf.c | 3 ++- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c index a7a3a63..735095a 100644 --- a/fs/xfs/kmem.c +++ b/fs/xfs/kmem.c @@ -55,8 +55,9 @@ kmem_alloc(size_t size, xfs_km_flags_t flags) return ptr; if (!(++retries % 100)) xfs_err(NULL, - "possible memory allocation deadlock in %s (mode:0x%x)", - __func__, lflags); + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, + __func__, lflags); congestion_wait(BLK_RW_ASYNC, HZ/50); } while (1); } @@ -120,8 +121,9 @@ kmem_zone_alloc(kmem_zone_t *zone, xfs_km_flags_t flags) return ptr; if (!(++retries % 100)) xfs_err(NULL, - "possible memory allocation deadlock in %s (mode:0x%x)", - __func__, lflags); + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, + __func__, lflags); congestion_wait(BLK_RW_ASYNC, HZ/50); } while (1); } diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index 8ecffb3..86785b5 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -354,7 +354,8 @@ retry: */ if (!(++retries % 100)) xfs_err(NULL, - "possible memory allocation deadlock in %s (mode:0x%x)", + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, __func__, gfp_mask); XFS_STATS_INC(xb_page_retries); -- 1.8.3.1 From 3dHv_VQkJAx8C9G9c.ceZBH5DG.7JHSANJNN.NBD.7JH@trix.bounces.google.com Sun Sep 20 22:37:29 2015 Return-Path: <3dHv_VQkJAx8C9G9c.ceZBH5DG.7JHSANJNN.NBD.7JH@trix.bounces.google.com> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE, T_DKIM_INVALID,T_REMOTE_IMAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 60E897F37 for ; Sun, 20 Sep 2015 22:37:29 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 4027F8F8035 for ; Sun, 20 Sep 2015 20:37:26 -0700 (PDT) X-ASG-Debug-ID: 1442806644-04cb6c6b0739b60001-NocioJ Received: from mail-pa0-f69.google.com (mail-pa0-f69.google.com [209.85.220.69]) by cuda.sgi.com with ESMTP id jKipDfrgylxgv6Vx (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 20 Sep 2015 20:37:25 -0700 (PDT) X-Barracuda-Envelope-From: 3dHv_VQkJAx8C9G9c.ceZBH5DG.7JHSANJNN.NBD.7JH@trix.bounces.google.com X-Barracuda-Apparent-Source-IP: 209.85.220.69 X-ASG-Whitelist: EmailCat (listserver) Received: by pacfr11 with SMTP id fr11so217621690pac.3 for ; Sun, 20 Sep 2015 20:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:message-id:date:subject:from:to:content-type; bh=ZrGMgYzKj0i6nXDsZHaiQFdAy7Agp8nvyvyvt9Li9EE=; b=kp+5kpIkcTy87hSam1wvTrNvbg+zSeK6qRpuJG5w1NgKmaFZAaYaWxSZnoFkka0Hts qSqBvJyrvVdMUEO9y2sxIbabeYn+MUpkXOELS7eHaOtxfFPjwfjKmkIUV9Pzf9NSTJhC P21BS6O3vWRClA8Uae7ZSZ3T1EDMkhr2iwSVmqE3yV4r9RgaKuXqGmAu2CdzSb8gdloj cAHWnjkTpCZny3ffY9Iea2p2AtekdcQEZPwydY5xSr9ysmIfHAFnOZA5KfPo+4KNSt8k QuYqohHFUOeU/Y0we3VUhDW9e5Nr1J5BpKHHe03jmoPVJDL+UJ3Z4VLk5MjPk3PB6aF2 yWDw== MIME-Version: 1.0 X-Received: by 10.66.102.73 with SMTP id fm9mt25301499pab.16.1442806644179; Sun, 20 Sep 2015 20:37:24 -0700 (PDT) Reply-To: hele7.794@gmail.com X-No-Auto-Attachment: 1 Message-ID: <047d7bd9098c819431052039992c@google.com> Date: Mon, 21 Sep 2015 03:37:24 +0000 Subject: =?GB2312?B?uN/Qp8vRy/fTyrz+tdjWt6Osv6q3otDFv6q3otPF1sq/zQ==?= =?GB2312?B?u6c=?= From: hele7.794@gmail.com X-ASG-Orig-Subj: =?GB2312?B?uN/Qp8vRy/fTyrz+tdjWt6Osv6q3otDFv6q3otPF1sq/zQ==?= =?GB2312?B?u6c=?= To: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=047d7bd9098c83a7a90520399917 X-Barracuda-Connect: mail-pa0-f69.google.com[209.85.220.69] X-Barracuda-Start-Time: 1442806644 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 --047d7bd9098c83a7a90520399917 Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-Transfer-Encoding: base64 zeLDs7/Nu6e/qreix+HLycjrw8Wjuw0KMaGiyO28/tXrttTN4sOz0NDStbXEv827p7+qt6LPtc2z o6y+39PQvqrIy7XEv827p8vRy/fL2bbIus23x7OjusO1xM3GueMNCtCnufujuw0KMqGiv8nS1MD7 08PE48PHtcSy+sa3tcShsLnYvPy0yqGxy9HL97P2xOPDx9DQ0rW1xMv509C1xL6tz/rJzKOsvfi/ 2g0KycyjrE9FTcnMtcjL+dPQtcTBqs+1t73KvaOs1rG799bVtsu/zbuno7sNCjOhos3qyKux3L+q QjJCtcS827jx1b2jrNW5u+G1xLPJsb6436Os1ve2r7P2u/fRuMvZ1dK1vdXm1f221MTjw8ey+sa3 uNDQyw0KyKS1xL/Nu6ejuw0KvNNRoaRRo7ozMTUwMDU4NTU01NrP38Pit9HR3cq+1PXDtNb3tq+/ qreiv827p6OszOHJ/b/Nu6fWysG/tcShow0KSSd2ZSBpbnZpdGVkIHlvdSB0byBmaWxsIG91dCB0 aGUgZm9ybSDQxM/rysKzySgqXl9fXiopIC4gVG8gZmlsbCBpdA0Kb3V0LCB2aXNpdDoNCmh0dHBz Oi8vZG9jcy5nb29nbGUuY29tL2Zvcm1zL2QvMURsX1Q5SnZMNTF2SThLYkR4blNjRjhfc29sSmpu TzVkVWo1X2JWMlIzR0kvdmlld2Zvcm0/Yz0wJnc9MSZ1c3A9bWFpbF9mb3JtX2xpbmsNCg== --047d7bd9098c83a7a90520399917 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

=CD=E2=C3=B3=BF=CD=BB=A7=BF=AA=B7=A2= =C7=E1=CB=C9=C8=EB=C3=C5=A3=BB
1=A1=A2=C8=ED=BC=FE=D5=EB=B6=D4=CD=E2=C3= =B3=D0=D0=D2=B5=B5=C4=BF=CD=BB=A7=BF=AA=B7=A2=CF=B5=CD=B3=A3=AC=BE=DF=D3=D0= =BE=AA=C8=CB=B5=C4=BF=CD=BB=A7=CB=D1=CB=F7=CB=D9=B6=C8=BA=CD=B7=C7=B3=A3=BA= =C3=B5=C4=CD=C6=B9=E3=D0=A7=B9=FB=A3=BB
2=A1=A2=BF=C9=D2=D4=C0=FB=D3=C3= =C4=E3=C3=C7=B5=C4=B2=FA=C6=B7=B5=C4=A1=B0=B9=D8=BC=FC=B4=CA=A1=B1=CB=D1=CB= =F7=B3=F6=C4=E3=C3=C7=D0=D0=D2=B5=B5=C4=CB=F9=D3=D0=B5=C4=BE=AD=CF=FA=C9=CC= =A3=AC=BD=F8=BF=DA=C9=CC=A3=ACOEM=C9=CC=B5=C8=CB=F9=D3=D0=B5=C4=C1=AA=CF=B5= =B7=BD=CA=BD=A3=AC=D6=B1=BB=F7=D6=D5=B6=CB=BF=CD=BB=A7=A3=BB
3=A1=A2=CD= =EA=C8=AB=B1=DC=BF=AAB2B=B5=C4=BC=DB=B8=F1=D5=BD=A3=AC=D5=B9=BB=E1=B5=C4=B3= =C9=B1=BE=B8=DF=A3=AC=D6=F7=B6=AF=B3=F6=BB=F7=D1=B8=CB=D9=D5=D2=B5=BD=D5=E6= =D5=FD=B6=D4=C4=E3=C3=C7=B2=FA=C6=B7=B8=D0=D0=CB=C8=A4=B5=C4=BF=CD=BB=A7=A3= =BB
=BC=D3Q=A1=A4Q=A3=BA3150058554=D4=DA=CF=DF=C3=E2=B7=D1=D1=DD=CA=BE= =D4=F5=C3=B4=D6=F7=B6=AF=BF=AA=B7=A2=BF=CD=BB=A7=A3=AC=CC=E1=C9=FD=BF=CD=BB= =A7=D6=CA=C1=BF=B5=C4=A1=A3

If you have trouble viewing or submitting this form, you can fill it out in= Google Forms.

=D0=C4=CF=EB=CA=C2= =B3=C9(*^__^*)

P= owered by
3D"Google
This content is neither create= d nor endorsed by Google.
Report Abuse - Terms of Service<= /a> - Addition= al Terms

<= /html> --047d7bd9098c83a7a90520399917-- From cmaiolino@redhat.com Mon Sep 21 02:03:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 791F87F37 for ; Mon, 21 Sep 2015 02:03:22 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id E8AA3AC003 for ; Mon, 21 Sep 2015 00:03:18 -0700 (PDT) X-ASG-Debug-ID: 1442818997-04cb6c6b043d4f0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id tr7WiUtwzI3eX4Vb (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 21 Sep 2015 00:03:17 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 14B058E3F3; Mon, 21 Sep 2015 07:03:17 +0000 (UTC) Received: from redhat.com (vpn-225-125.phx2.redhat.com [10.3.225.125]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8L73DrU029064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 21 Sep 2015 03:03:15 -0400 Date: Mon, 21 Sep 2015 09:03:12 +0200 From: Carlos Maiolino To: Dave Chinner Cc: Troy McCorkell , carlos.e.r@opensuse.org, xfs@oss.sgi.com Subject: Re: What's up with this list? Message-ID: <20150921070312.GA2617@redhat.com> X-ASG-Orig-Subj: Re: What's up with this list? Mail-Followup-To: Dave Chinner , Troy McCorkell , carlos.e.r@opensuse.org, xfs@oss.sgi.com References: <541AFB60.5030403@sgi.com> <55FAF053.3020405@sgi.com> <55FB06E8.1020203@opensuse.org> <55FC3569.5020801@sgi.com> <20150918225624.GF26895@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150918225624.GF26895@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442818997 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Sat, Sep 19, 2015 at 08:56:24AM +1000, Dave Chinner wrote: > On Fri, Sep 18, 2015 at 11:01:45AM -0500, Troy McCorkell wrote: > > xfs@oss.sgi.com is an open list and does not require people to be members > > of the list to post to it. The spam filters applied to > > xfs@oss.sgi.com are > > as aggressive as they can be and still allow for an open list. > > > > Next option would be to add a moderator to the list. Adding a moderator > > would interfere with non-list members posting to the list. > > Moderation is not an option because of this interference and the > burden it puts on the moderator to respond in a timely fashion. > > If the spam rejection does not improve our next option is to move to > the linux-xfs@vger.kernel.org list - the vger infrastructure is not > perfect, but it does have better spam rejection than the current > filtering on this list. This may be the best long-term solution to > the problem, but it does involve short term pain for everyone. > +1 for that, the pain is not that much, and we've discussed moving xfs list to vger.kernel.org for a while, I really don't see a reason to do so, other than people needing to update their e-mail addresses and maybe git configurations. To relief even more the pain, xfs@sgi, could just forward the e-mails to linux-xfs with a InReplyTo modified to linux-xfs even. Althouh, I'm not sure how feasible is the last part. > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- Carlos From cmaiolino@redhat.com Mon Sep 21 03:56:18 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id D3A767F37 for ; Mon, 21 Sep 2015 03:56:18 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id B59158F8049 for ; Mon, 21 Sep 2015 01:56:15 -0700 (PDT) X-ASG-Debug-ID: 1442825774-04cb6c6b05400c0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id nKdvimWGFVVFlh0D (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 21 Sep 2015 01:56:14 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 36A3224B for ; Mon, 21 Sep 2015 08:56:14 +0000 (UTC) Received: from zion.usersys.redhat.com (vpn-225-125.phx2.redhat.com [10.3.225.125]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8L8uCUv011786 for ; Mon, 21 Sep 2015 04:56:13 -0400 From: Carlos Maiolino To: xfs@oss.sgi.com Subject: [PATCH] xfs_io: Implement inodes64 command Date: Mon, 21 Sep 2015 10:56:08 +0200 X-ASG-Orig-Subj: [PATCH] xfs_io: Implement inodes64 command Message-Id: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442825774 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Implement an easy way to check a filesystem for the existence of 64bit inodes. Based on XFS_IOC_FSINUMBERS, and starting with a lastip of XFS_MAXINUMBER_32, it returns a string saying if there is or there isn't 64bit inodes in the filesystem. Signed-off-by: Carlos Maiolino --- io/open.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/io/open.c b/io/open.c index ac5a5e0..b25b09d 100644 --- a/io/open.c +++ b/io/open.c @@ -20,6 +20,7 @@ #include "input.h" #include "init.h" #include "io.h" +#include "libxfs.h" #ifndef __O_TMPFILE #if defined __alpha__ @@ -44,6 +45,7 @@ static cmdinfo_t statfs_cmd; static cmdinfo_t chproj_cmd; static cmdinfo_t lsproj_cmd; static cmdinfo_t extsize_cmd; +static cmdinfo_t inodes64_cmd; static prid_t prid; static long extsize; @@ -750,6 +752,36 @@ statfs_f( return 0; } +static int +inodes64_f( + int argc, + char **argv) +{ + int i; + __s32 count; + __u64 last = XFS_MAXINUMBER_32; + xfs_inogrp_t igroup; + xfs_fsop_bulkreq_t bulkreq; + + bulkreq.lastip = &last; + bulkreq.icount = 1; + bulkreq.ubuffer = &igroup; + bulkreq.ocount = &count; + + if (!xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { + if (count > 0) { + printf("Filesystem does have 64bit inodes\n"); + return 0; + } else { + printf("Filesystem does not have 64bit inodes\n"); + return 0; + } + } + perror("xfsctl(XFS_IOC_FSINUMBERS)"); + exitcode = 1; + return 0; +} + void open_init(void) { @@ -815,6 +847,12 @@ open_init(void) _("get/set preferred extent size (in bytes) for the open file"); extsize_cmd.help = extsize_help; + inodes64_cmd.name = "inodes64"; + inodes64_cmd.cfunc = inodes64_f; + inodes64_cmd.flags = CMD_NOMAP_OK; + inodes64_cmd.oneline = + _("Checks if filesyste contais 64bit inodes"); + add_command(&open_cmd); add_command(&stat_cmd); add_command(&close_cmd); @@ -822,4 +860,5 @@ open_init(void) add_command(&chproj_cmd); add_command(&lsproj_cmd); add_command(&extsize_cmd); + add_command(&inodes64_cmd); } -- 2.4.3 From eun@gmail.com Mon Sep 21 04:26:44 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.4 required=5.0 tests=FREEMAIL_FROM,FREEMAIL_REPLYTO, HTML_MESSAGE,TO_NO_BRKTS_MSFT autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 56F3B7F37 for ; Mon, 21 Sep 2015 04:26:44 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id D7F5CAC001 for ; Mon, 21 Sep 2015 02:26:40 -0700 (PDT) X-ASG-Debug-ID: 1442827595-04cb6c6b0640b70001-NocioJ Received: from mxout7.netvision.net.il (mxout7.netvision.net.il [194.90.6.2]) by cuda.sgi.com with ESMTP id 4c5uBQk0mj2qmL3d for ; Mon, 21 Sep 2015 02:26:35 -0700 (PDT) X-Barracuda-Envelope-From: eun@gmail.com X-Barracuda-Apparent-Source-IP: 194.90.6.2 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_XaJwxytc9R3Z1f0x5zOqvg)" Received: from pool-31-207-194-63.is74.ru ([31.207.194.63]) by mxout7.netvision.net.il (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0NV000J7TSW8IW00@mxout7.netvision.net.il> for xfs@oss.sgi.com; Mon, 21 Sep 2015 12:26:34 +0300 (IDT) Message-id: Reply-to: 7753191$ From: 7753191$ To: xfs@oss.sgi.com Subject: =?windows-1251?B?yOv+9e7iIFJlOiDTIOzt7uPo9SDz5uUg7+7r?= =?windows-1251?B?8/fo6+7x/CDn4PDg4e7y4PL8ISDP8Ojx7uXk?= =?windows-1251?B?6O3/6fH/IQ==?= Date: Mon, 21 Sep 2015 13:24:30 +0400 X-ASG-Orig-Subj: =?windows-1251?B?yOv+9e7iIFJlOiDTIOzt7uPo9SDz5uUg7+7r?= =?windows-1251?B?8/fo6+7x/CDn4PDg4e7y4PL8ISDP8Ojx7uXk?= =?windows-1251?B?6O3/6fH/IQ==?= Organization: 7753191$ X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Barracuda-Connect: mxout7.netvision.net.il[194.90.6.2] X-Barracuda-Start-Time: 1442827595 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.70 X-Barracuda-Spam-Status: No, SCORE=0.70 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MV0646, BSF_SC0_SA584, BSF_SC0_TG035a, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22747 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SC0_TG035a Message contains invalid style definition 0.50 BSF_SC0_MV0646 Custom rule MV0646 0.20 BSF_SC0_SA584 Custom Rule SA584 This is a multi-part message in MIME format. --Boundary_(ID_XaJwxytc9R3Z1f0x5zOqvg) Content-type: text/plain; charset=windows-1251 Content-transfer-encoding: quoted-printable =C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5 xfs@oss.sgi.com=20 =D5=EE=F7=E5=F8=FC =EC=ED=EE=E3=EE =E4=E5=ED=E5=E3 - =F2=E5=E1=E5 =F1=FE=E4= =E0! [gvufs] http://goo.gl/6wjW1k =D1 =D3=C2: 21.09.2015 - 13:24:30=20 --Boundary_(ID_XaJwxytc9R3Z1f0x5zOqvg) Content-type: text/html; charset=windows-1251 Content-transfer-encoding: quoted-printable
=C7=E4=F0=E0=E2=F1=F2=E2=F3= =E9=F2=E5 xfs@oss.sgi.com=20
=D5=EE=F7=E5=F8=FC =EC=ED=EE=E3=EE =E4=E5=ED=E5=E3 - =F2=E5=E1=E5 =F1= =FE=E4=E0! [gvufs]
164455 $-->>>
=D1 =D3=C2: 21.09.2015= -=20 13:24:30
--Boundary_(ID_XaJwxytc9R3Z1f0x5zOqvg)-- From robin.listas@gmail.com Mon Sep 21 05:03:32 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id F2E657F37 for ; Mon, 21 Sep 2015 05:03:31 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id C28F48F8040 for ; Mon, 21 Sep 2015 03:03:28 -0700 (PDT) X-ASG-Debug-ID: 1442829799-04bdf0462746a40001-NocioJ Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by cuda.sgi.com with ESMTP id rV8kkui3ftSqy4ze (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 21 Sep 2015 03:03:19 -0700 (PDT) X-Barracuda-Envelope-From: robin.listas@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.212.182 Received: by wicge5 with SMTP id ge5so108209994wic.0 for ; Mon, 21 Sep 2015 03:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type:content-id; bh=tOAELK1mNad2ToR0ja9QySUOAeP8N4VKqYebnber5mc=; b=mODtP9/G5+Gdh35s5v3WPbWf4P8s/KACwHK0MhGeui5FNY6jeJU1xVNoe+2wbpPTFL s+cBXnSV9P3EBWq0AmlEVo/w/by7QvScuDK5YvrXIA3W9T3BmBol8UGDUqpWeDw0Bdw1 XRqOlAN0bvm1ea7R3o3sCfv9EBO7ZKJWm6B+TGClDB8TND7nJ7GjaYxfPnxkYoyHV8Kb 7b6z8tpNzrPn7JYXBOci/u3k0IfyV64XSfpcuTJmqke9FJHjgDyFwoQ/jBAvpakKtX9s iep9LCM1Wu+EFOMJC+tVzGRJ/8E+Ri0iL61dmR3yppsXLnHQFwA/v6JlwmoZ9LfhGNu0 nBdA== X-Received: by 10.180.12.145 with SMTP id y17mr12849950wib.83.1442829798484; Mon, 21 Sep 2015 03:03:18 -0700 (PDT) Received: from minas-tirith.valinor (221.Red-2-140-92.dynamicIP.rima-tde.net. [2.140.92.221]) by smtp.gmail.com with ESMTPSA id cx3sm23255468wjc.27.2015.09.21.03.03.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Sep 2015 03:03:17 -0700 (PDT) Sender: Carlos Robinson Received: from localhost (localhost [127.0.0.1]) by minas-tirith.valinor (Postfix) with ESMTP id 927A518286E for ; Mon, 21 Sep 2015 12:03:08 +0200 (CEST) Date: Mon, 21 Sep 2015 12:02:58 +0200 (CEST) From: "Carlos E. R." X-X-Sender: cer@minas-tirith.valinor To: XFS mailing list Subject: Re: What's up with this list? In-Reply-To: X-ASG-Orig-Subj: Re: What's up with this list? Message-ID: References: <541AFB60.5030403@sgi.com> <55FAF053.3020405@sgi.com> <55FB06E8.1020203@opensuse.org> <55FC3569.5020801@sgi.com> <20150918225624.GF26895@dastard> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463758550-1540614313-1442829649=:24753" Content-ID: X-Barracuda-Connect: mail-wi0-f182.google.com[209.85.212.182] X-Barracuda-Start-Time: 1442829799 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22747 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463758550-1540614313-1442829649=:24753 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: El 2015-09-19 a las 13:52 +0200, Carlos E. R. escribió: > To re-enable your membership, you can simply respond to this message > (leaving the Subject: line intact), or visit the confirmation page at > > > THAT is the problem I'm having. The spam I get I can filter out, it is not > that bad. See how frequent it is: X 4434 14-08-31 16:20 xfs-request@oss.sgi.com (3931) confirm c706bfb352b42c74758b652ef1378b81002b724b X 4769 14-09-18 01:53 xfs-request@oss.sgi.com (4169) confirm e22de168da621e139335f532773c160ba9e26da9 X 5291 14-10-17 11:28 xfs-request@oss.sgi.com (4169) confirm fd7fd355f3c9235210d1db382713e95e29760dd5 X 5628 14-11-06 06:46 xfs-request@oss.sgi.com (4165) confirm 61426741797fd5050e2f1f55d0dc5260cd4f9684 X 6196 14-12-27 05:42 xfs-request@oss.sgi.com (4166) confirm 8a23e93612ea5b3287ab1b47dfeeb40ff96c6db7 X 6787 15-02-10 05:20 xfs-request@oss.sgi.com (3733) confirm 8417559808c8eee163d93343717004747a589fe9 X 7282 15-03-15 22:13 xfs-request@oss.sgi.com (3733) confirm 5f12062a2ad09d461a99e934af624b776abb64ae X 7529 15-03-28 13:29 xfs-request@oss.sgi.com (3735) confirm 5cadd0c89284d0ec3e6e1dbf4e26d7717eb3770c X 8062 15-05-14 04:35 xfs-request@oss.sgi.com (4224) confirm 0d8739847c3b8c11df497bd57e4f39831a110fe4 X 8100 15-05-25 09:57 xfs-request@oss.sgi.com (4224) confirm b0967d8558a96e20601b3259c8cb512f61f73212 X 8260 15-06-06 22:02 xfs-request@oss.sgi.com (4221) confirm 1f01a2b717a50d6df4fdb37eec5628bd645e105b X 8430 15-06-20 08:43 xfs-request@oss.sgi.com (4223) confirm 2d9b43b9bf7db276432ef4e527dbcd81ed6b3c12 X 8556 15-06-30 11:44 xfs-request@oss.sgi.com (3736) confirm 4953159bc1315891147b0b3d0e3a34adaeccff34 X 8719 15-07-16 09:00 xfs-request@oss.sgi.com (3735) confirm 72781f7c7177a3fd5e21d3f487bae5d42082abfe X 8747 15-07-23 10:04 xfs-request@oss.sgi.com (3736) confirm b11f194b6da57b46a62a13ae185bbc4677fd9120 X 8885 15-08-03 10:36 xfs-request@oss.sgi.com (4220) confirm 94cf2c9ffd5f48909d3aa5d0159d310756ae8a14 X 9077 15-08-12 10:03 xfs-request@oss.sgi.com (4223) confirm 12ee9b4720921c68209e95255fbe1e130444c4b6 X 9311 15-08-23 10:31 xfs-request@oss.sgi.com (4223) confirm fd0b55cf93d7323c177de55f7a981bf13c7f699b X 9635 15-09-04 10:55 xfs-request@oss.sgi.com (4222) confirm bd1e72efe20cf78e76a605db5d0a7c7de0ab3318 X 9854 15-09-16 01:08 xfs-request@oss.sgi.com (4225) confirm c107ce18b6e885bcc572a65cd7dc73ecba7334dc - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlX/1dwACgkQja8UbcUWM1xm3QD+Im7KHmJkfmrTaI+E86p61vy2 tAhu1CaM8KuL1BMyzvYA/iNM+nthggpzvu5GGkb0rEf+Cy33ypPa/ukbDXh+fDsR =RLEU -----END PGP SIGNATURE----- ---1463758550-1540614313-1442829649=:24753-- From penguin-kernel@I-love.SAKURA.ne.jp Mon Sep 21 06:10:32 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 45A457F37 for ; Mon, 21 Sep 2015 06:10:32 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 36E87304032 for ; Mon, 21 Sep 2015 04:10:28 -0700 (PDT) X-ASG-Debug-ID: 1442833823-04cb6c6b0743c00001-NocioJ Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by cuda.sgi.com with ESMTP id 8CVRXQKIoHhd5SCC (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 21 Sep 2015 04:10:24 -0700 (PDT) X-Barracuda-Envelope-From: penguin-kernel@I-love.SAKURA.ne.jp X-Barracuda-Apparent-Source-IP: 202.181.97.72 Received: from fsav101.sakura.ne.jp (fsav101.sakura.ne.jp [27.133.134.228]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8LBADYa033343; Mon, 21 Sep 2015 20:10:13 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav101.sakura.ne.jp (F-Secure/fsigk_smtp/522/fsav101.sakura.ne.jp); Mon, 21 Sep 2015 20:10:13 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/522/fsav101.sakura.ne.jp) Received: from localhost.localdomain (softbank126074231104.bbtec.net [126.74.231.104]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8LBA8JX033332 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 Sep 2015 20:10:13 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) From: Tetsuo Handa To: david@fromorbit.com Cc: xfs@oss.sgi.com, linux-mm@kvack.org, Tetsuo Handa Subject: [PATCH] mm, vmscan: Warn about possible deadlock at shirink_inactive_list Date: Mon, 21 Sep 2015 20:09:54 +0900 X-ASG-Orig-Subj: [PATCH] mm, vmscan: Warn about possible deadlock at shirink_inactive_list Message-Id: <1442833794-23117-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> X-Mailer: git-send-email 1.8.3.1 X-Barracuda-Connect: www262.sakura.ne.jp[202.181.97.72] X-Barracuda-Start-Time: 1442833824 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22748 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header This is a difficult-to-trigger silent hang up bug. The kswapd is allowed to bypass too_many_isolated() check in shrink_inactive_list(). But the kswapd can be blocked by locks in shrink_page_list() in shrink_inactive_list(). If the task which is blocking the kswapd is trying to allocate memory with the locks held, it forms memory reclaim deadlock. ---------- [ 142.870301] kswapd0 D ffff88007fcd5b80 0 51 2 0x00000000 [ 142.871941] ffff88007c98f660 0000000000000046 ffff88007cde4c80 ffff88007c990000 [ 142.873772] ffff880035d08b40 ffff880035d08b58 ffff880079e4a828 ffff88007c98f890 [ 142.875544] ffff88007c98f678 ffffffff81632c68 ffff88007cde4c80 ffff88007c98f6d8 [ 142.877338] Call Trace: [ 142.878220] [] schedule+0x38/0x90 [ 142.879477] [] rwsem_down_read_failed+0xd3/0x140 [ 142.880937] [] call_rwsem_down_read_failed+0x14/0x30 [ 142.882595] [] ? down_read+0x12/0x20 [ 142.883882] [] xfs_log_commit_cil+0x5b/0x460 [ 142.885326] [] __xfs_trans_commit+0x10b/0x1f0 [ 142.886756] [] xfs_trans_commit+0xb/0x10 [ 142.888085] [] xfs_iomap_write_allocate+0x165/0x320 [ 142.889657] [] xfs_map_blocks+0x15a/0x170 [ 142.891002] [] xfs_vm_writepage+0x18b/0x5a0 [ 142.892372] [] pageout.isra.42+0x18c/0x250 [ 142.893813] [] shrink_page_list+0x650/0xa10 [ 142.895182] [] shrink_inactive_list+0x1f2/0x560 [ 142.896606] [] shrink_lruvec+0x59f/0x760 [ 142.898037] [] shrink_zone+0xa6/0x2d0 [ 142.899320] [] kswapd+0x4c2/0x8e0 [ 142.900545] [] ? mem_cgroup_shrink_node_zone+0xe0/0xe0 [ 142.902152] [] kthread+0xd3/0xf0 [ 142.903381] [] ? kthread_create_on_node+0x1a0/0x1a0 [ 142.904919] [] ret_from_fork+0x3f/0x70 [ 142.906237] [] ? kthread_create_on_node+0x1a0/0x1a0 (...snipped...) [ 148.995189] a.out D ffffffff813360c7 0 7821 7788 0x00000080 [ 148.996854] ffff88007c6b73d8 0000000000000086 ffff880078e7f2c0 ffff88007c6b8000 [ 148.998583] ffff88007c6b7410 ffff88007fc8dfc0 00000000fffd94f9 0000000000000002 [ 149.000560] ffff88007c6b73f0 ffffffff81632c68 ffff88007fc8dfc0 ffff88007c6b7470 [ 149.002415] Call Trace: [ 149.003285] [] schedule+0x38/0x90 [ 149.004624] [] schedule_timeout+0x122/0x1c0 [ 149.006003] [] ? preempt_count_add+0x43/0x90 [ 149.007412] [] ? cascade+0x90/0x90 [ 149.008704] [] io_schedule_timeout+0xa1/0x110 [ 149.010109] [] congestion_wait+0x7d/0xd0 [ 149.011536] [] ? wait_woken+0x80/0x80 [ 149.012891] [] shrink_inactive_list+0x519/0x560 [ 149.014327] [] ? check_preempt_wakeup+0x10e/0x1f0 [ 149.015867] [] shrink_lruvec+0x59f/0x760 [ 149.017340] [] ? mem_cgroup_iter+0xef/0x4e0 [ 149.018742] [] shrink_zone+0xa6/0x2d0 [ 149.020150] [] do_try_to_free_pages+0x164/0x420 [ 149.021605] [] try_to_free_pages+0x94/0xc0 [ 149.022968] [] __alloc_pages_nodemask+0x4fb/0x930 [ 149.024476] [] alloc_pages_current+0x8c/0x100 [ 149.025883] [] new_slab+0x458/0x4d0 [ 149.027209] [] ___slab_alloc+0x49e/0x610 [ 149.028580] [] ? kmem_alloc+0x74/0xe0 [ 149.029864] [] ? update_curr+0x58/0xe0 [ 149.031327] [] ? update_cfs_shares+0xad/0xf0 [ 149.032808] [] ? dequeue_entity+0x1e9/0x800 [ 149.034301] [] __slab_alloc.isra.67+0x53/0x6f [ 149.035780] [] ? kmem_alloc+0x74/0xe0 [ 149.037076] [] ? kmem_alloc+0x74/0xe0 [ 149.038344] [] __kmalloc+0x14d/0x1a0 [ 149.039677] [] kmem_alloc+0x74/0xe0 [ 149.040940] [] xfs_log_commit_cil+0x352/0x460 [ 149.042321] [] __xfs_trans_commit+0x10b/0x1f0 [ 149.043733] [] xfs_trans_commit+0xb/0x10 [ 149.045065] [] xfs_vn_update_time+0xdf/0x130 [ 149.046430] [] file_update_time+0xb8/0x110 [ 149.047833] [] xfs_file_aio_write_checks+0x16e/0x1c0 [ 149.049386] [] xfs_file_buffered_aio_write+0x79/0x1f0 [ 149.051031] [] ? _raw_spin_lock_irqsave+0x25/0x50 [ 149.052581] [] ? _raw_spin_unlock_irqrestore+0x1f/0x40 [ 149.054084] [] xfs_file_write_iter+0x74/0x110 [ 149.055729] [] __vfs_write+0xc7/0x100 [ 149.057023] [] vfs_write+0xa4/0x190 [ 149.058330] [] SyS_write+0x50/0xc0 [ 149.059553] [] ? do_fsync+0x38/0x60 [ 149.060811] [] entry_SYSCALL_64_fastpath+0x12/0x71 (...snipped...) [ 264.199092] kswapd0 D ffff88007fcd5b80 0 51 2 0x00000000 [ 264.200724] ffff88007c98f660 0000000000000046 ffff88007cde4c80 ffff88007c990000 [ 264.202469] ffff880035d08b40 ffff880035d08b58 ffff880079e4a828 ffff88007c98f890 [ 264.204233] ffff88007c98f678 ffffffff81632c68 ffff88007cde4c80 ffff88007c98f6d8 [ 264.206173] Call Trace: [ 264.207202] [] schedule+0x38/0x90 [ 264.208536] [] rwsem_down_read_failed+0xd3/0x140 [ 264.210044] [] call_rwsem_down_read_failed+0x14/0x30 [ 264.211602] [] ? down_read+0x12/0x20 [ 264.212929] [] xfs_log_commit_cil+0x5b/0x460 [ 264.214369] [] __xfs_trans_commit+0x10b/0x1f0 [ 264.215820] [] xfs_trans_commit+0xb/0x10 [ 264.217193] [] xfs_iomap_write_allocate+0x165/0x320 [ 264.218721] [] xfs_map_blocks+0x15a/0x170 [ 264.220109] [] xfs_vm_writepage+0x18b/0x5a0 [ 264.221586] [] pageout.isra.42+0x18c/0x250 [ 264.222989] [] shrink_page_list+0x650/0xa10 [ 264.224404] [] shrink_inactive_list+0x1f2/0x560 [ 264.225876] [] shrink_lruvec+0x59f/0x760 [ 264.227248] [] shrink_zone+0xa6/0x2d0 [ 264.228573] [] kswapd+0x4c2/0x8e0 [ 264.229840] [] ? mem_cgroup_shrink_node_zone+0xe0/0xe0 [ 264.231407] [] kthread+0xd3/0xf0 [ 264.232662] [] ? kthread_create_on_node+0x1a0/0x1a0 [ 264.234185] [] ret_from_fork+0x3f/0x70 [ 264.235527] [] ? kthread_create_on_node+0x1a0/0x1a0 (...snipped...) [ 270.339774] a.out D ffffffff813360c7 0 7821 7788 0x00000080 [ 270.341391] ffff88007c6b73d8 0000000000000086 ffff880078e7f2c0 ffff88007c6b8000 [ 270.343114] ffff88007c6b7410 ffff88007fc4dfc0 00000000ffff8b29 0000000000000002 [ 270.344859] ffff88007c6b73f0 ffffffff81632c68 ffff88007fc4dfc0 ffff88007c6b7470 [ 270.346670] Call Trace: [ 270.347608] [] schedule+0x38/0x90 [ 270.348929] [] schedule_timeout+0x122/0x1c0 [ 270.350354] [] ? preempt_count_add+0x43/0x90 [ 270.351790] [] ? cascade+0x90/0x90 [ 270.353106] [] io_schedule_timeout+0xa1/0x110 [ 270.354558] [] congestion_wait+0x7d/0xd0 [ 270.355958] [] ? wait_woken+0x80/0x80 [ 270.357298] [] shrink_inactive_list+0x519/0x560 [ 270.358779] [] ? check_preempt_wakeup+0x10e/0x1f0 [ 270.360307] [] shrink_lruvec+0x59f/0x760 [ 270.361687] [] ? mem_cgroup_iter+0xef/0x4e0 [ 270.363147] [] shrink_zone+0xa6/0x2d0 [ 270.364462] [] do_try_to_free_pages+0x164/0x420 [ 270.365898] [] try_to_free_pages+0x94/0xc0 [ 270.367261] [] __alloc_pages_nodemask+0x4fb/0x930 [ 270.368744] [] alloc_pages_current+0x8c/0x100 [ 270.370151] [] new_slab+0x458/0x4d0 [ 270.371420] [] ___slab_alloc+0x49e/0x610 [ 270.372769] [] ? kmem_alloc+0x74/0xe0 [ 270.374053] [] ? update_curr+0x58/0xe0 [ 270.375351] [] ? update_cfs_shares+0xad/0xf0 [ 270.376748] [] ? dequeue_entity+0x1e9/0x800 [ 270.378200] [] __slab_alloc.isra.67+0x53/0x6f [ 270.379604] [] ? kmem_alloc+0x74/0xe0 [ 270.380879] [] ? kmem_alloc+0x74/0xe0 [ 270.382148] [] __kmalloc+0x14d/0x1a0 [ 270.383424] [] kmem_alloc+0x74/0xe0 [ 270.384668] [] xfs_log_commit_cil+0x352/0x460 [ 270.386049] [] __xfs_trans_commit+0x10b/0x1f0 [ 270.387449] [] xfs_trans_commit+0xb/0x10 [ 270.388761] [] xfs_vn_update_time+0xdf/0x130 [ 270.390126] [] file_update_time+0xb8/0x110 [ 270.391484] [] xfs_file_aio_write_checks+0x16e/0x1c0 [ 270.392962] [] xfs_file_buffered_aio_write+0x79/0x1f0 [ 270.394728] [] ? _raw_spin_lock_irqsave+0x25/0x50 [ 270.396218] [] ? _raw_spin_unlock_irqrestore+0x1f/0x40 [ 270.397769] [] xfs_file_write_iter+0x74/0x110 [ 270.399194] [] __vfs_write+0xc7/0x100 [ 270.400507] [] vfs_write+0xa4/0x190 [ 270.401788] [] SyS_write+0x50/0xc0 [ 270.403048] [] ? do_fsync+0x38/0x60 [ 270.404324] [] entry_SYSCALL_64_fastpath+0x12/0x71 ---------- While OOM-killer deadlock shows OOM-killer messages and CPU usage remains 100%, this hang up shows no kernel messages and CPU usage remains 0% as if the system is completely idle. This patch shows progress of shrinking inactive list in order to assist warning about possible deadlock. So far I haven't succeeded to reproduce this bug after applying this patch; excuse me for output messages example is not available. Signed-off-by: Tetsuo Handa --- mm/vmscan.c | 45 +++++++++++++++++++++++++++++++-------------- 1 file changed, 31 insertions(+), 14 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index db5339d..0464537 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1476,20 +1476,12 @@ int isolate_lru_page(struct page *page) return ret; } -static int __too_many_isolated(struct zone *zone, int file, - struct scan_control *sc, int safe) +static inline unsigned long inactive_pages(struct zone *zone, int file, + struct scan_control *sc, int safe) { - unsigned long inactive, isolated; - - if (safe) { - inactive = zone_page_state_snapshot(zone, - NR_INACTIVE_ANON + 2 * file); - isolated = zone_page_state_snapshot(zone, - NR_ISOLATED_ANON + file); - } else { - inactive = zone_page_state(zone, NR_INACTIVE_ANON + 2 * file); - isolated = zone_page_state(zone, NR_ISOLATED_ANON + file); - } + unsigned long inactive = safe ? + zone_page_state_snapshot(zone, NR_INACTIVE_ANON + 2 * file) : + zone_page_state(zone, NR_INACTIVE_ANON + 2 * file); /* * GFP_NOIO/GFP_NOFS callers are allowed to isolate more pages, so they @@ -1498,8 +1490,21 @@ static int __too_many_isolated(struct zone *zone, int file, */ if ((sc->gfp_mask & GFP_IOFS) == GFP_IOFS) inactive >>= 3; + return inactive; +} - return isolated > inactive; +static inline unsigned long isolated_pages(struct zone *zone, int file, + int safe) +{ + return safe ? zone_page_state_snapshot(zone, NR_ISOLATED_ANON + file) : + zone_page_state(zone, NR_ISOLATED_ANON + file); +} + +static int __too_many_isolated(struct zone *zone, int file, + struct scan_control *sc, int safe) +{ + return isolated_pages(zone, file, safe) > + inactive_pages(zone, file, sc, safe); } /* @@ -1619,8 +1624,20 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, int file = is_file_lru(lru); struct zone *zone = lruvec_zone(lruvec); struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; + unsigned long start = jiffies; + unsigned long prev = start + 30 * HZ; while (unlikely(too_many_isolated(zone, file, sc))) { + unsigned long now = jiffies; + + if (time_after(now, prev)) { + pr_warn("vmscan: %s(%u) is waiting for %lu seconds at %s (mode:0x%x,isolated:%lu,inactive:%lu)\n", + current->comm, current->pid, (now - start) / HZ, + __func__, sc->gfp_mask, + isolated_pages(zone, file, 1), + inactive_pages(zone, file, sc, 1)); + prev = now + 30 * HZ; + } congestion_wait(BLK_RW_ASYNC, HZ/10); /* We are about to die and free our memory. Return now. */ -- 1.8.3.1 From penguin-kernel@I-love.SAKURA.ne.jp Mon Sep 21 06:13:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 5217E7F47 for ; Mon, 21 Sep 2015 06:13:22 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 0967B8F8035 for ; Mon, 21 Sep 2015 04:13:19 -0700 (PDT) X-ASG-Debug-ID: 1442833989-04bdf0462649750001-NocioJ Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by cuda.sgi.com with ESMTP id yyC4zrh9NGa3KxeU (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 21 Sep 2015 04:13:11 -0700 (PDT) X-Barracuda-Envelope-From: penguin-kernel@I-love.SAKURA.ne.jp X-Barracuda-Apparent-Source-IP: 202.181.97.72 Received: from fsav101.sakura.ne.jp (fsav101.sakura.ne.jp [27.133.134.228]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8LBD4XQ034191; Mon, 21 Sep 2015 20:13:04 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav101.sakura.ne.jp (F-Secure/fsigk_smtp/522/fsav101.sakura.ne.jp); Mon, 21 Sep 2015 20:13:04 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/522/fsav101.sakura.ne.jp) Received: from AQUA (softbank126074231104.bbtec.net [126.74.231.104]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8LBD4Zp034188; Mon, 21 Sep 2015 20:13:04 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) To: david@fromorbit.com Cc: xfs@oss.sgi.com, linux-mm@kvack.org Subject: Re: [PATCH] mm, vmscan: Warn about possible deadlock at shirink_inactive_list From: Tetsuo Handa X-ASG-Orig-Subj: Re: [PATCH] mm, vmscan: Warn about possible deadlock at shirink_inactive_list References: <1442833794-23117-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> In-Reply-To: <1442833794-23117-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> Message-Id: <201509212013.HGH18247.JOFOQMSVFLOFtH@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Mon, 21 Sep 2015 20:13:04 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Barracuda-Connect: www262.sakura.ne.jp[202.181.97.72] X-Barracuda-Start-Time: 1442833990 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 2.00 X-Barracuda-Spam-Status: No, SCORE=2.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC7_MV0607 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22748 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 2.00 BSF_SC7_MV0607 URI: Custom rule MV0607 (Oops. I forgot to append below description.) David, I got a backtrace where the system stalled forever with 0% CPU usage because all memory allocating tasks are sleeping at congestion_wait() in shrink_inactive_list() without triggering the OOM killer (uptime > 100 of http://I-love.SAKURA.ne.jp/tmp/serial-20150920.txt.xz ). Could you please have a look whether this is really a deadlock. (Even if it was not a deadlock, sleeping for 2 minutes at congestion_wait() is unusable...) Tetsuo Handa wrote: > This is a difficult-to-trigger silent hang up bug. > > The kswapd is allowed to bypass too_many_isolated() check in > shrink_inactive_list(). But the kswapd can be blocked by locks in > shrink_page_list() in shrink_inactive_list(). If the task which is > blocking the kswapd is trying to allocate memory with the locks held, > it forms memory reclaim deadlock. > > ---------- > [ 142.870301] kswapd0 D ffff88007fcd5b80 0 51 2 0x00000000 > [ 142.871941] ffff88007c98f660 0000000000000046 ffff88007cde4c80 ffff88007c990000 > [ 142.873772] ffff880035d08b40 ffff880035d08b58 ffff880079e4a828 ffff88007c98f890 > [ 142.875544] ffff88007c98f678 ffffffff81632c68 ffff88007cde4c80 ffff88007c98f6d8 > [ 142.877338] Call Trace: > [ 142.878220] [] schedule+0x38/0x90 > [ 142.879477] [] rwsem_down_read_failed+0xd3/0x140 > [ 142.880937] [] call_rwsem_down_read_failed+0x14/0x30 > [ 142.882595] [] ? down_read+0x12/0x20 > [ 142.883882] [] xfs_log_commit_cil+0x5b/0x460 > [ 142.885326] [] __xfs_trans_commit+0x10b/0x1f0 > [ 142.886756] [] xfs_trans_commit+0xb/0x10 > [ 142.888085] [] xfs_iomap_write_allocate+0x165/0x320 > [ 142.889657] [] xfs_map_blocks+0x15a/0x170 > [ 142.891002] [] xfs_vm_writepage+0x18b/0x5a0 > [ 142.892372] [] pageout.isra.42+0x18c/0x250 > [ 142.893813] [] shrink_page_list+0x650/0xa10 > [ 142.895182] [] shrink_inactive_list+0x1f2/0x560 > [ 142.896606] [] shrink_lruvec+0x59f/0x760 > [ 142.898037] [] shrink_zone+0xa6/0x2d0 > [ 142.899320] [] kswapd+0x4c2/0x8e0 > [ 142.900545] [] ? mem_cgroup_shrink_node_zone+0xe0/0xe0 > [ 142.902152] [] kthread+0xd3/0xf0 > [ 142.903381] [] ? kthread_create_on_node+0x1a0/0x1a0 > [ 142.904919] [] ret_from_fork+0x3f/0x70 > [ 142.906237] [] ? kthread_create_on_node+0x1a0/0x1a0 > (...snipped...) > [ 148.995189] a.out D ffffffff813360c7 0 7821 7788 0x00000080 > [ 148.996854] ffff88007c6b73d8 0000000000000086 ffff880078e7f2c0 ffff88007c6b8000 > [ 148.998583] ffff88007c6b7410 ffff88007fc8dfc0 00000000fffd94f9 0000000000000002 > [ 149.000560] ffff88007c6b73f0 ffffffff81632c68 ffff88007fc8dfc0 ffff88007c6b7470 > [ 149.002415] Call Trace: > [ 149.003285] [] schedule+0x38/0x90 > [ 149.004624] [] schedule_timeout+0x122/0x1c0 > [ 149.006003] [] ? preempt_count_add+0x43/0x90 > [ 149.007412] [] ? cascade+0x90/0x90 > [ 149.008704] [] io_schedule_timeout+0xa1/0x110 > [ 149.010109] [] congestion_wait+0x7d/0xd0 > [ 149.011536] [] ? wait_woken+0x80/0x80 > [ 149.012891] [] shrink_inactive_list+0x519/0x560 > [ 149.014327] [] ? check_preempt_wakeup+0x10e/0x1f0 > [ 149.015867] [] shrink_lruvec+0x59f/0x760 > [ 149.017340] [] ? mem_cgroup_iter+0xef/0x4e0 > [ 149.018742] [] shrink_zone+0xa6/0x2d0 > [ 149.020150] [] do_try_to_free_pages+0x164/0x420 > [ 149.021605] [] try_to_free_pages+0x94/0xc0 > [ 149.022968] [] __alloc_pages_nodemask+0x4fb/0x930 > [ 149.024476] [] alloc_pages_current+0x8c/0x100 > [ 149.025883] [] new_slab+0x458/0x4d0 > [ 149.027209] [] ___slab_alloc+0x49e/0x610 > [ 149.028580] [] ? kmem_alloc+0x74/0xe0 > [ 149.029864] [] ? update_curr+0x58/0xe0 > [ 149.031327] [] ? update_cfs_shares+0xad/0xf0 > [ 149.032808] [] ? dequeue_entity+0x1e9/0x800 > [ 149.034301] [] __slab_alloc.isra.67+0x53/0x6f > [ 149.035780] [] ? kmem_alloc+0x74/0xe0 > [ 149.037076] [] ? kmem_alloc+0x74/0xe0 > [ 149.038344] [] __kmalloc+0x14d/0x1a0 > [ 149.039677] [] kmem_alloc+0x74/0xe0 > [ 149.040940] [] xfs_log_commit_cil+0x352/0x460 > [ 149.042321] [] __xfs_trans_commit+0x10b/0x1f0 > [ 149.043733] [] xfs_trans_commit+0xb/0x10 > [ 149.045065] [] xfs_vn_update_time+0xdf/0x130 > [ 149.046430] [] file_update_time+0xb8/0x110 > [ 149.047833] [] xfs_file_aio_write_checks+0x16e/0x1c0 > [ 149.049386] [] xfs_file_buffered_aio_write+0x79/0x1f0 > [ 149.051031] [] ? _raw_spin_lock_irqsave+0x25/0x50 > [ 149.052581] [] ? _raw_spin_unlock_irqrestore+0x1f/0x40 > [ 149.054084] [] xfs_file_write_iter+0x74/0x110 > [ 149.055729] [] __vfs_write+0xc7/0x100 > [ 149.057023] [] vfs_write+0xa4/0x190 > [ 149.058330] [] SyS_write+0x50/0xc0 > [ 149.059553] [] ? do_fsync+0x38/0x60 > [ 149.060811] [] entry_SYSCALL_64_fastpath+0x12/0x71 > (...snipped...) > [ 264.199092] kswapd0 D ffff88007fcd5b80 0 51 2 0x00000000 > [ 264.200724] ffff88007c98f660 0000000000000046 ffff88007cde4c80 ffff88007c990000 > [ 264.202469] ffff880035d08b40 ffff880035d08b58 ffff880079e4a828 ffff88007c98f890 > [ 264.204233] ffff88007c98f678 ffffffff81632c68 ffff88007cde4c80 ffff88007c98f6d8 > [ 264.206173] Call Trace: > [ 264.207202] [] schedule+0x38/0x90 > [ 264.208536] [] rwsem_down_read_failed+0xd3/0x140 > [ 264.210044] [] call_rwsem_down_read_failed+0x14/0x30 > [ 264.211602] [] ? down_read+0x12/0x20 > [ 264.212929] [] xfs_log_commit_cil+0x5b/0x460 > [ 264.214369] [] __xfs_trans_commit+0x10b/0x1f0 > [ 264.215820] [] xfs_trans_commit+0xb/0x10 > [ 264.217193] [] xfs_iomap_write_allocate+0x165/0x320 > [ 264.218721] [] xfs_map_blocks+0x15a/0x170 > [ 264.220109] [] xfs_vm_writepage+0x18b/0x5a0 > [ 264.221586] [] pageout.isra.42+0x18c/0x250 > [ 264.222989] [] shrink_page_list+0x650/0xa10 > [ 264.224404] [] shrink_inactive_list+0x1f2/0x560 > [ 264.225876] [] shrink_lruvec+0x59f/0x760 > [ 264.227248] [] shrink_zone+0xa6/0x2d0 > [ 264.228573] [] kswapd+0x4c2/0x8e0 > [ 264.229840] [] ? mem_cgroup_shrink_node_zone+0xe0/0xe0 > [ 264.231407] [] kthread+0xd3/0xf0 > [ 264.232662] [] ? kthread_create_on_node+0x1a0/0x1a0 > [ 264.234185] [] ret_from_fork+0x3f/0x70 > [ 264.235527] [] ? kthread_create_on_node+0x1a0/0x1a0 > (...snipped...) > [ 270.339774] a.out D ffffffff813360c7 0 7821 7788 0x00000080 > [ 270.341391] ffff88007c6b73d8 0000000000000086 ffff880078e7f2c0 ffff88007c6b8000 > [ 270.343114] ffff88007c6b7410 ffff88007fc4dfc0 00000000ffff8b29 0000000000000002 > [ 270.344859] ffff88007c6b73f0 ffffffff81632c68 ffff88007fc4dfc0 ffff88007c6b7470 > [ 270.346670] Call Trace: > [ 270.347608] [] schedule+0x38/0x90 > [ 270.348929] [] schedule_timeout+0x122/0x1c0 > [ 270.350354] [] ? preempt_count_add+0x43/0x90 > [ 270.351790] [] ? cascade+0x90/0x90 > [ 270.353106] [] io_schedule_timeout+0xa1/0x110 > [ 270.354558] [] congestion_wait+0x7d/0xd0 > [ 270.355958] [] ? wait_woken+0x80/0x80 > [ 270.357298] [] shrink_inactive_list+0x519/0x560 > [ 270.358779] [] ? check_preempt_wakeup+0x10e/0x1f0 > [ 270.360307] [] shrink_lruvec+0x59f/0x760 > [ 270.361687] [] ? mem_cgroup_iter+0xef/0x4e0 > [ 270.363147] [] shrink_zone+0xa6/0x2d0 > [ 270.364462] [] do_try_to_free_pages+0x164/0x420 > [ 270.365898] [] try_to_free_pages+0x94/0xc0 > [ 270.367261] [] __alloc_pages_nodemask+0x4fb/0x930 > [ 270.368744] [] alloc_pages_current+0x8c/0x100 > [ 270.370151] [] new_slab+0x458/0x4d0 > [ 270.371420] [] ___slab_alloc+0x49e/0x610 > [ 270.372769] [] ? kmem_alloc+0x74/0xe0 > [ 270.374053] [] ? update_curr+0x58/0xe0 > [ 270.375351] [] ? update_cfs_shares+0xad/0xf0 > [ 270.376748] [] ? dequeue_entity+0x1e9/0x800 > [ 270.378200] [] __slab_alloc.isra.67+0x53/0x6f > [ 270.379604] [] ? kmem_alloc+0x74/0xe0 > [ 270.380879] [] ? kmem_alloc+0x74/0xe0 > [ 270.382148] [] __kmalloc+0x14d/0x1a0 > [ 270.383424] [] kmem_alloc+0x74/0xe0 > [ 270.384668] [] xfs_log_commit_cil+0x352/0x460 > [ 270.386049] [] __xfs_trans_commit+0x10b/0x1f0 > [ 270.387449] [] xfs_trans_commit+0xb/0x10 > [ 270.388761] [] xfs_vn_update_time+0xdf/0x130 > [ 270.390126] [] file_update_time+0xb8/0x110 > [ 270.391484] [] xfs_file_aio_write_checks+0x16e/0x1c0 > [ 270.392962] [] xfs_file_buffered_aio_write+0x79/0x1f0 > [ 270.394728] [] ? _raw_spin_lock_irqsave+0x25/0x50 > [ 270.396218] [] ? _raw_spin_unlock_irqrestore+0x1f/0x40 > [ 270.397769] [] xfs_file_write_iter+0x74/0x110 > [ 270.399194] [] __vfs_write+0xc7/0x100 > [ 270.400507] [] vfs_write+0xa4/0x190 > [ 270.401788] [] SyS_write+0x50/0xc0 > [ 270.403048] [] ? do_fsync+0x38/0x60 > [ 270.404324] [] entry_SYSCALL_64_fastpath+0x12/0x71 > ---------- > > While OOM-killer deadlock shows OOM-killer messages and CPU usage remains > 100%, this hang up shows no kernel messages and CPU usage remains 0% as if > the system is completely idle. > > This patch shows progress of shrinking inactive list in order to assist > warning about possible deadlock. So far I haven't succeeded to reproduce > this bug after applying this patch; excuse me for output messages example > is not available. > > Signed-off-by: Tetsuo Handa > --- > mm/vmscan.c | 45 +++++++++++++++++++++++++++++++-------------- > 1 file changed, 31 insertions(+), 14 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index db5339d..0464537 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1476,20 +1476,12 @@ int isolate_lru_page(struct page *page) > return ret; > } > > -static int __too_many_isolated(struct zone *zone, int file, > - struct scan_control *sc, int safe) > +static inline unsigned long inactive_pages(struct zone *zone, int file, > + struct scan_control *sc, int safe) > { > - unsigned long inactive, isolated; > - > - if (safe) { > - inactive = zone_page_state_snapshot(zone, > - NR_INACTIVE_ANON + 2 * file); > - isolated = zone_page_state_snapshot(zone, > - NR_ISOLATED_ANON + file); > - } else { > - inactive = zone_page_state(zone, NR_INACTIVE_ANON + 2 * file); > - isolated = zone_page_state(zone, NR_ISOLATED_ANON + file); > - } > + unsigned long inactive = safe ? > + zone_page_state_snapshot(zone, NR_INACTIVE_ANON + 2 * file) : > + zone_page_state(zone, NR_INACTIVE_ANON + 2 * file); > > /* > * GFP_NOIO/GFP_NOFS callers are allowed to isolate more pages, so they > @@ -1498,8 +1490,21 @@ static int __too_many_isolated(struct zone *zone, int file, > */ > if ((sc->gfp_mask & GFP_IOFS) == GFP_IOFS) > inactive >>= 3; > + return inactive; > +} > > - return isolated > inactive; > +static inline unsigned long isolated_pages(struct zone *zone, int file, > + int safe) > +{ > + return safe ? zone_page_state_snapshot(zone, NR_ISOLATED_ANON + file) : > + zone_page_state(zone, NR_ISOLATED_ANON + file); > +} > + > +static int __too_many_isolated(struct zone *zone, int file, > + struct scan_control *sc, int safe) > +{ > + return isolated_pages(zone, file, safe) > > + inactive_pages(zone, file, sc, safe); > } > > /* > @@ -1619,8 +1624,20 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, > int file = is_file_lru(lru); > struct zone *zone = lruvec_zone(lruvec); > struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat; > + unsigned long start = jiffies; > + unsigned long prev = start + 30 * HZ; > > while (unlikely(too_many_isolated(zone, file, sc))) { > + unsigned long now = jiffies; > + > + if (time_after(now, prev)) { > + pr_warn("vmscan: %s(%u) is waiting for %lu seconds at %s (mode:0x%x,isolated:%lu,inactive:%lu)\n", > + current->comm, current->pid, (now - start) / HZ, > + __func__, sc->gfp_mask, > + isolated_pages(zone, file, 1), > + inactive_pages(zone, file, sc, 1)); > + prev = now + 30 * HZ; > + } > congestion_wait(BLK_RW_ASYNC, HZ/10); > > /* We are about to die and free our memory. Return now. */ > -- > 1.8.3.1 > > From angelo.dureghello@nomovok.com Mon Sep 21 06:13:47 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id EE4FB7F47 for ; Mon, 21 Sep 2015 06:13:47 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id B028E304032 for ; Mon, 21 Sep 2015 04:13:47 -0700 (PDT) X-ASG-Debug-ID: 1442834023-04bdf04627497c0001-NocioJ Received: from mail.nomovok.com (mail.nomovok.com [83.150.122.238]) by cuda.sgi.com with ESMTP id GPrU9piXbrh5me6Z (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Sep 2015 04:13:44 -0700 (PDT) X-Barracuda-Envelope-From: angelo.dureghello@nomovok.com X-Barracuda-Apparent-Source-IP: 83.150.122.238 Received: from [192.168.0.111] (host22-235-dynamic.248-95-r.retail.telecomitalia.it [95.248.235.22]) by mail.nomovok.com (Postfix) with ESMTPSA id 9D838AE031 for ; Mon, 21 Sep 2015 14:13:42 +0300 (EEST) Message-ID: <55FFE665.7040004@nomovok.com> Date: Mon, 21 Sep 2015 13:13:41 +0200 From: Angelo Dureghello User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: xfstests, bad generic tests 009 and 308 References: <55FC3E0E.9060506@nomovok.com> <20150918224412.GE26895@dastard> X-ASG-Orig-Subj: Re: xfstests, bad generic tests 009 and 308 In-Reply-To: <20150918224412.GE26895@dastard> Content-Type: multipart/mixed; boundary="------------020908000407020700070704" X-Barracuda-Connect: mail.nomovok.com[83.150.122.238] X-Barracuda-Start-Time: 1442834024 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22748 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words This is a multi-part message in MIME format. --------------020908000407020700070704 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, many thanks for the support. Sorry for the double mail, after first registering mails was not accepted, so i re-registered with a company mail. On 19/09/2015 00:44, Dave Chinner wrote: > On Fri, Sep 18, 2015 at 06:38:38PM +0200, Angelo Dureghello wrote: >> Hi all, >> >> working on arm (32bit arch), kernel 4.1.6. > Is this a new platform? > > Also, we need to know what compiler you are using, because we know > that certain versions of gcc miscompile XFS kernel code on arm > (4.6, 4.7 and certain versions of 4.8 are suspect) due to a > combination of compiler mis-optimisations and kernel bugs in the > arm 64 bit division asm implementation. > > As such, it would be worthwhile trying gcc-4.9 and a 4.3-rc1 kernel > to see if the problems still occur. I am using actually gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf >> Looking to find the reason of some bad results on xfstests, >> >> -tests/generic/009 >> ------------------ >> i get several "all holes" messages >> >> generic/009 [ 842.949643] run fstests generic/009 at 2015-09-18 >> 15:29:36 >> - output mismatch (see >> /home/angelo/xfstests/results//generic/009.out.bad) >> --- tests/generic/009.out 2015-09-17 10:54:06.689071257 +0000 >> +++ /home/angelo/xfstests/results//generic/009.out.bad >> 2015-09-18 15:29:41.412784177 +0000 >> @@ -1,79 +1,45 @@ >> QA output created by 009 >> 1. into a hole >> -0: [0..7]: hole >> -1: [8..23]: unwritten >> -2: [24..39]: hole >> +0: [0..39]: hole >> daa100df6e6711906b61c9ab5aa16032 >> >> also some other tests are giving the same bad notices. > Can you attach the entire > /home/angelo/xfstests/results//generic/009.out.bad file? I'm not > sure which of the tests this output comes from, so I need to > confirm which specific operations are resulting in errors. Sure, i completed the whole generic + shared + xfs tests. In total i have 38 errors. And trying now one by one to understand the reason. I attached the 009 output. >> -tests/generic/308 >> ------------------ >> >> I have now: CONFIG_LBDAF=y >> >> In my target device this test creates a 16 Terabytes file 308.tempfile >> >> -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 >> >> While "df" is not complaining about: >> >> /dev/mmcblk0p5 8378368 45252 8333116 1% /media/p5 >> >> and next rm -f on it hands the cpu to 95%, forever. >> >> This issue seems known from a long time, as it has been discussed in >> the thread: >> >> http://oss.sgi.com/archives/xfs/2013-04/msg00273.html >> >> I was wondering if there was any special reason why the Jeff patch has >> never been finally applied. > MAX_LFS_FILESIZE on 32 bits is 8TB, whereas xfs supports 16TB file > size on 32 bit systems. The specific issue this test fixed was > committed in commit 8695d27 ("xfs: fix infinite loop at > xfs_vm_writepage on 32bit system") > > http://oss.sgi.com/archives/xfs/2014-05/msg00447.html > > And, as you may notice now, generic/308 is the test case for the > exact problem the above commit fixed. I have recent git version of xfstests, but generic/308 shows #! /bin/bash # FS QA Test No. 308 # # Regression test for commit: # f17722f ext4: Fix max file size and logical block counting of extent format file > Can you find out exactly where the CPU is looping? sysrq-l will > help, as will running 'perf top -U -g' to show you the hot code > paths, and so on. Strangely, the patch http://oss.sgi.com/archives/xfs/2014-05/msg00447.html is already included in the xfs that comes with this 4.1.6 kernel, while only applying previous http://oss.sgi.com/archives/xfs/2013-04/msg00273.html patch from Jeff fix the issue and test 308 get passed. I have a 16MB partition, and wondering why xfs allows from test 308 to create a 16TB file. -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 When at 308 test exit, rm is invoked, system get blocked in infinite loop. root 5445 0.7 0.2 3760 3180 ttyS0 S+ 10:53 0:00 /bin/bash /home/angelo/xfstests/tests/generic/308 root 5674 100 0.0 1388 848 ttyS0 R+ 10:53 0:27 rm -f /media/p5/testfile.308 Can't install actually perf-tools for some debian repos issue, but let me know, i will enable sysrq if needed. Best regards Angelo > > Cheers, > > Dave. -- Best regards, Angelo Dureghello --------------020908000407020700070704 Content-Type: text/plain; charset=UTF-8; name="009.out.bad" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="009.out.bad" QA output created by 009 1. into a hole 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 2. into allocated space cc58a7417c2d7763adc45b6fcd3fa024 3. into unwritten space daa100df6e6711906b61c9ab5aa16032 4. hole -> data 0: [0..39]: hole cc63069677939f69a6e8f68cae6a6dac 5. hole -> unwritten 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 6. data -> hole 0: [24..39]: hole 1b3779878366498b28c702ef88c4a773 7. data -> unwritten 0: [32..39]: hole 1b3779878366498b28c702ef88c4a773 8. unwritten -> hole 0: [24..39]: hole daa100df6e6711906b61c9ab5aa16032 9. unwritten -> data 0: [32..39]: hole cc63069677939f69a6e8f68cae6a6dac 10. hole -> data -> hole 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 11. data -> hole -> data f6aeca13ec49e5b266cd1c913cd726e3 12. unwritten -> data -> unwritten daa100df6e6711906b61c9ab5aa16032 13. data -> unwritten -> data f6aeca13ec49e5b266cd1c913cd726e3 14. data -> hole @ EOF e1f024eedd27ea6b1c3e9b841c850404 15. data -> hole @ 0 eecb7aa303d121835de05028751d301c 16. data -> cache cold ->hole eecb7aa303d121835de05028751d301c 17. data -> hole in single block file 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0000200 0000 0000 0000 0000 0000 0000 0000 0000 * 0000400 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 1. into a hole 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 2. into allocated space cc58a7417c2d7763adc45b6fcd3fa024 3. into unwritten space daa100df6e6711906b61c9ab5aa16032 4. hole -> data 0: [0..39]: hole cc63069677939f69a6e8f68cae6a6dac 5. hole -> unwritten 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 6. data -> hole 0: [24..39]: hole 1b3779878366498b28c702ef88c4a773 7. data -> unwritten 0: [32..39]: hole 1b3779878366498b28c702ef88c4a773 8. unwritten -> hole 0: [24..39]: hole daa100df6e6711906b61c9ab5aa16032 9. unwritten -> data 0: [32..39]: hole cc63069677939f69a6e8f68cae6a6dac 10. hole -> data -> hole 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 11. data -> hole -> data f6aeca13ec49e5b266cd1c913cd726e3 12. unwritten -> data -> unwritten daa100df6e6711906b61c9ab5aa16032 13. data -> unwritten -> data f6aeca13ec49e5b266cd1c913cd726e3 14. data -> hole @ EOF e1f024eedd27ea6b1c3e9b841c850404 15. data -> hole @ 0 eecb7aa303d121835de05028751d301c 16. data -> cache cold ->hole eecb7aa303d121835de05028751d301c 17. data -> hole in single block file 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0000200 0000 0000 0000 0000 0000 0000 0000 0000 * 0000400 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 1. into a hole 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 2. into allocated space cc58a7417c2d7763adc45b6fcd3fa024 3. into unwritten space cc58a7417c2d7763adc45b6fcd3fa024 4. hole -> data cc58a7417c2d7763adc45b6fcd3fa024 5. hole -> unwritten cc58a7417c2d7763adc45b6fcd3fa024 6. data -> hole cc58a7417c2d7763adc45b6fcd3fa024 7. data -> unwritten cc58a7417c2d7763adc45b6fcd3fa024 8. unwritten -> hole cc58a7417c2d7763adc45b6fcd3fa024 9. unwritten -> data cc58a7417c2d7763adc45b6fcd3fa024 10. hole -> data -> hole f6aeca13ec49e5b266cd1c913cd726e3 11. data -> hole -> data f6aeca13ec49e5b266cd1c913cd726e3 12. unwritten -> data -> unwritten f6aeca13ec49e5b266cd1c913cd726e3 13. data -> unwritten -> data f6aeca13ec49e5b266cd1c913cd726e3 14. data -> hole @ EOF e1f024eedd27ea6b1c3e9b841c850404 15. data -> hole @ 0 eecb7aa303d121835de05028751d301c 16. data -> cache cold ->hole eecb7aa303d121835de05028751d301c 17. data -> hole in single block file 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0000200 0000 0000 0000 0000 0000 0000 0000 0000 * 0000400 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 1. into a hole 0: [0..39]: hole daa100df6e6711906b61c9ab5aa16032 2. into allocated space cc58a7417c2d7763adc45b6fcd3fa024 3. into unwritten space cc58a7417c2d7763adc45b6fcd3fa024 4. hole -> data cc58a7417c2d7763adc45b6fcd3fa024 5. hole -> unwritten cc58a7417c2d7763adc45b6fcd3fa024 6. data -> hole cc58a7417c2d7763adc45b6fcd3fa024 7. data -> unwritten cc58a7417c2d7763adc45b6fcd3fa024 8. unwritten -> hole cc58a7417c2d7763adc45b6fcd3fa024 9. unwritten -> data cc58a7417c2d7763adc45b6fcd3fa024 10. hole -> data -> hole f6aeca13ec49e5b266cd1c913cd726e3 11. data -> hole -> data f6aeca13ec49e5b266cd1c913cd726e3 12. unwritten -> data -> unwritten f6aeca13ec49e5b266cd1c913cd726e3 13. data -> unwritten -> data f6aeca13ec49e5b266cd1c913cd726e3 14. data -> hole @ EOF e1f024eedd27ea6b1c3e9b841c850404 15. data -> hole @ 0 eecb7aa303d121835de05028751d301c 16. data -> cache cold ->hole eecb7aa303d121835de05028751d301c 17. data -> hole in single block file 0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * 0000200 0000 0000 0000 0000 0000 0000 0000 0000 * 0000400 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd * --------------020908000407020700070704-- From angelo.dureghello@nomovok.com Mon Sep 21 06:18:07 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 1BCD97F47 for ; Mon, 21 Sep 2015 06:18:07 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id D35E18F8035 for ; Mon, 21 Sep 2015 04:18:06 -0700 (PDT) X-ASG-Debug-ID: 1442834283-04bdf0462749b10001-NocioJ Received: from mail.nomovok.com (mail.nomovok.com [83.150.122.238]) by cuda.sgi.com with ESMTP id DIblsqjWoYgxXPZU (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Sep 2015 04:18:04 -0700 (PDT) X-Barracuda-Envelope-From: angelo.dureghello@nomovok.com X-Barracuda-Apparent-Source-IP: 83.150.122.238 Received: from [192.168.0.111] (host22-235-dynamic.248-95-r.retail.telecomitalia.it [95.248.235.22]) by mail.nomovok.com (Postfix) with ESMTPSA id C4664AE031 for ; Mon, 21 Sep 2015 14:18:02 +0300 (EEST) Message-ID: <55FFE769.7090802@nomovok.com> Date: Mon, 21 Sep 2015 13:18:01 +0200 From: Angelo Dureghello User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: xfstests, bad generic tests 009 and 308 References: <55FC3E0E.9060506@nomovok.com> <20150918224412.GE26895@dastard> <55FFE665.7040004@nomovok.com> X-ASG-Orig-Subj: Re: xfstests, bad generic tests 009 and 308 In-Reply-To: <55FFE665.7040004@nomovok.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail.nomovok.com[83.150.122.238] X-Barracuda-Start-Time: 1442834284 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22748 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words Sry, in my previous mail please s/16M/16G. Was a typo. I am using an SD card with test partitions 8G and 16G. Best regards Angelo On 21/09/2015 13:13, Angelo Dureghello wrote: > Hi Dave, > > many thanks for the support. Sorry for the double mail, after > first registering mails was not accepted, so i re-registered > with a company mail. > > > On 19/09/2015 00:44, Dave Chinner wrote: >> On Fri, Sep 18, 2015 at 06:38:38PM +0200, Angelo Dureghello wrote: >>> Hi all, >>> >>> working on arm (32bit arch), kernel 4.1.6. >> Is this a new platform? >> >> Also, we need to know what compiler you are using, because we know >> that certain versions of gcc miscompile XFS kernel code on arm >> (4.6, 4.7 and certain versions of 4.8 are suspect) due to a >> combination of compiler mis-optimisations and kernel bugs in the >> arm 64 bit division asm implementation. >> >> As such, it would be worthwhile trying gcc-4.9 and a 4.3-rc1 kernel >> to see if the problems still occur. > > I am using actually gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf > >>> Looking to find the reason of some bad results on xfstests, >>> >>> -tests/generic/009 >>> ------------------ >>> i get several "all holes" messages >>> >>> generic/009 [ 842.949643] run fstests generic/009 at 2015-09-18 >>> 15:29:36 >>> - output mismatch (see >>> /home/angelo/xfstests/results//generic/009.out.bad) >>> --- tests/generic/009.out 2015-09-17 10:54:06.689071257 +0000 >>> +++ /home/angelo/xfstests/results//generic/009.out.bad >>> 2015-09-18 15:29:41.412784177 +0000 >>> @@ -1,79 +1,45 @@ >>> QA output created by 009 >>> 1. into a hole >>> -0: [0..7]: hole >>> -1: [8..23]: unwritten >>> -2: [24..39]: hole >>> +0: [0..39]: hole >>> daa100df6e6711906b61c9ab5aa16032 >>> >>> also some other tests are giving the same bad notices. >> Can you attach the entire >> /home/angelo/xfstests/results//generic/009.out.bad file? I'm not >> sure which of the tests this output comes from, so I need to >> confirm which specific operations are resulting in errors. > Sure, i completed the whole generic + shared + xfs tests. > In total i have 38 errors. And trying now one by one to understand the > reason. > I attached the 009 output. > >>> -tests/generic/308 >>> ------------------ >>> >>> I have now: CONFIG_LBDAF=y >>> >>> In my target device this test creates a 16 Terabytes file 308.tempfile >>> >>> -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 >>> >>> While "df" is not complaining about: >>> >>> /dev/mmcblk0p5 8378368 45252 8333116 1% /media/p5 >>> >>> and next rm -f on it hands the cpu to 95%, forever. >>> >>> This issue seems known from a long time, as it has been discussed in >>> the thread: >>> >>> http://oss.sgi.com/archives/xfs/2013-04/msg00273.html >>> >>> I was wondering if there was any special reason why the Jeff patch has >>> never been finally applied. >> MAX_LFS_FILESIZE on 32 bits is 8TB, whereas xfs supports 16TB file >> size on 32 bit systems. The specific issue this test fixed was >> committed in commit 8695d27 ("xfs: fix infinite loop at >> xfs_vm_writepage on 32bit system") >> >> http://oss.sgi.com/archives/xfs/2014-05/msg00447.html >> >> And, as you may notice now, generic/308 is the test case for the >> exact problem the above commit fixed. > > I have recent git version of xfstests, but generic/308 shows > > #! /bin/bash > # FS QA Test No. 308 > # > # Regression test for commit: > # f17722f ext4: Fix max file size and logical block counting of extent > format file > >> Can you find out exactly where the CPU is looping? sysrq-l will >> help, as will running 'perf top -U -g' to show you the hot code >> paths, and so on. > > Strangely, the patch > http://oss.sgi.com/archives/xfs/2014-05/msg00447.html is already included > in the xfs that comes with this 4.1.6 kernel, while only applying > previous > > http://oss.sgi.com/archives/xfs/2013-04/msg00273.html patch from Jeff > fix the issue and > test 308 get passed. > > > I have a 16MB partition, and wondering why xfs allows from test 308 to > create a 16TB file. > > -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 > > > When at 308 test exit, rm is invoked, system get blocked in infinite > loop. > > root 5445 0.7 0.2 3760 3180 ttyS0 S+ 10:53 0:00 > /bin/bash /home/angelo/xfstests/tests/generic/308 > root 5674 100 0.0 1388 848 ttyS0 R+ 10:53 0:27 rm -f > /media/p5/testfile.308 > > Can't install actually perf-tools for some debian repos issue, but let > me know, i will enable sysrq > if needed. > > Best regards > Angelo > > >> >> Cheers, >> >> Dave. > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- Best regards, Angelo Dureghello From rjohnston@sgi.com Mon Sep 21 08:43:13 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 455687F37 for ; Mon, 21 Sep 2015 08:43:13 -0500 (CDT) Received: from xmail.sgi.com (pv-excas3-dc21.corp.sgi.com [137.38.106.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 970B6AC005; Mon, 21 Sep 2015 06:43:09 -0700 (PDT) Received: from [128.162.233.55] (128.162.233.55) by xmail.sgi.com (137.38.106.6) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 21 Sep 2015 08:43:08 -0500 Subject: Re: [PATCH V3] xfsdump: prevent segfault in cb_add_inogrp To: Dave Chinner References: <20150924193241.975348815@gulag1.americas.sgi.com> <77EDF3BA.60409@sgi.com> <20150826225601.GG3902@dastard> <55DE4492.90105@sgi.com> CC: From: Rich Johnston Message-ID: <5600094B.3090206@sgi.com> Date: Mon, 21 Sep 2015 08:42:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55DE4492.90105@sgi.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [128.162.233.55] On 08/26/2015 05:58 PM, Rich Johnston wrote: > On 08/26/2015 05:56 PM, Dave Chinner wrote: ... >> Can't believe I missed this first two times time through - the patch >> is missing your signed-off-by. Just reply with it, and I'll fix it >> up on commit. :) > Dooh my bad > > Signed-off-by: Rich Johnston >> >> Thanks, Rich! >> >> Cheers, >> >> Dave. >> > Hey Dave, Just curious when this patch are going to be committed? Thanks --Rich These are also ready to go. [PATCH V4] xfsrestore: fix fs uuid order check for incremental restores http://oss.sgi.com/archives/xfs/2015-09/msg00185.html [PATCH V2] xfsrestore: fix 2GB directory dump limitation for multi-stream http://oss.sgi.com/archives/xfs/2015-09/msg00033.html From tdm@sgi.com Mon Sep 21 10:13:58 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id A1C687F37 for ; Mon, 21 Sep 2015 10:13:58 -0500 (CDT) Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by relay2.corp.sgi.com (Postfix) with ESMTP id 5D205304067; Mon, 21 Sep 2015 08:13:55 -0700 (PDT) Received: from [128.162.232.11] (porter.americas.sgi.com [128.162.232.11]) by estes.americas.sgi.com (Postfix) with ESMTP id 059FC7003736; Mon, 21 Sep 2015 10:13:55 -0500 (CDT) Message-ID: <56001EB2.2000109@sgi.com> Date: Mon, 21 Sep 2015 10:13:54 -0500 From: Troy McCorkell User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Cc: Dave Chinner , carlos.e.r@opensuse.org Subject: Re: What's up with this list? References: <541AFB60.5030403@sgi.com> <55FAF053.3020405@sgi.com> <55FB06E8.1020203@opensuse.org> <55FC3569.5020801@sgi.com> <20150918225624.GF26895@dastard> In-Reply-To: <20150918225624.GF26895@dastard> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/18/2015 05:56 PM, Dave Chinner wrote: > On Fri, Sep 18, 2015 at 11:01:45AM -0500, Troy McCorkell wrote: > >> xfs@oss.sgi.com is an open list and does not require people to be members >> of the list to post to it. The spam filters applied to >> xfs@oss.sgi.com are >> as aggressive as they can be and still allow for an open list. >> >> Next option would be to add a moderator to the list. Adding a moderator >> would interfere with non-list members posting to the list. >> > Moderation is not an option because of this interference and the > burden it puts on the moderator to respond in a timely fashion. > > If the spam rejection does not improve our next option is to move to > the linux-xfs@vger.kernel.org list - the vger infrastructure is not > perfect, but it does have better spam rejection than the current > filtering on this list. This may be the best long-term solution to > the problem, but it does involve short term pain for everyone. > > Cheers, > > Dave. > I understand moderation is not an option. Just reviewing the options. oss.sgi.com is not a stand alone system when it comes to email. All emails received by oss.sgi.com first pass through the SGI corporate spam filters. Several of the old defunct mailing lists on oss.sgi.com have been configured as spam-traps. Additional spam filters have been added specifically for oss.sgi.com. And yet spam continues to hit the list. I'll continue the conversation with the SGI IT group. Thanks, Troy From noreply@release.debian.org Mon Sep 21 11:39:31 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 559D67F37 for ; Mon, 21 Sep 2015 11:39:31 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id C3BCD304062 for ; Mon, 21 Sep 2015 09:39:28 -0700 (PDT) X-ASG-Debug-ID: 1442853562-04cb6c6b064e990001-NocioJ Received: from picconi.debian.org (picconi.debian.org [5.153.231.3]) by cuda.sgi.com with ESMTP id 02qESGHgciztrqCy (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 21 Sep 2015 09:39:23 -0700 (PDT) X-Barracuda-Envelope-From: noreply@release.debian.org X-Barracuda-Apparent-Source-IP: 5.153.231.3 Received: from mailly.debian.org ([2001:41b8:202:deb:6564:a62:52c3:4b72]) from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=mailly.debian.org,EMAIL=hostmaster@mailly.debian.org (verified) by picconi.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1Ze47e-0005BW-9B for xfsprogs@packages.debian.org; Mon, 21 Sep 2015 16:39:22 +0000 Received: from franck.debian.org ([138.16.160.12]) from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=franck.debian.org,EMAIL=hostmaster@franck.debian.org (verified) by mailly.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1Ze47d-00039n-94; Mon, 21 Sep 2015 16:39:21 +0000 Received: from release by franck.debian.org with local (Exim 4.84) (envelope-from ) id 1Ze47c-0002z2-13; Mon, 21 Sep 2015 16:39:20 +0000 From: Debian testing watch Precedence: bulk X-Trille: 0.120315.1711 Subject: xfsprogs 4.2.0 MIGRATED to testing X-Testing-Watch-Package: xfsprogs X-ASG-Orig-Subj: xfsprogs 4.2.0 MIGRATED to testing X-Testing-Watch-Version: 4.2.0 To: xfsprogs@packages.debian.org Message-Id: Date: Mon, 21 Sep 2015 16:39:20 +0000 Delivered-To: xfsprogs@packages.debian.org X-Barracuda-Connect: picconi.debian.org[5.153.231.3] X-Barracuda-Start-Time: 1442853563 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22754 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header FYI: The status of the xfsprogs source package in Debian's testing distribution has changed. Previous version: 3.2.4-1 Current version: 4.2.0 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. From mel@ohmu.fi Mon Sep 21 12:04:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 329A07F37 for ; Mon, 21 Sep 2015 12:04:43 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 25517304051 for ; Mon, 21 Sep 2015 10:04:39 -0700 (PDT) X-ASG-Debug-ID: 1442855076-04cbb033b05bd00001-NocioJ Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by cuda.sgi.com with ESMTP id LiACmgWHV76H9r3d (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Sep 2015 10:04:37 -0700 (PDT) X-Barracuda-Envelope-From: mel@ohmu.fi X-Barracuda-Apparent-Source-IP: 62.142.5.117 Received: from localhost.localdomain (a88-115-163-75.elisa-laajakaista.fi [88.115.163.75]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id D7193400A; Mon, 21 Sep 2015 20:04:35 +0300 (EEST) From: Mika Eloranta To: xfs@oss.sgi.com Cc: Mika Eloranta Subject: [PATCH] mkfs.xfs: add [-U uuid] option Date: Mon, 21 Sep 2015 20:04:20 +0300 X-ASG-Orig-Subj: [PATCH] mkfs.xfs: add [-U uuid] option Message-Id: <1442855060-38259-1-git-send-email-mel@ohmu.fi> X-Mailer: git-send-email 2.3.5 X-Barracuda-Connect: emh07.mail.saunalahti.fi[62.142.5.117] X-Barracuda-Start-Time: 1442855077 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_RULE_7580D X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22756 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.75 BSF_RULE_7580D Custom Rule 7580D The UUID can now be optionally specified during filesystem creation. --- man/man8/mkfs.xfs.8 | 7 +++++++ mkfs/xfs_mkfs.c | 12 ++++++++++-- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/man/man8/mkfs.xfs.8 b/man/man8/mkfs.xfs.8 index 6260e0c..ab48dd7 100644 --- a/man/man8/mkfs.xfs.8 +++ b/man/man8/mkfs.xfs.8 @@ -38,6 +38,9 @@ mkfs.xfs \- construct an XFS filesystem .B \-L .I label ] [ +.B \-U +.I uuid +] [ .B \-N ] [ .B \-K @@ -816,6 +819,10 @@ will not proceed with creating the filesystem. Refer to the .BR mount "(8) and " xfs_admin (8) manual entries for additional information. .TP +.BI \-U " uuid" +Create the filesystem with the specified +.IR UUID . +.TP .B \-N Causes the file system parameters to be printed out without really creating the file system. diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c index d993fc0..9fc5c67 100644 --- a/mkfs/xfs_mkfs.c +++ b/mkfs/xfs_mkfs.c @@ -948,6 +948,7 @@ main( bool finobtflag; int spinodes; + platform_uuid_clear(&uuid); progname = basename(argv[0]); setlocale(LC_ALL, ""); bindtextdomain(PACKAGE, LOCALEDIR); @@ -990,7 +991,7 @@ main( xi.isdirect = LIBXFS_DIRECT; xi.isreadonly = LIBXFS_EXCLUSIVELY; - while ((c = getopt(argc, argv, "b:d:i:l:L:m:n:KNp:qr:s:CfV")) != EOF) { + while ((c = getopt(argc, argv, "b:d:i:l:L:U:m:n:KNp:qr:s:CfV")) != EOF) { switch (c) { case 'C': case 'f': @@ -1465,6 +1466,10 @@ main( illegal(optarg, "L"); label = optarg; break; + case 'U': + if (platform_uuid_parse(optarg, &uuid)) + illegal(optarg, "U"); + break; case 'm': p = optarg; while (*p != '\0') { @@ -2550,7 +2555,9 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"), sbp->sb_dblocks = dblocks; sbp->sb_rblocks = rtblocks; sbp->sb_rextents = rtextents; - platform_uuid_generate(&uuid); + if (platform_uuid_is_null(&uuid)) { + platform_uuid_generate(&uuid); + } platform_uuid_copy(&sbp->sb_uuid, &uuid); /* Only in memory; libxfs expects this as if read from disk */ platform_uuid_copy(&sbp->sb_meta_uuid, &uuid); @@ -3175,6 +3182,7 @@ usage( void ) sunit=value|su=num,sectlog=n|sectsize=num,\n\ lazy-count=0|1]\n\ /* label */ [-L label (maximum 12 characters)]\n\ +/* uuid */ [-U uuid]\n\ /* naming */ [-n log=n|size=num,version=2|ci,ftype=0|1]\n\ /* no-op info only */ [-N]\n\ /* prototype file */ [-p fname]\n\ -- 2.3.5 From robin.listas@gmail.com Mon Sep 21 12:36:27 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 07C967F37 for ; Mon, 21 Sep 2015 12:36:27 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id CBB2F304067 for ; Mon, 21 Sep 2015 10:36:26 -0700 (PDT) X-ASG-Debug-ID: 1442856981-04bdf0462257170001-NocioJ Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by cuda.sgi.com with ESMTP id pLLaBtRsn88b6x1P (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 21 Sep 2015 10:36:22 -0700 (PDT) X-Barracuda-Envelope-From: robin.listas@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.212.170 Received: by wicfx3 with SMTP id fx3so122254416wic.0 for ; Mon, 21 Sep 2015 10:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type:content-id; bh=prX3dRtuNuT5J3UZ2oknWe4oKOuo8F2j0pAQ++Dknq4=; b=pOxGCjZ8ov0PSkO6WQ/Ax3FA91FmE9lZJbk2FQTp/7OsAgzRD8AUDX22Zwh2Pjv77d o1FzL52sbN+GYsgXgVzF/8wUeZD7zXlCY9GPZOftpKc6oUyl9xSBA7pmvS/UKNPp1DG6 p8XD2V1p8TFcHgl/Q0+Wnv3fv71mM/rQ2OTl1/Js3K1TEkAQ+PTHt1UWNn9E+p4PDNb8 y7Wj1dY3ebuWHBJb5Pfb35sg3iw2i+hbr5J2BjTkODGAwmwVFYr1hX0Pw0tSYLstUm0s WpbnIxvZA4rvowYmPeWB5O8zCmA2s1SYVeswhpKej+uSDfSQXgAKkbsabRIcSNuvHel9 hnFQ== X-Received: by 10.194.82.167 with SMTP id j7mr24719658wjy.123.1442856980846; Mon, 21 Sep 2015 10:36:20 -0700 (PDT) Received: from minas-tirith.valinor (118.Red-176-80-72.dynamicIP.rima-tde.net. [176.80.72.118]) by smtp.gmail.com with ESMTPSA id e6sm9178635wiy.3.2015.09.21.10.36.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Sep 2015 10:36:20 -0700 (PDT) Sender: Carlos Robinson Received: from localhost (localhost [127.0.0.1]) by minas-tirith.valinor (Postfix) with ESMTP id 987EA181FEC for ; Mon, 21 Sep 2015 19:36:10 +0200 (CEST) Date: Mon, 21 Sep 2015 19:36:10 +0200 (CEST) From: "Carlos E. R." X-X-Sender: cer@minas-tirith.valinor To: XFS mailing list Subject: Re: What's up with this list? In-Reply-To: <56001EB2.2000109@sgi.com> X-ASG-Orig-Subj: Re: What's up with this list? Message-ID: References: <541AFB60.5030403@sgi.com> <55FAF053.3020405@sgi.com> <55FB06E8.1020203@opensuse.org> <55FC3569.5020801@sgi.com> <20150918225624.GF26895@dastard> <56001EB2.2000109@sgi.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463758550-1715253016-1442856172=:24753" Content-ID: X-Barracuda-Connect: mail-wi0-f170.google.com[209.85.212.170] X-Barracuda-Start-Time: 1442856982 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22758 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463758550-1715253016-1442856172=:24753 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: El 2015-09-21 a las 10:13 -0500, Troy McCorkell escribió: > I understand moderation is not an option. Just reviewing the options. > > oss.sgi.com is not a stand alone system when it comes to email. All > emails received by oss.sgi.com first pass through the SGI corporate spam > filters. Several of the old defunct mailing lists on oss.sgi.com have > been configured as spam-traps. Additional spam filters have been added > specifically for oss.sgi.com. And yet spam continues to hit the list. > > I'll continue the conversation with the SGI IT group. At opensuse mail lists they tried for a year or two opening some mail lists, so that subscription was not required for posting, on some of the lists. The ammount of spam increased. Aparently all measures they tried failed, and they eventually went back to the old system or requring registration previous to emailing. Curtailing that amount of spam would take aggresive filtering, so agresive as to make difficult for normal people to post. However, most of that spam was filtered out at my inbox. Ocassionally, a post would bounce at my ISP, yes, same as here. But I never got unsuscribed. Instead, I get probing posts like this: +++-.-.-.-.-.-.-.-.-. Subject: Bouncing messages from opensuse@opensuse.org Hi, this is the Mlmmj program managing the mailing list. Some messages to you could not be delivered. If you're seeing this message it means things are back to normal, and it's merely for your information. Here is the list of the bounced messages: - - 176321 - - 176324 - - 176323 - - 176320 - -.-.-.-.-.-.-.-.-.++- If I try to retrieve one of those failed posts, get it resent, it never arrives. Apparently it bounces again. Sometimes I'm able to locate it at the web mail archive, and it is certainly spam, with an invalid "from:" or similar issue. The problem, for me, is that sgi.com's Mailman doesn't probe. Instead, it shooes me out inmediately if one post can not be sent. Aparently it does not consider that other posts are sent without problem, nor sends a probe. That's the problem that concerns me: that my subscription is deactivated on bounces. And it is the only mail list that I'm subscribed to where this happens, as far as I remember. - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYAQAoACgkQja8UbcUWM1yarQD9FKvr6pmjvKd23Cuc/eJY9u88 2szq7MAbEtica4AcYDkA/375dewwBfik89iOwWeeQIZnk7FBFPrT9VsJ00FOgAL9 =Z0Ro -----END PGP SIGNATURE----- ---1463758550-1715253016-1442856172=:24753-- From sandeen@sandeen.net Mon Sep 21 15:50:25 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=MIME_QP_LONG_LINE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id C70B77F37 for ; Mon, 21 Sep 2015 15:50:24 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 65895AC001 for ; Mon, 21 Sep 2015 13:50:24 -0700 (PDT) X-ASG-Debug-ID: 1442868618-04bdf046225d0a0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id wvPGn07LgpiU7Oka for ; Mon, 21 Sep 2015 13:50:18 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from [100.246.252.123] (unknown [172.56.8.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 544E66214D12; Mon, 21 Sep 2015 15:50:18 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] xfs_io: Implement inodes64 command From: Eric Sandeen X-ASG-Orig-Subj: Re: [PATCH] xfs_io: Implement inodes64 command X-Mailer: iPhone Mail (13A344) In-Reply-To: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> Date: Mon, 21 Sep 2015 15:50:21 -0500 Cc: xfs@oss.sgi.com Content-Transfer-Encoding: quoted-printable Message-Id: <67F3D80A-F1B2-468C-A105-4AA881BC4F72@sandeen.net> References: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> To: Carlos Maiolino X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1442868618 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.82 X-Barracuda-Spam-Status: No, SCORE=0.82 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MIME_QP_LONG_LINE, MIME_QP_LONG_LINE_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22763 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.82 MIME_QP_LONG_LINE_2 RAW: Quoted-printable line longer than 76 chars On Sep 21, 2015, at 3:56 AM, Carlos Maiolino wrote: >=20 > Implement an easy way to check a filesystem for the existence of 64bit ino= des. >=20 > Based on XFS_IOC_FSINUMBERS, and starting with a lastip of XFS_MAXINUMBER_= 32, it > returns a string saying if there is or there isn't 64bit inodes in the > filesystem. >=20 > Signed-off-by: Carlos Maiolino > --- > io/open.c | 39 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 39 insertions(+) >=20 > diff --git a/io/open.c b/io/open.c > index ac5a5e0..b25b09d 100644 > --- a/io/open.c > +++ b/io/open.c > @@ -20,6 +20,7 @@ > #include "input.h" > #include "init.h" > #include "io.h" > +#include "libxfs.h" >=20 > #ifndef __O_TMPFILE > #if defined __alpha__ > @@ -44,6 +45,7 @@ static cmdinfo_t statfs_cmd; > static cmdinfo_t chproj_cmd; > static cmdinfo_t lsproj_cmd; > static cmdinfo_t extsize_cmd; > +static cmdinfo_t inodes64_cmd; > static prid_t prid; > static long extsize; >=20 > @@ -750,6 +752,36 @@ statfs_f( > return 0; > } >=20 > +static int > +inodes64_f( > + int argc, > + char **argv) > +{ > + int i; > + __s32 count; > + __u64 last =3D XFS_MAXINUMBER_32; > + xfs_inogrp_t igroup; > + xfs_fsop_bulkreq_t bulkreq; > + > + bulkreq.lastip =3D &last; > + bulkreq.icount =3D 1; > + bulkreq.ubuffer =3D &igroup; > + bulkreq.ocount =3D &count; > + > + if (!xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { > + if (count > 0) { > + printf("Filesystem does have 64bit inodes\n"); > + return 0; > + } else { > + printf("Filesystem does not have 64bit inodes\n"); > + return 0; > + } > + } > + perror("xfsctl(XFS_IOC_FSINUMBERS)"); > + exitcode =3D 1; > + return 0; > +} > + > void > open_init(void) > { > @@ -815,6 +847,12 @@ open_init(void) > _("get/set preferred extent size (in bytes) for the open file"); > extsize_cmd.help =3D extsize_help; >=20 > + inodes64_cmd.name =3D "inodes64"; > + inodes64_cmd.cfunc =3D inodes64_f; > + inodes64_cmd.flags =3D CMD_NOMAP_OK; > + inodes64_cmd.oneline =3D > + _("Checks if filesyste contais 64bit inodes"); "Check if filesystem contains 64bit inodes" Still needs a manpage update ;) Also is it ok to not have inodes64_cmd.help? (Sorry, on phone right now, ca= n't look, perhaps it's fine) Thanks, Eric > + > add_command(&open_cmd); > add_command(&stat_cmd); > add_command(&close_cmd); > @@ -822,4 +860,5 @@ open_init(void) > add_command(&chproj_cmd); > add_command(&lsproj_cmd); > add_command(&extsize_cmd); > + add_command(&inodes64_cmd); > } > --=20 > 2.4.3 >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs >=20 From david@fromorbit.com Mon Sep 21 16:53:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A41F77F37 for ; Mon, 21 Sep 2015 16:53:20 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 4F52AAC001 for ; Mon, 21 Sep 2015 14:53:20 -0700 (PDT) X-ASG-Debug-ID: 1442872397-04bdf046265ea10001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id yqWxvy17o3xBBVxE for ; Mon, 21 Sep 2015 14:53:17 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CrCQDcewBWPOV8LHldgySBPYJcg32iUAEBAQEBAQaKcpEhBAICgTlNAQEBAQEBBwEBAQFBP4QlAQEEOhwjEAgDDgoJJQ8FJQMHGhOILctsAQEBBwIBHxmGE4VEhQ0HgxiBFAEElWSNA48AjB6EdiwziW0BAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 22 Sep 2015 07:22:42 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Ze90r-0006k7-UY; Tue, 22 Sep 2015 07:52:42 +1000 Date: Tue, 22 Sep 2015 07:52:41 +1000 From: Dave Chinner To: Tetsuo Handa Cc: xfs@oss.sgi.com, linux-mm@kvack.org Subject: Re: [PATCH] mm, vmscan: Warn about possible deadlock at shirink_inactive_list Message-ID: <20150921215241.GA19114@dastard> X-ASG-Orig-Subj: Re: [PATCH] mm, vmscan: Warn about possible deadlock at shirink_inactive_list References: <1442833794-23117-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442833794-23117-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442872397 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22765 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Mon, Sep 21, 2015 at 08:09:54PM +0900, Tetsuo Handa wrote: > This is a difficult-to-trigger silent hang up bug. > > The kswapd is allowed to bypass too_many_isolated() check in > shrink_inactive_list(). But the kswapd can be blocked by locks in > shrink_page_list() in shrink_inactive_list(). If the task which is > blocking the kswapd is trying to allocate memory with the locks held, > it forms memory reclaim deadlock. It's a known problem in XFS and I'm currently working on patches to fix it by hoisting the memory allocations outside of the CIL context lock. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Mon Sep 21 17:09:25 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 1E90D7F37 for ; Mon, 21 Sep 2015 17:09:25 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id E47EC304048 for ; Mon, 21 Sep 2015 15:09:21 -0700 (PDT) X-ASG-Debug-ID: 1442873358-04bdf046225f2b0001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id m0dyBMJ16DdpNjiq for ; Mon, 21 Sep 2015 15:09:18 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ATCgCOfwBWPOV8LHldgyRUaYJcg32iUAEBAQEBAQaKcosqhXcCAgEBAoE5TQEBAQEBAQcBAQEBQT+EJQEBBCcTHCMQCAMOCgklDwUlAwcaE4gty2UBAQEHAgEfGYYThUSFDQeDGIEUBYx9iGeFEYdygVGBZoJPiHqMHoJxAxyBZiwziW0BAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 22 Sep 2015 07:38:33 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Ze9GC-0006mQ-MI; Tue, 22 Sep 2015 08:08:32 +1000 Date: Tue, 22 Sep 2015 08:08:32 +1000 From: Dave Chinner To: Carlos Maiolino Cc: xfs@oss.sgi.com Subject: Re: [PATCH] xfs_io: Implement inodes64 command Message-ID: <20150921220832.GB19114@dastard> X-ASG-Orig-Subj: Re: [PATCH] xfs_io: Implement inodes64 command References: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442873358 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22765 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Mon, Sep 21, 2015 at 10:56:08AM +0200, Carlos Maiolino wrote: > Implement an easy way to check a filesystem for the existence of 64bit inodes. > > Based on XFS_IOC_FSINUMBERS, and starting with a lastip of XFS_MAXINUMBER_32, it > returns a string saying if there is or there isn't 64bit inodes in the > filesystem. > > Signed-off-by: Carlos Maiolino > --- > io/open.c | 39 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 39 insertions(+) > > diff --git a/io/open.c b/io/open.c > index ac5a5e0..b25b09d 100644 > --- a/io/open.c > +++ b/io/open.c > @@ -20,6 +20,7 @@ > #include "input.h" > #include "init.h" > #include "io.h" > +#include "libxfs.h" > > #ifndef __O_TMPFILE > #if defined __alpha__ > @@ -44,6 +45,7 @@ static cmdinfo_t statfs_cmd; > static cmdinfo_t chproj_cmd; > static cmdinfo_t lsproj_cmd; > static cmdinfo_t extsize_cmd; > +static cmdinfo_t inodes64_cmd; > static prid_t prid; > static long extsize; > > @@ -750,6 +752,36 @@ statfs_f( > return 0; > } > > +static int > +inodes64_f( > + int argc, > + char **argv) > +{ > + int i; > + __s32 count; > + __u64 last = XFS_MAXINUMBER_32; > + xfs_inogrp_t igroup; > + xfs_fsop_bulkreq_t bulkreq; Please don't use typedefs. > + > + bulkreq.lastip = &last; > + bulkreq.icount = 1; > + bulkreq.ubuffer = &igroup; > + bulkreq.ocount = &count; > + > + if (!xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { > + if (count > 0) { > + printf("Filesystem does have 64bit inodes\n"); > + return 0; > + } else { > + printf("Filesystem does not have 64bit inodes\n"); > + return 0; > + } > + } > + perror("xfsctl(XFS_IOC_FSINUMBERS)"); I'd do this the other way around: if (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { perror("XFS_IOC_FSINUMBERS"); exitcode = 1; return 0; } if (count > 0) printf("Filesystem does have 64bit inodes\n"); else printf("Filesystem does not have 64bit inodes\n"); return 0; is sufficient, xfsctl is a one line wrapper around ioctl(). > @@ -815,6 +847,12 @@ open_init(void) > _("get/set preferred extent size (in bytes) for the open file"); > extsize_cmd.help = extsize_help; > > + inodes64_cmd.name = "inodes64"; > + inodes64_cmd.cfunc = inodes64_f; > + inodes64_cmd.flags = CMD_NOMAP_OK; > + inodes64_cmd.oneline = > + _("Checks if filesyste contais 64bit inodes"); ^^^ ^^ 64 bit "inodes64" could be improved as a command name. e.g: oneline = _("Query inode number usage in the filesystem") And could do a little more to help users work out what the problematic inode is. e.g: Long help: Inode_numbers [-s|-l] [num] [-s] returns the physical size of the largest inode number in the filesystem (32 bit of 64 bit) [-l] returns the largest inode number in the filesystem [-n] returns the next inode number after [num] [num] returns whether the inode number exists i.e. if you want 32 bit inodes in the fs, you can use [-n num] to iterate all the inode numbers above 32 bits in size... Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Mon Sep 21 17:18:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id EDE0E7F37 for ; Mon, 21 Sep 2015 17:18:47 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id DC4688F8040 for ; Mon, 21 Sep 2015 15:18:44 -0700 (PDT) X-ASG-Debug-ID: 1442873921-04cbb033b1655b0001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id kzGYied6f1869cEQ for ; Mon, 21 Sep 2015 15:18:41 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2APCgDfgQBWPOV8LHldgySBPYJcg32iUAEBAQEBAQaKcpEhAgIBAQKBNE0BAQEBAQEHAQEBAUE/hCQBAQEDAScTHCMFCwgDDgoJJQ8FJQMHGhOIJgfLYgEBAQEBBQEBAQEBHRmGE4VEhQ0HgxiBFAWVZI0Dmx6CdByBZiwziW0BAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 22 Sep 2015 07:48:40 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Ze9Pz-0006nU-Rj; Tue, 22 Sep 2015 08:18:39 +1000 Date: Tue, 22 Sep 2015 08:18:39 +1000 From: Dave Chinner To: Mika Eloranta Cc: xfs@oss.sgi.com Subject: Re: [PATCH] mkfs.xfs: add [-U uuid] option Message-ID: <20150921221839.GC19114@dastard> X-ASG-Orig-Subj: Re: [PATCH] mkfs.xfs: add [-U uuid] option References: <1442855060-38259-1-git-send-email-mel@ohmu.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442855060-38259-1-git-send-email-mel@ohmu.fi> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442873921 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22766 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Mon, Sep 21, 2015 at 08:04:20PM +0300, Mika Eloranta wrote: > The UUID can now be optionally specified during filesystem > creation. Which UUID are you wanting to set - the metadata uuid or the user visible UUID label? Or both? Can you explain the use case for this? i.e. I'm trying to work out why Why doesn't mkfs.xfs + xfs_admin -U doesn't work for you? We need some explaination in the commit message so that when we look at this in a couple of years time we know why we added this to mkfs... > @@ -948,6 +948,7 @@ main( > bool finobtflag; > int spinodes; > > + platform_uuid_clear(&uuid); > progname = basename(argv[0]); > setlocale(LC_ALL, ""); > bindtextdomain(PACKAGE, LOCALEDIR); > @@ -990,7 +991,7 @@ main( > xi.isdirect = LIBXFS_DIRECT; > xi.isreadonly = LIBXFS_EXCLUSIVELY; > > - while ((c = getopt(argc, argv, "b:d:i:l:L:m:n:KNp:qr:s:CfV")) != EOF) { > + while ((c = getopt(argc, argv, "b:d:i:l:L:U:m:n:KNp:qr:s:CfV")) != EOF) { > switch (c) { > case 'C': > case 'f': > @@ -1465,6 +1466,10 @@ main( > illegal(optarg, "L"); > label = optarg; > break; > + case 'U': > + if (platform_uuid_parse(optarg, &uuid)) > + illegal(optarg, "U"); > + break; I'd prefer not to introduce new top level options if possible - this seems to fit under the -m (global metadata options) option subgroup (i.e. -m uuid=). > case 'm': > p = optarg; > while (*p != '\0') { > @@ -2550,7 +2555,9 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"), > sbp->sb_dblocks = dblocks; > sbp->sb_rblocks = rtblocks; > sbp->sb_rextents = rtextents; > - platform_uuid_generate(&uuid); > + if (platform_uuid_is_null(&uuid)) { > + platform_uuid_generate(&uuid); > + } Just generate the uuid initially and then it gets overwritten by the CLI option if it is set. No need for null detection and generation here. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Mon Sep 21 17:52:49 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id C67D57F37 for ; Mon, 21 Sep 2015 17:52:49 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id B26248F804C for ; Mon, 21 Sep 2015 15:52:49 -0700 (PDT) X-ASG-Debug-ID: 1442875965-04cb6c6b0459350001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id w0N5aSTZnIRWzgzv for ; Mon, 21 Sep 2015 15:52:46 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DuHADqiABWPOV8LHlDGoMkVGmCXIotnBEPAQEBAQEBBkRGiWiKUV+FcQICAQECgTRNAQEBAQEBBwEBAQFBP4QkAQEBAwE6HCMFCwgDGAklDwUlAwcaE4gmBw47yxsBAQEBAQEBAwEBAQEBARwZhhOFRIQ7AQFQB4MYgRQFhzSOMIURh3KBUZVgg22EdiwzAYgtgT8BAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 22 Sep 2015 08:22:45 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Ze9wy-0006rf-Ay; Tue, 22 Sep 2015 08:52:44 +1000 Date: Tue, 22 Sep 2015 08:52:44 +1000 From: Dave Chinner To: Angelo Dureghello Cc: xfs@oss.sgi.com Subject: Re: xfstests, bad generic tests 009 and 308 Message-ID: <20150921225244.GD19114@dastard> X-ASG-Orig-Subj: Re: xfstests, bad generic tests 009 and 308 References: <55FC3E0E.9060506@nomovok.com> <20150918224412.GE26895@dastard> <55FFE665.7040004@nomovok.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55FFE665.7040004@nomovok.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442875965 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.70 X-Barracuda-Spam-Status: No, SCORE=0.70 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA085, MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22767 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words 0.10 BSF_SC0_SA085 Custom Rule SA085 On Mon, Sep 21, 2015 at 01:13:41PM +0200, Angelo Dureghello wrote: > Hi Dave, > > many thanks for the support. Sorry for the double mail, after > first registering mails was not accepted, so i re-registered > with a company mail. > > > On 19/09/2015 00:44, Dave Chinner wrote: > >On Fri, Sep 18, 2015 at 06:38:38PM +0200, Angelo Dureghello wrote: > >>Hi all, > >> > >>working on arm (32bit arch), kernel 4.1.6. > >Is this a new platform? > > > >Also, we need to know what compiler you are using, because we know > >that certain versions of gcc miscompile XFS kernel code on arm > >(4.6, 4.7 and certain versions of 4.8 are suspect) due to a > >combination of compiler mis-optimisations and kernel bugs in the > >arm 64 bit division asm implementation. > > > >As such, it would be worthwhile trying gcc-4.9 and a 4.3-rc1 kernel > >to see if the problems still occur. > > I am using actually gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf So gcc-4.9 patched with a bunch of stuff from linaro and built as a cross compiler from x86-64 to 32 bit arm? ISTR we had a bunch of different compiler problems at one point that only showed up in kernels build with a x86-64 to arm cross-compiler. In case you haven't guessed, XFS has a history of being bitten by ARM compiler problems. There's been a lot more problems in the past couple of years than the historical trend, though. As it is, I highly recommend that you try a current 4.3 kernel, as there are several code fixes in the XFS kernel code that work around compiler issues we know about. AFAIA, the do_div() asm bug that trips recent gcc optimisations isn't in the upstream kernel yet, but that can be worked around by setting CONFIG_CC_OPTIMIZE_FOR_SIZE=y in your build. > >>generic/009 [ 842.949643] run fstests generic/009 at 2015-09-18 > >>15:29:36 > >> - output mismatch (see > >>/home/angelo/xfstests/results//generic/009.out.bad) > >> --- tests/generic/009.out 2015-09-17 10:54:06.689071257 +0000 > >> +++ /home/angelo/xfstests/results//generic/009.out.bad > >>2015-09-18 15:29:41.412784177 +0000 > >> @@ -1,79 +1,45 @@ > >> QA output created by 009 > >> 1. into a hole > >> -0: [0..7]: hole > >> -1: [8..23]: unwritten > >> -2: [24..39]: hole > >> +0: [0..39]: hole > >> daa100df6e6711906b61c9ab5aa16032 > >> > >>also some other tests are giving the same bad notices. > >Can you attach the entire > >/home/angelo/xfstests/results//generic/009.out.bad file? I'm not > >sure which of the tests this output comes from, so I need to > >confirm which specific operations are resulting in errors. > Sure, i completed the whole generic + shared + xfs tests. > In total i have 38 errors. And trying now one by one to understand > the reason. > I attached the 009 output. > > >>-tests/generic/308 > >>------------------ .... > I have recent git version of xfstests, but generic/308 shows > > #! /bin/bash > # FS QA Test No. 308 > # > # Regression test for commit: > # f17722f ext4: Fix max file size and logical block counting of > extent format file More that one filesystem had problems with maximum file sizes on 32 bit systems. Compare the contents of the test; don't stop reading because the summary of the test makes you think the rest of the test is unrelated to the problem at hand. > I have a 16MB partition, and wondering why xfs allows from test 308 > to create a 16TB file. > > -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 https://en.wikipedia.org/wiki/Sparse_file > QA output created by 009 > 1. into a hole > 0: [0..39]: hole > daa100df6e6711906b61c9ab5aa16032 > 2. into allocated space > cc58a7417c2d7763adc45b6fcd3fa024 > 3. into unwritten space > daa100df6e6711906b61c9ab5aa16032 I don't need to look any further to see that something is badly wrong here. This is telling me that no extents are being allocated at all, which indicates either fiemap is broken, awk/sed is broken or misbehaving (and hence mangling the output) or something deep in the filesystem code is fundamentally broken in some strange, silent way. Can you create an xfs filesystem on your scratch device, and manually run this command and post the output: # mkfs.xfs -V # mkfs.xfs # mount /mnt/xfs # xfs_io -f -c "pwrite 0 64k" -c sync \ -c "bmap -vp" -c "fiemap -v" \ -c "falloc 1024k 256k" -c sync \ -c "pwrite 1088k 64k" -c sync \ -c "bmap -vp" -c "fiemap -v" \ /mnt/xfs/testfile and attach the entire output? It would also be good if you can run this command under trace-cmd and capture all the XFS events that occur during the test. See http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F for details, and attach the (compressed) report file. Cheers, Dave. -- Dave Chinner david@fromorbit.com From mika.eloranta@ohmu.fi Mon Sep 21 17:56:58 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 474877F3F for ; Mon, 21 Sep 2015 17:56:58 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 22B94304053 for ; Mon, 21 Sep 2015 15:56:58 -0700 (PDT) X-ASG-Debug-ID: 1442876215-04cb6c6b0759460001-NocioJ Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by cuda.sgi.com with ESMTP id EOQBkFF1OURKLUUL (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 21 Sep 2015 15:56:56 -0700 (PDT) X-Barracuda-Envelope-From: mika.eloranta@ohmu.fi X-Barracuda-Apparent-Source-IP: 66.111.4.25 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id BAB5620A41 for ; Mon, 21 Sep 2015 18:56:55 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 21 Sep 2015 18:56:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=GulQrmrDHD06BFN sZb+a7LSdmqU=; b=LFkZ2HzPpLqn+j3Hb20DkVfrNiBASCdlVyX2BwbSYs5o+Hk pT1dhlooquBM2q3KVEvGIyD9Sb4FmtYjX7RlAYOD2AFr2VqWTKrUHQytBKZe2O0N 0ieK+Kgfc2J99sK4k9enM9rJz5y0vkirI1nx6ozDpi3IGbiKqPvyiK+fWjmk= X-Sasl-enc: uQVYt02cpWR3DalMUQgQWkvktw/4cL8UePMlgbLZ7Ou4 1442876215 Received: from [192.168.1.104] (a88-115-163-75.elisa-laajakaista.fi [88.115.163.75]) by mail.messagingengine.com (Postfix) with ESMTPA id 29272C00013; Mon, 21 Sep 2015 18:56:55 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [PATCH] mkfs.xfs: add [-U uuid] option From: Mika Eloranta X-ASG-Orig-Subj: Re: [PATCH] mkfs.xfs: add [-U uuid] option In-Reply-To: <20150921221839.GC19114@dastard> Date: Tue, 22 Sep 2015 01:56:53 +0300 Cc: xfs@oss.sgi.com Content-Transfer-Encoding: quoted-printable Message-Id: <2640913C-6C95-4128-9055-B155AECA0206@ohmu.fi> References: <1442855060-38259-1-git-send-email-mel@ohmu.fi> <20150921221839.GC19114@dastard> To: Dave Chinner X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: out1-smtp.messagingengine.com[66.111.4.25] X-Barracuda-Start-Time: 1442876215 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22767 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 On 22 Sep 2015, at 01:18, Dave Chinner wrote: >=20 > On Mon, Sep 21, 2015 at 08:04:20PM +0300, Mika Eloranta wrote: >> The UUID can now be optionally specified during filesystem >> creation. >=20 > Which UUID are you wanting to set - the metadata uuid or the user > visible UUID label? Or both? Can you explain the use case for this? > i.e. I'm trying to work out why Why doesn't mkfs.xfs + > xfs_admin -U doesn't work for you? I want to set the user visible UUID (same as xfs_admin -U/-u). Whether = this impacts the "metadata uuid=E2=80=9D or not, I do not know, I=E2=80=99= m not an expert on the XFS internals, just a user. Use case: pre-defined UUID set for the filesystem by an _external = system_ so that a detached (network) filesystem can later be correctly = identified/verified by its UUID (i.e. by the contents of the filesystem = instead of metadata outside the filesystem). For example, first creating = a database record for a block filesystem with a random UUIDv4 and = creating the actual filesystem with the same UUID only after that. =E2=80=9Cmkfs.ext4" already supports this with the same exact = invocation. xfs_admin -U does not seem to be an option because: * xfs_admin -U option is going away? = http://oss.sgi.com/pipermail/xfs/2015-April/041265.html * Other people have issues with it: = https://bugzilla.redhat.com/show_bug.cgi?id=3D1233220 * I get inconsistent behavior with it: about half of the time = /dev/disk/by-uuid/* or =E2=80=9Clsblk" do NOT see the change (Fedora = 22). * Pre-assigning the UUID straight away during the filesystem creation = will work around any current or future bugs (e.g. above) and limitations = regarding changing the UUID. * When you need a filesystem with a specific UUID, it is an unnecessary = extra step to first create it with a random UUID and only afterwards set = it to the one you need. > We need some explaination in the commit message so that when we look > at this in a couple of years time we know why we added this to > mkfs=E2=80=A6 Sure, I can update the commit message. Please let me know if you need more clarifications, thanks! Cheers, - Mika >=20 >> @@ -948,6 +948,7 @@ main( >> bool finobtflag; >> int spinodes; >>=20 >> + platform_uuid_clear(&uuid); >> progname =3D basename(argv[0]); >> setlocale(LC_ALL, ""); >> bindtextdomain(PACKAGE, LOCALEDIR); >> @@ -990,7 +991,7 @@ main( >> xi.isdirect =3D LIBXFS_DIRECT; >> xi.isreadonly =3D LIBXFS_EXCLUSIVELY; >>=20 >> - while ((c =3D getopt(argc, argv, "b:d:i:l:L:m:n:KNp:qr:s:CfV")) = !=3D EOF) { >> + while ((c =3D getopt(argc, argv, = "b:d:i:l:L:U:m:n:KNp:qr:s:CfV")) !=3D EOF) { >> switch (c) { >> case 'C': >> case 'f': >> @@ -1465,6 +1466,10 @@ main( >> illegal(optarg, "L"); >> label =3D optarg; >> break; >> + case 'U': >> + if (platform_uuid_parse(optarg, &uuid)) >> + illegal(optarg, "U"); >> + break; >=20 > I'd prefer not to introduce new top level options if possible - this > seems to fit under the -m (global metadata options) option subgroup > (i.e. -m uuid=3D). >=20 >> case 'm': >> p =3D optarg; >> while (*p !=3D '\0') { >> @@ -2550,7 +2555,9 @@ _("size %s specified for log subvolume is too = large, maximum is %lld blocks\n"), >> sbp->sb_dblocks =3D dblocks; >> sbp->sb_rblocks =3D rtblocks; >> sbp->sb_rextents =3D rtextents; >> - platform_uuid_generate(&uuid); >> + if (platform_uuid_is_null(&uuid)) { >> + platform_uuid_generate(&uuid); >> + } >=20 > Just generate the uuid initially and then it gets overwritten by the > CLI option if it is set. No need for null detection and generation > here. >=20 > Cheers, >=20 > Dave. > --=20 > Dave Chinner > david@fromorbit.com From david@fromorbit.com Mon Sep 21 18:36:31 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id F16FE7F37 for ; Mon, 21 Sep 2015 18:36:31 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id CF8B98F8037 for ; Mon, 21 Sep 2015 16:36:31 -0700 (PDT) X-ASG-Debug-ID: 1442878588-04bdf0462861070001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id pKcrAWCnzrd80cT6 for ; Mon, 21 Sep 2015 16:36:29 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AQCgCxkwBWPOV8LHldgySBPYJcg32iUAEBAQEBAQaKcpEhAgIBAQKBNk0BAQEBAQEHAQEBAUE/hCUBAQQjDwEjFQ4QCAMYAgIFIQICDwUlAwcaE4gtt0GUHQEBAQEGAgEfGYEJhQqFRIUNB4JpL4EUBZVkjQOBUZVgg22CdByBZiwziW0BAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 22 Sep 2015 09:06:28 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeAdH-0006wd-GO; Tue, 22 Sep 2015 09:36:27 +1000 Date: Tue, 22 Sep 2015 09:36:27 +1000 From: Dave Chinner To: Mika Eloranta Cc: xfs@oss.sgi.com Subject: Re: [PATCH] mkfs.xfs: add [-U uuid] option Message-ID: <20150921233627.GE19114@dastard> X-ASG-Orig-Subj: Re: [PATCH] mkfs.xfs: add [-U uuid] option References: <1442855060-38259-1-git-send-email-mel@ohmu.fi> <20150921221839.GC19114@dastard> <2640913C-6C95-4128-9055-B155AECA0206@ohmu.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2640913C-6C95-4128-9055-B155AECA0206@ohmu.fi> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442878588 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22769 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 22, 2015 at 01:56:53AM +0300, Mika Eloranta wrote: > On 22 Sep 2015, at 01:18, Dave Chinner > wrote: > > > > On Mon, Sep 21, 2015 at 08:04:20PM +0300, Mika Eloranta wrote: > >> The UUID can now be optionally specified during filesystem > >> creation. > > > > Which UUID are you wanting to set - the metadata uuid or the > > user visible UUID label? Or both? Can you explain the use case > > for this? i.e. I'm trying to work out why Why doesn't mkfs.xfs > > + xfs_admin -U doesn't work for you? > > I want to set the user visible UUID (same as xfs_admin -U/-u). > Whether this impacts the "metadata uuid†or not, I do not > know, I’m not an expert on the XFS internals, just a user. Which tells me what I need to know - You are trying to use the UUID as a user controlled filesystem label. Funnily enough, we have a thing for this already - a user controlled filesystem label: # mkfs.xfs -L "label" .... It's 12 characters long, so more than enough for any sort of unique identification scheme you want to use for your filesystems. xfs_admin enables you to change it after the fact, all major filesystems support it and all the infrastructure know about it (lsblk, /etc/fstab. /dev/disk/by-label, etc) so using it is no different to using UUIDs. Except that, unlike UUIDs, you can make fileystem labels human readable. :) Perhaps you should try using filesystem labels seeing as everything you need is already there? Cheers, Dave. -- Dave Chinner david@fromorbit.com From sandeen@sandeen.net Mon Sep 21 20:42:36 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 4320F7F37 for ; Mon, 21 Sep 2015 20:42:36 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 322DF304032 for ; Mon, 21 Sep 2015 18:42:35 -0700 (PDT) X-ASG-Debug-ID: 1442886151-04cbb033b169b00001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id vlJvxPztECJA4oue for ; Mon, 21 Sep 2015 18:42:31 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id D5CEF6214D14 for ; Mon, 21 Sep 2015 20:42:30 -0500 (CDT) Subject: Re: [PATCH] mkfs.xfs: add [-U uuid] option To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] mkfs.xfs: add [-U uuid] option References: <1442855060-38259-1-git-send-email-mel@ohmu.fi> <20150921221839.GC19114@dastard> From: Eric Sandeen Message-ID: <5600B206.20806@sandeen.net> Date: Mon, 21 Sep 2015 20:42:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150921221839.GC19114@dastard> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1442886151 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22772 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/21/15 5:18 PM, Dave Chinner wrote: > On Mon, Sep 21, 2015 at 08:04:20PM +0300, Mika Eloranta wrote: >> The UUID can now be optionally specified during filesystem >> creation. > > Which UUID are you wanting to set - the metadata uuid or the user > visible UUID label? Or both? At mkfs time it should be the same / both. (the only reason they need to diverge is a post-mkfs user-visible change on a V5 fs). Can you explain the use case for this? > i.e. I'm trying to work out why Why doesn't mkfs.xfs + > xfs_admin -U doesn't work for you? > > We need some explaination in the commit message so that when we look > at this in a couple of years time we know why we added this to > mkfs... I'm a little curious to know why it's desired, but it's also so trivial it seems worth accepting if it's useful to someone. mke2fs (mkfs.ext[234]) and mkfs.btrfs can do this today as well, so something seems to be driving the desire for the feature. -Eric From david@fromorbit.com Mon Sep 21 21:21:51 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 5C2D77F3F for ; Mon, 21 Sep 2015 21:21:51 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 2CB8D8F8033 for ; Mon, 21 Sep 2015 19:21:48 -0700 (PDT) X-ASG-Debug-ID: 1442888504-04bdf04622645f0001-NocioJ Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id AlQQIZtRVvveYtEK for ; Mon, 21 Sep 2015 19:21:44 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CsCQBlugBWPOV8LHldgySBPYJcg32iUQEBAQEBAQaKcpEhBAICgTxNAQEBAQEBBwEBAQFBP4QkAQEBAwEnExwjBQsIAxgJJQ8FJQMHGhOIJgfLPwEBAQEGAQEBAR4ZhhOFRIUNB4MYgRQFhzSLB4MpjQODN4tJjB6CcQMcgWYsM4ltAQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail04.adl6.internode.on.net with ESMTP; 22 Sep 2015 11:47:56 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeD9X-0007Cl-Kk; Tue, 22 Sep 2015 12:17:55 +1000 Date: Tue, 22 Sep 2015 12:17:55 +1000 From: Dave Chinner To: "Darrick J. Wong" Cc: xfs@oss.sgi.com Subject: Re: [PATCH 08/11] xfs_io: support reflinking and deduping file ranges Message-ID: <20150922021755.GF19114@dastard> X-ASG-Orig-Subj: Re: [PATCH 08/11] xfs_io: support reflinking and deduping file ranges References: <20150826003220.23973.59731.stgit@birch.djwong.org> <20150826003311.23973.64761.stgit@birch.djwong.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150826003311.23973.64761.stgit@birch.djwong.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1442888504 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22773 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header On Tue, Aug 25, 2015 at 05:33:11PM -0700, Darrick J. Wong wrote: > +static int > +dedupe_f( > + int argc, > + char **argv) > +{ > + off64_t soffset, doffset; > + long long count, total; > + char s1[64], s2[64], ts[64]; Magic! > + char *infile; > + int Cflag, qflag, wflag, Wflag; Urk. Variables that differ only by case! > + struct xfs_ioctl_file_extent_same_args *args = NULL; > + struct xfs_ioctl_file_extent_same_info *info; verbosity--; > + size_t fsblocksize, fssectsize; > + struct timeval t1, t2; > + int c, fd = -1; > + > + Cflag = qflag = wflag = Wflag = 0; > + init_cvtnum(&fsblocksize, &fssectsize); > + > + while ((c = getopt(argc, argv, "CqwW")) != EOF) { > + switch (c) { > + case 'C': > + Cflag = 1; > + break; > + case 'q': > + qflag = 1; > + break; > + case 'w': > + wflag = 1; > + break; > + case 'W': > + Wflag = 1; > + break; > + default: > + return command_usage(&dedupe_cmd); > + } > + } > + if (optind != argc - 4) > + return command_usage(&dedupe_cmd); > + infile = argv[optind]; > + optind++; > + soffset = cvtnum(fsblocksize, fssectsize, argv[optind]); > + if (soffset < 0) { > + printf(_("non-numeric src offset argument -- %s\n"), argv[optind]); > + return 0; > + } > + optind++; > + doffset = cvtnum(fsblocksize, fssectsize, argv[optind]); > + if (doffset < 0) { > + printf(_("non-numeric dest offset argument -- %s\n"), argv[optind]); > + return 0; > + } > + optind++; > + count = cvtnum(fsblocksize, fssectsize, argv[optind]); > + if (count < 1) { > + printf(_("non-positive length argument -- %s\n"), argv[optind]); > + return 0; > + } > + > + c = IO_READONLY; > + fd = openfile(infile, NULL, c, 0); > + if (fd < 0) > + return 0; > + > + gettimeofday(&t1, NULL); > + args = calloc(1, sizeof(struct xfs_ioctl_file_extent_same_args) + > + sizeof(struct xfs_ioctl_file_extent_same_info)); > + if (!args) > + goto done; > + info = (struct xfs_ioctl_file_extent_same_info *)(args + 1); > + args->logical_offset = soffset; > + args->length = count; > + args->dest_count = 1; > + info->fd = file->fd; > + info->logical_offset = doffset; > + do { > + c = ioctl(fd, XFS_IOC_FILE_EXTENT_SAME, args); > + if (c) > + break; > + args->logical_offset += info->bytes_deduped; > + info->logical_offset += info->bytes_deduped; > + args->length -= info->bytes_deduped; > + } while (c == 0 && info->status == 0 && info->bytes_deduped > 0); What's "c"? it's actually a return value, and it's already been handled if it's non zero. and there's nothing preventing args->length from going negative. > + if (c) > + perror(_("dedupe ioctl")); > + if (info->status < 0) > + printf("dedupe: %s\n", _(strerror(-info->status))); > + if (info->status == XFS_SAME_DATA_DIFFERS) "same data differs"? Really? :P > + printf(_("Extents did not match.\n")); And putting hte error messages outside the loop is going to be hard to maintain. I'd much prefer to see this written as: while (args->length > 0) { result = ioctl(fd, XFS_IOC_FILE_EXTENT_SAME, args); if (result) { perror("XFS_IOC_FILE_EXTENT_SAME"); goto done; } if (info->status != 0) { printf("dedupe: %s\n", _(strerror(-info->status))); if (info->status == XFS_SAME_DATA_DIFFERS) printf(_("Extents did not match.\n")); goto done; } if (info->bytes_deduped == 0) break; args->logical_offset += info->bytes_deduped; info->logical_offset += info->bytes_deduped; args->length -= info->bytes_deduped; } Actually, I'd really lik eto see this bit factored out into a separate function, so there's clear separation between arg parsing, the operation and post-op cleanup. > + total = info->bytes_deduped; > + c = 1; > + if (Wflag) > + fsync(file->fd); > + if (wflag) > + fdatasync(file->fd); So these flags are just for syncing. This does not need to be a part of this function, because the user can simply do: xfs_io -c "dedupe ...." -c "fsync" ... if an fsync or fdatasync is required after dedupe. So kill those options. > + if (qflag) > + goto done; Urk. > + gettimeofday(&t2, NULL); > + t2 = tsub(t2, t1); > + > + /* Finally, report back -- -C gives a parsable format */ > + timestr(&t2, ts, sizeof(ts), Cflag ? VERBOSE_FIXED_TIME : 0); > + if (!Cflag) { > + cvtstr((double)total, s1, sizeof(s1)); > + cvtstr(tdiv((double)total, t2), s2, sizeof(s2)); > + printf(_("linked %lld/%lld bytes at offset %lld\n"), > + total, count, (long long)doffset); > + printf(_("%s, %d ops; %s (%s/sec and %.4f ops/sec)\n"), > + s1, c, ts, s2, tdiv((double)c, t2)); > + } else {/* bytes,ops,time,bytes/sec,ops/sec */ > + printf("%lld,%d,%s,%.3f,%.3f\n", > + total, c, ts, > + tdiv((double)total, t2), tdiv((double)c, t2)); > + } This must be common with other timing code. Factor it out? > +static void > +reflink_help(void) > +{ > + printf(_( > +"\n" > +" Links a range of bytes (in block size increments) from a file into a range \n" > +" of bytes in the open file. The two extent ranges need not contain identical\n" > +" data. \n" > +"\n" > +" Example:\n" > +" 'reflink some_file 0 4096 32768' - links 32768 bytes from some_file at \n" > +" offset 0 to into the open file at \n" > +" position 4096\n" > +" 'reflink some_file' - links all bytes from some_file into the open file\n" > +" at position 0\n" > +"\n" > +" Reflink a range of blocks from a given input file to the open file. Both\n" > +" files share the same range of physical disk blocks; a write to the shared\n" > +" range of either file should result in the write landing in a new block and\n" > +" that range of the file being remapped (i.e. copy-on-write). Both files\n" > +" must reside on the same filesystem.\n" > +" -w -- call fdatasync(2) at the end (included in timing results)\n" > +" -W -- call fsync(2) at the end (included in timing results)\n" > +"\n")); > +} FWIW, could these just be a single string like: " Links a range of bytes (in block size increments) from a file into a range of bytes in the open file. The two extent ranges need not contain identical .... \n")); So we don't have to mangle the entire layout if we modify the help tet in future? > +static int > +reflink_f( > + int argc, > + char **argv) > +{ Same comments as the dedupe_f() function about factoring and variable names and reusing "c" for a bunch of unrelated values. indeed, most of this is common with the dedupe_f function, so perhaps it might be worth putting them in the same file and factoring them appropriately to shared common elements? > diff --git a/libxfs/xfs_fs.h b/libxfs/xfs_fs.h > index 89689c6..0c922ad 100644 > --- a/libxfs/xfs_fs.h > +++ b/libxfs/xfs_fs.h > @@ -559,6 +559,42 @@ typedef struct xfs_swapext > #define XFS_IOC_GOINGDOWN _IOR ('X', 125, __uint32_t) > /* XFS_IOC_GETFSUUID ---------- deprecated 140 */ > > +/* reflink ioctls; these MUST match the btrfs ioctl definitions */ > +struct xfs_ioctl_clone_range_args { > + __s64 src_fd; > + __u64 src_offset; > + __u64 src_length; > + __u64 dest_offset; > +}; struct xfs_clone_args > + > +#define XFS_SAME_DATA_DIFFERS 1 #define XFS_EXTENT_DATA_SAME 0 #define XFS_EXTENT_DATA_DIFFERS 1 > +/* For extent-same ioctl */ > +struct xfs_ioctl_file_extent_same_info { > + __s64 fd; /* in - destination file */ > + __u64 logical_offset; /* in - start of extent in destination */ > + __u64 bytes_deduped; /* out - total # of bytes we were able > + * to dedupe from this file */ > + /* status of this dedupe operation: > + * 0 if dedup succeeds > + * < 0 for error > + * == XFS_SAME_DATA_DIFFERS if data differs > + */ > + __s32 status; /* out - see above description */ > + __u32 reserved; > +}; struct xfs_extent_data_info > + > +struct xfs_ioctl_file_extent_same_args { > + __u64 logical_offset; /* in - start of extent in source */ > + __u64 length; /* in - length of extent */ > + __u16 dest_count; /* in - total elements in info array */ > + __u16 reserved1; > + __u32 reserved2; > + struct xfs_ioctl_file_extent_same_info info[0]; > +}; struct xfs_extent_data > + > +#define XFS_IOC_CLONE _IOW (0x94, 9, int) > +#define XFS_IOC_CLONE_RANGE _IOW (0x94, 13, struct xfs_ioctl_clone_range_args) > +#define XFS_IOC_FILE_EXTENT_SAME _IOWR(0x94, 54, struct xfs_ioctl_file_extent_same_args) FWIW, these structure and ioctl definitions really need to be in a separate patch as they need to be shared with the kernel code. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Tue Sep 22 00:13:25 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id D69527F37 for ; Tue, 22 Sep 2015 00:13:25 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id A9CA6304039 for ; Mon, 21 Sep 2015 22:13:22 -0700 (PDT) X-ASG-Debug-ID: 1442898775-04bdf0462667cf0001-NocioJ Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id SqYDAi3k7ZVShkui for ; Mon, 21 Sep 2015 22:13:19 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BRCgD64QBWPOV8LHldgySBPYZZolIBAQEBAQaKdZEiAgIBAQKBOk0BAQEBAQEHAQEBAUE/hCUBAQQnExwjEAgDDgoJJQ8FJQMHGhOILcs+AQEBAQYCAR8ZhhOFRIUNB4MYgRQFjH2IaI0EgVKENYh7jCCCdBwWgVAsM4ltAQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail06.adl6.internode.on.net with ESMTP; 22 Sep 2015 14:42:54 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeFsr-0007Pf-Li; Tue, 22 Sep 2015 15:12:53 +1000 Date: Tue, 22 Sep 2015 15:12:53 +1000 From: Dave Chinner To: Tetsuo Handa Cc: xfs@oss.sgi.com, linux-mm@kvack.org, Michal Hocko Subject: Re: [PATCH v2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks Message-ID: <20150922051253.GB3902@dastard> X-ASG-Orig-Subj: Re: [PATCH v2] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks References: <20150920231858.GY3902@dastard> <1442798637-5941-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442798637-5941-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1442898776 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22775 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Mon, Sep 21, 2015 at 10:23:57AM +0900, Tetsuo Handa wrote: > This patch adds comm name and pid to warning messages printed by > kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory(). > This will help telling which memory allocations (e.g. kernel worker > threads, OOM victim tasks, neither) are stalling because these functions > are passing __GFP_NOWARN which suppresses not only backtrace but comm name > and pid. > > [ 135.568662] Out of memory: Kill process 9593 (a.out) score 998 or sacrifice child > [ 135.570195] Killed process 9593 (a.out) total-vm:4700kB, anon-rss:488kB, file-rss:0kB > [ 137.473691] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 137.497662] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 137.598219] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 139.494529] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 139.517196] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 139.616396] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 141.512753] XFS: kworker/u16:29(383) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 141.531421] XFS: a.out(8944) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > [ 141.633574] XFS: a.out(9658) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x1250) > > (Strictly speaking, we want task_lock()/task_unlock() when reading comm name.) > > Signed-off-by: Tetsuo Handa > Cc: Michal Hocko > --- > fs/xfs/kmem.c | 10 ++++++---- > fs/xfs/xfs_buf.c | 3 ++- > 2 files changed, 8 insertions(+), 5 deletions(-) > > diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c > index a7a3a63..735095a 100644 > --- a/fs/xfs/kmem.c > +++ b/fs/xfs/kmem.c > @@ -55,8 +55,9 @@ kmem_alloc(size_t size, xfs_km_flags_t flags) > return ptr; > if (!(++retries % 100)) > xfs_err(NULL, > - "possible memory allocation deadlock in %s (mode:0x%x)", > - __func__, lflags); > + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", > + current->comm, current->pid, > + __func__, lflags); <=80 columns, please. Cheers, Dave. -- Dave Chinner david@fromorbit.com From mika.eloranta@ohmu.fi Tue Sep 22 01:43:46 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 569227F3F for ; Tue, 22 Sep 2015 01:43:46 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 45E5A304032 for ; Mon, 21 Sep 2015 23:43:42 -0700 (PDT) X-ASG-Debug-ID: 1442904217-04cbb033b170310001-NocioJ Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by cuda.sgi.com with ESMTP id FUy1EHZ2Y752LcZS (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 21 Sep 2015 23:43:37 -0700 (PDT) X-Barracuda-Envelope-From: mika.eloranta@ohmu.fi X-Barracuda-Apparent-Source-IP: 66.111.4.25 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 702A920B12 for ; Tue, 22 Sep 2015 02:43:36 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 22 Sep 2015 02:43:36 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=7xYzF3NKkA0Wnb8 baw/Agn/pPL8=; b=fX8Hv8KVF3qTipmboZHSmrwL0Dezpuwoj2rBFdUlre8j+c8 NK/gXBaGhUmw6J3CIsk0muvD/16tMPVwMJkFWUrB62XbxGiFivdC5Y9YCKeet/CL hO5V4NiHLOd38VI9b2M8Wu0dLNOAoUNdUqJiluBH0vQzkXDf4CALyz16m2GY= X-Sasl-enc: MWHZIyAV6vxzAWv/9drAP6RlRQVcMp+xGiy/GZ4QcBww 1442904216 Received: from [192.168.1.104] (a88-115-163-75.elisa-laajakaista.fi [88.115.163.75]) by mail.messagingengine.com (Postfix) with ESMTPA id CF471C0001A; Tue, 22 Sep 2015 02:43:35 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [PATCH] mkfs.xfs: add [-U uuid] option From: Mika Eloranta X-ASG-Orig-Subj: Re: [PATCH] mkfs.xfs: add [-U uuid] option In-Reply-To: <20150921233627.GE19114@dastard> Date: Tue, 22 Sep 2015 09:43:34 +0300 Cc: xfs@oss.sgi.com Content-Transfer-Encoding: quoted-printable Message-Id: <5E0C9EC9-8ABE-47CC-BB7F-2BC0A872AEDB@ohmu.fi> References: <1442855060-38259-1-git-send-email-mel@ohmu.fi> <20150921221839.GC19114@dastard> <2640913C-6C95-4128-9055-B155AECA0206@ohmu.fi> <20150921233627.GE19114@dastard> To: Dave Chinner X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: out1-smtp.messagingengine.com[66.111.4.25] X-Barracuda-Start-Time: 1442904217 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22777 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 On 22 Sep 2015, at 02:36, Dave Chinner wrote: >=20 > On Tue, Sep 22, 2015 at 01:56:53AM +0300, Mika Eloranta wrote: >> On 22 Sep 2015, at 01:18, Dave Chinner >> wrote: >>>=20 >>> On Mon, Sep 21, 2015 at 08:04:20PM +0300, Mika Eloranta wrote: >>>> The UUID can now be optionally specified during filesystem >>>> creation. >>>=20 >>> Which UUID are you wanting to set - the metadata uuid or the >>> user visible UUID label? Or both? Can you explain the use case >>> for this? i.e. I'm trying to work out why Why doesn't mkfs.xfs >>> + xfs_admin -U doesn't work for you? >>=20 >> I want to set the user visible UUID (same as xfs_admin -U/-u). >> Whether this impacts the "metadata uuid=E2=80=9D or not, I do not >> know, I=E2=80=99m not an expert on the XFS internals, just a user. >=20 > Which tells me what I need to know - You are trying to use the UUID > as a user controlled filesystem label. Funnily enough, we have a > thing for this already - a user controlled filesystem label: >=20 > # mkfs.xfs -L "label" .... >=20 > It's 12 characters long, so more than enough for any sort of unique > identification scheme you want to use for your filesystems. > xfs_admin enables you to change it after the fact, all major > filesystems support it and all the infrastructure know about it > (lsblk, /etc/fstab. /dev/disk/by-label, etc) so using it is no > different to using UUIDs. Except that, unlike UUIDs, you can make > fileystem labels human readable. :) >=20 > Perhaps you should try using filesystem labels seeing as everything > you need is already there? Labels are great for user-readable identifiers, but UUID is nowadays pretty much the norm for random-generated identifiers. My use-case concerns distributed and automated virtual systems, where filesystems are constantly built and torn down. Using the filesystem label to store a truncated version of a UUID is kind of an option, but I'd really rather use the entire UUID because: 1) Identifying an orphan filesystem based on its contents becomes more straightforward, e.g. if they are already listed in a key-value store based on their full UUID and prefix lookups are not possible. 2) The label is actually rather short for storing a random ID. For example storing 48 bits from the UUID in the label hex-encoded would give me a collision already in 20 million fs instances with >50% probability. I thought adding the option would be a rather straightforward thing, especially when more problematic "xfs_admin -U" is (was?) already supported. Is there technical reason why assigning the UUID is no longer recommended? The patch only allows optionally using a user-specified UUID instead of a one generated randomly on the spot within mkfs.xfs, and I cannot see any harm in that. Cheers, Mika From cmaiolino@redhat.com Tue Sep 22 02:22:32 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id A9E2F7F37 for ; Tue, 22 Sep 2015 02:22:32 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 899778F8033 for ; Tue, 22 Sep 2015 00:22:29 -0700 (PDT) X-ASG-Debug-ID: 1442906548-04cb6c6b0763470001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id YZDKBJTFHM09Dcjg (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 00:22:28 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id CD6312F9102; Tue, 22 Sep 2015 07:22:27 +0000 (UTC) Received: from redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8M7MOHb018980 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2015 03:22:26 -0400 Date: Tue, 22 Sep 2015 09:22:24 +0200 From: Carlos Maiolino To: Mika Eloranta Cc: Dave Chinner , xfs@oss.sgi.com Subject: Re: [PATCH] mkfs.xfs: add [-U uuid] option Message-ID: <20150922072224.GA26699@redhat.com> X-ASG-Orig-Subj: Re: [PATCH] mkfs.xfs: add [-U uuid] option Mail-Followup-To: Mika Eloranta , Dave Chinner , xfs@oss.sgi.com References: <1442855060-38259-1-git-send-email-mel@ohmu.fi> <20150921221839.GC19114@dastard> <2640913C-6C95-4128-9055-B155AECA0206@ohmu.fi> <20150921233627.GE19114@dastard> <5E0C9EC9-8ABE-47CC-BB7F-2BC0A872AEDB@ohmu.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5E0C9EC9-8ABE-47CC-BB7F-2BC0A872AEDB@ohmu.fi> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1442906548 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 22, 2015 at 09:43:34AM +0300, Mika Eloranta wrote: > On 22 Sep 2015, at 02:36, Dave Chinner wrote: > > > > On Tue, Sep 22, 2015 at 01:56:53AM +0300, Mika Eloranta wrote: > >> On 22 Sep 2015, at 01:18, Dave Chinner > >> wrote: > >>> > >>> On Mon, Sep 21, 2015 at 08:04:20PM +0300, Mika Eloranta wrote: > >>>> The UUID can now be optionally specified during filesystem > >>>> creation. > >>> > >>> Which UUID are you wanting to set - the metadata uuid or the > >>> user visible UUID label? Or both? Can you explain the use case > >>> for this? i.e. I'm trying to work out why Why doesn't mkfs.xfs > >>> + xfs_admin -U doesn't work for you? > >> > >> I want to set the user visible UUID (same as xfs_admin -U/-u). > >> Whether this impacts the "metadata uuid†or not, I do not > >> know, I’m not an expert on the XFS internals, just a user. > > > > Which tells me what I need to know - You are trying to use the UUID > > as a user controlled filesystem label. Funnily enough, we have a > > thing for this already - a user controlled filesystem label: > > > > # mkfs.xfs -L "label" .... > > > > It's 12 characters long, so more than enough for any sort of unique > > identification scheme you want to use for your filesystems. > > xfs_admin enables you to change it after the fact, all major > > filesystems support it and all the infrastructure know about it > > (lsblk, /etc/fstab. /dev/disk/by-label, etc) so using it is no > > different to using UUIDs. Except that, unlike UUIDs, you can make > > fileystem labels human readable. :) > > > > Perhaps you should try using filesystem labels seeing as everything > > you need is already there? > > Labels are great for user-readable identifiers, but UUID is nowadays > pretty much the norm for random-generated identifiers. My use-case > concerns distributed and automated virtual systems, where filesystems > are constantly built and torn down. > > Using the filesystem label to store a truncated version of a UUID is > kind of an option, but I'd really rather use the entire UUID because: > > 1) Identifying an orphan filesystem based on its contents becomes > more straightforward, e.g. if they are already listed in a key-value > store based on their full UUID and prefix lookups are not possible. > > 2) The label is actually rather short for storing a random ID. For > example storing 48 bits from the UUID in the label hex-encoded > would give me a collision already in 20 million fs instances with > >50% probability. > > I thought adding the option would be a rather straightforward thing, > especially when more problematic "xfs_admin -U" is (was?) already > supported. Is there technical reason why assigning the UUID is no longer > recommended? The patch only allows optionally using a user-specified > UUID instead of a one generated randomly on the spot within mkfs.xfs, > and I cannot see any harm in that. > Hi Mika, I don't think that Dave's argument was regarding technical reasons, but the lack of information about the feature. Use case, etc We already have too many options in the xfs tools, and also, a way to set the uuid to a filesystem as explained before, and, although it is not harmful as you said, and I should say I agree with you in this point, the fact that you sent the patch without detailed information about why it is useful and the use cases for that (that you just described here), makes people ask you all these questions, mainly when there were no previous discussion regarding the feature, so, just keep in mind that in the next patches you might send, add as much information as possible, to (maybe :) speed up the integration of the patch, and even though, you're not free to have people asking you lots of questions regarding your patch. But anyway, I agree with the patchset and the points are fair enough for having this option, but having it as a -m uuid= instead of -U makes more sense here. > Cheers, > > Mika > -- Carlos From cmaiolino@redhat.com Tue Sep 22 02:45:06 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id B5CDE7F47 for ; Tue, 22 Sep 2015 02:45:05 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 9265F8F81CD for ; Tue, 22 Sep 2015 00:45:05 -0700 (PDT) X-ASG-Debug-ID: 1442907902-04cbb033b371710001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id GOKOwFuZhBRxF9St (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 00:45:03 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 6606EA2C20; Tue, 22 Sep 2015 07:45:02 +0000 (UTC) Received: from redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8M7iwxO012250 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2015 03:45:01 -0400 Date: Tue, 22 Sep 2015 09:44:58 +0200 From: Carlos Maiolino To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH] xfs_io: Implement inodes64 command Message-ID: <20150922074458.GB26699@redhat.com> X-ASG-Orig-Subj: Re: [PATCH] xfs_io: Implement inodes64 command Mail-Followup-To: Eric Sandeen , xfs@oss.sgi.com References: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> <67F3D80A-F1B2-468C-A105-4AA881BC4F72@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67F3D80A-F1B2-468C-A105-4AA881BC4F72@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442907903 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Mon, Sep 21, 2015 at 03:50:21PM -0500, Eric Sandeen wrote: > On Sep 21, 2015, at 3:56 AM, Carlos Maiolino wrote: > > > > Implement an easy way to check a filesystem for the existence of 64bit inodes. > > > > Based on XFS_IOC_FSINUMBERS, and starting with a lastip of XFS_MAXINUMBER_32, it > > returns a string saying if there is or there isn't 64bit inodes in the > > filesystem. > > > > Signed-off-by: Carlos Maiolino > > --- > > io/open.c | 39 +++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 39 insertions(+) > > > > diff --git a/io/open.c b/io/open.c > > index ac5a5e0..b25b09d 100644 > > --- a/io/open.c > > +++ b/io/open.c > > @@ -20,6 +20,7 @@ > > #include "input.h" > > #include "init.h" > > #include "io.h" > > +#include "libxfs.h" > > > > #ifndef __O_TMPFILE > > #if defined __alpha__ > > @@ -44,6 +45,7 @@ static cmdinfo_t statfs_cmd; > > static cmdinfo_t chproj_cmd; > > static cmdinfo_t lsproj_cmd; > > static cmdinfo_t extsize_cmd; > > +static cmdinfo_t inodes64_cmd; > > static prid_t prid; > > static long extsize; > > > > @@ -750,6 +752,36 @@ statfs_f( > > return 0; > > } > > > > +static int > > +inodes64_f( > > + int argc, > > + char **argv) > > +{ > > + int i; > > + __s32 count; > > + __u64 last = XFS_MAXINUMBER_32; > > + xfs_inogrp_t igroup; > > + xfs_fsop_bulkreq_t bulkreq; > > + > > + bulkreq.lastip = &last; > > + bulkreq.icount = 1; > > + bulkreq.ubuffer = &igroup; > > + bulkreq.ocount = &count; > > + > > + if (!xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { > > + if (count > 0) { > > + printf("Filesystem does have 64bit inodes\n"); > > + return 0; > > + } else { > > + printf("Filesystem does not have 64bit inodes\n"); > > + return 0; > > + } > > + } > > + perror("xfsctl(XFS_IOC_FSINUMBERS)"); > > + exitcode = 1; > > + return 0; > > +} > > + > > void > > open_init(void) > > { > > @@ -815,6 +847,12 @@ open_init(void) > > _("get/set preferred extent size (in bytes) for the open file"); > > extsize_cmd.help = extsize_help; > > > > + inodes64_cmd.name = "inodes64"; > > + inodes64_cmd.cfunc = inodes64_f; > > + inodes64_cmd.flags = CMD_NOMAP_OK; > > + inodes64_cmd.oneline = > > + _("Checks if filesyste contais 64bit inodes"); > > "Check if filesystem contains 64bit inodes" > Oh lord.. I completely forgot to fix this, thanks :-) > Still needs a manpage update ;) > Writing it :) > Also is it ok to not have inodes64_cmd.help? (Sorry, on phone right now, can't look, perhaps it's fine) I thought about it too, but not having a .help method is fine, and, it looks that the only options which contains a .help method are those who have arguments to the command itself. So, since inodes64 does not have arguments, a .help is not necessary from what I could figure out. > > Thanks, > Eric > > > > + > > add_command(&open_cmd); > > add_command(&stat_cmd); > > add_command(&close_cmd); > > @@ -822,4 +860,5 @@ open_init(void) > > add_command(&chproj_cmd); > > add_command(&lsproj_cmd); > > add_command(&extsize_cmd); > > + add_command(&inodes64_cmd); > > } > > -- > > 2.4.3 > > > > _______________________________________________ > > xfs mailing list > > xfs@oss.sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- Carlos From david@fromorbit.com Tue Sep 22 02:52:59 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id D770D7F50 for ; Tue, 22 Sep 2015 02:52:58 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 55940AC001 for ; Tue, 22 Sep 2015 00:52:55 -0700 (PDT) X-ASG-Debug-ID: 1442908371-04cb6c6b0663d10001-NocioJ Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id rAXaosqnSBsCHPhc for ; Tue, 22 Sep 2015 00:52:52 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2C6DACGBwFWPOV8LHldgySBPYZZolQBAQEBAQaKdY1ygzACAgEBAoE7TQEBAQEBAQcBAQEBQT+EJAEBAQMBIw8BIxUOBQsIAxgCAgUhAgIPBSUDBxoTiCYHtnyUOQEBCAIBHxmBCYUKhUSFDQeCaYFDBZVljQSBUodWjg2DbYJ0HIFmLDOJbQEBAQ Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail06.adl6.internode.on.net with ESMTP; 22 Sep 2015 17:22:50 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeINd-0007eS-BM; Tue, 22 Sep 2015 17:52:49 +1000 Date: Tue, 22 Sep 2015 17:52:49 +1000 From: Dave Chinner To: Mika Eloranta Cc: xfs@oss.sgi.com Subject: Re: [PATCH] mkfs.xfs: add [-U uuid] option Message-ID: <20150922075249.GI19114@dastard> X-ASG-Orig-Subj: Re: [PATCH] mkfs.xfs: add [-U uuid] option References: <1442855060-38259-1-git-send-email-mel@ohmu.fi> <20150921221839.GC19114@dastard> <2640913C-6C95-4128-9055-B155AECA0206@ohmu.fi> <20150921233627.GE19114@dastard> <5E0C9EC9-8ABE-47CC-BB7F-2BC0A872AEDB@ohmu.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5E0C9EC9-8ABE-47CC-BB7F-2BC0A872AEDB@ohmu.fi> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1442908371 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22778 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 22, 2015 at 09:43:34AM +0300, Mika Eloranta wrote: > On 22 Sep 2015, at 02:36, Dave Chinner wrote: > > > > On Tue, Sep 22, 2015 at 01:56:53AM +0300, Mika Eloranta wrote: > >> On 22 Sep 2015, at 01:18, Dave Chinner > >> wrote: > >>> > >>> On Mon, Sep 21, 2015 at 08:04:20PM +0300, Mika Eloranta wrote: > >>>> The UUID can now be optionally specified during filesystem > >>>> creation. > >>> > >>> Which UUID are you wanting to set - the metadata uuid or the > >>> user visible UUID label? Or both? Can you explain the use case > >>> for this? i.e. I'm trying to work out why Why doesn't mkfs.xfs > >>> + xfs_admin -U doesn't work for you? > >> > >> I want to set the user visible UUID (same as xfs_admin -U/-u). > >> Whether this impacts the "metadata uuid†or not, I do not > >> know, I’m not an expert on the XFS internals, just a user. > > > > Which tells me what I need to know - You are trying to use the UUID > > as a user controlled filesystem label. Funnily enough, we have a > > thing for this already - a user controlled filesystem label: > > > > # mkfs.xfs -L "label" .... > > > > It's 12 characters long, so more than enough for any sort of unique > > identification scheme you want to use for your filesystems. > > xfs_admin enables you to change it after the fact, all major > > filesystems support it and all the infrastructure know about it > > (lsblk, /etc/fstab. /dev/disk/by-label, etc) so using it is no > > different to using UUIDs. Except that, unlike UUIDs, you can make > > fileystem labels human readable. :) > > > > Perhaps you should try using filesystem labels seeing as everything > > you need is already there? > > Labels are great for user-readable identifiers, but UUID is nowadays > pretty much the norm for random-generated identifiers. My use-case > concerns distributed and automated virtual systems, where filesystems > are constantly built and torn down. Sure. Your use case boils down to "we need to replace a randomly generated mkfs UUID with our own randomly generated UUID". Why not just read the randomly generated UUID out of the filesystem and put that in the database? There are many ways ot skin a cat, and I'm trying to understand why you need to skin it in this particular way... :/ > Using the filesystem label to store a truncated version of a UUID is > kind of an option, but I'd really rather use the entire UUID because: > > 1) Identifying an orphan filesystem based on its contents becomes > more straightforward, e.g. if they are already listed in a key-value > store based on their full UUID and prefix lookups are not possible. > > 2) The label is actually rather short for storing a random ID. For > example storing 48 bits from the UUID in the label hex-encoded > would give me a collision already in 20 million fs instances with > >50% probability. A label stores characters, not hex-encoded values. 12 characters, assuming A-Z, a-z, 0-9 is 62^12 possible combinations that can be stored. Indeed, Just 6 characters (half the label) gives you 56 *billion* unique labels. But that's not obvious until you stop thinking about using UUIDs for everything..... [ I'm starting to think the mere mention of "UUID" causes people to lose 20 IQ points instantly. :P ] > I thought adding the option would be a rather straightforward thing, > especially when more problematic "xfs_admin -U" is (was?) already > supported. Bugs are a reality we have to live with. We've fixed them (I think). > Is there technical reason why assigning the UUID is no longer > recommended? The changing of the XFS UUID was added for a very specific use case - allowing writable clones of a filesystem to be mounted so the "nouuid" mount option was unnecessary. You're the first person n 10 years to ask for something new in UUID handling and that is why I'm asking lots of questions.... > The patch only allows optionally using a user-specified UUID > instead of a one generated randomly on the spot within mkfs.xfs, > and I cannot see any harm in that. Sure, there may be no harm, but I'm starting from the position of knowing nothing about why you want the feature or how it will be used so I can't make that judgement just by looking at the code. Think on that for a moment - do you just include random code changes in your code base that you really know nothing about? Or do you ask questions and try to understand why it is needed first? Indeed, would you trust software maintained by someone who doesn't care to make informed decisions about the code base they are responsible for maintaining? Don't get me wrong here - I will take an updated patch from you for this functionality. Both you and Eric have very good points as to why mkfs should allow this, but I need to make sure /I/ understand the bigger picture before committing it... Cheers, Dave. -- Dave Chinner david@fromorbit.com From cmaiolino@redhat.com Tue Sep 22 02:54:38 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 663F47F50 for ; Tue, 22 Sep 2015 02:54:38 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 275EC8F8035 for ; Tue, 22 Sep 2015 00:54:38 -0700 (PDT) X-ASG-Debug-ID: 1442908476-04bdf046286b520001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 1oHzKCQBpSSwkSa9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 00:54:36 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 984DBC0A147A; Tue, 22 Sep 2015 07:54:36 +0000 (UTC) Received: from redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8M7sXwv005478 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2015 03:54:35 -0400 Date: Tue, 22 Sep 2015 09:54:32 +0200 From: Carlos Maiolino To: Dave Chinner Cc: xfs@oss.sgi.com Subject: Re: [PATCH] xfs_io: Implement inodes64 command Message-ID: <20150922075432.GC26699@redhat.com> X-ASG-Orig-Subj: Re: [PATCH] xfs_io: Implement inodes64 command Mail-Followup-To: Dave Chinner , xfs@oss.sgi.com References: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> <20150921220832.GB19114@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150921220832.GB19114@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1442908476 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 22, 2015 at 08:08:32AM +1000, Dave Chinner wrote: > On Mon, Sep 21, 2015 at 10:56:08AM +0200, Carlos Maiolino wrote: > > Implement an easy way to check a filesystem for the existence of 64bit inodes. > > > > Based on XFS_IOC_FSINUMBERS, and starting with a lastip of XFS_MAXINUMBER_32, it > > returns a string saying if there is or there isn't 64bit inodes in the > > filesystem. > > > > Signed-off-by: Carlos Maiolino > > --- > > io/open.c | 39 +++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 39 insertions(+) > > > > diff --git a/io/open.c b/io/open.c > > index ac5a5e0..b25b09d 100644 > > --- a/io/open.c > > +++ b/io/open.c > > @@ -20,6 +20,7 @@ > > #include "input.h" > > #include "init.h" > > #include "io.h" > > +#include "libxfs.h" > > > > #ifndef __O_TMPFILE > > #if defined __alpha__ > > @@ -44,6 +45,7 @@ static cmdinfo_t statfs_cmd; > > static cmdinfo_t chproj_cmd; > > static cmdinfo_t lsproj_cmd; > > static cmdinfo_t extsize_cmd; > > +static cmdinfo_t inodes64_cmd; > > static prid_t prid; > > static long extsize; > > > > @@ -750,6 +752,36 @@ statfs_f( > > return 0; > > } > > > > +static int > > +inodes64_f( > > + int argc, > > + char **argv) > > +{ > > + int i; > > + __s32 count; > > + __u64 last = XFS_MAXINUMBER_32; > > + xfs_inogrp_t igroup; > > + xfs_fsop_bulkreq_t bulkreq; > > Please don't use typedefs. > Ok. > > + > > + bulkreq.lastip = &last; > > + bulkreq.icount = 1; > > + bulkreq.ubuffer = &igroup; > > + bulkreq.ocount = &count; > > + > > + if (!xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { > > + if (count > 0) { > > + printf("Filesystem does have 64bit inodes\n"); > > + return 0; > > + } else { > > + printf("Filesystem does not have 64bit inodes\n"); > > + return 0; > > + } > > + } > > + perror("xfsctl(XFS_IOC_FSINUMBERS)"); > > I'd do this the other way around: > > if (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { > perror("XFS_IOC_FSINUMBERS"); > exitcode = 1; > return 0; > } > > if (count > 0) > printf("Filesystem does have 64bit inodes\n"); > else > printf("Filesystem does not have 64bit inodes\n"); > return 0; > > is sufficient, xfsctl is a one line wrapper around ioctl(). > Ok, I'll change this, but, just a matter of curiosity, what are the technical reasons to write the conditional this way, instead of the way I wrote first? Just to avoid entering the conditional? > > @@ -815,6 +847,12 @@ open_init(void) > > _("get/set preferred extent size (in bytes) for the open file"); > > extsize_cmd.help = extsize_help; > > > > + inodes64_cmd.name = "inodes64"; > > + inodes64_cmd.cfunc = inodes64_f; > > + inodes64_cmd.flags = CMD_NOMAP_OK; > > + inodes64_cmd.oneline = > > + _("Checks if filesyste contais 64bit inodes"); > ^^^ ^^ 64 bit > > "inodes64" could be improved as a command name. e.g: > > oneline = _("Query inode number usage in the filesystem") > > And could do a little more to help users work out what the > problematic inode is. e.g: > > Long help: > > Inode_numbers [-s|-l] [num] > > [-s] returns the physical size of the largest inode > number in the filesystem (32 bit of 64 bit) > [-l] returns the largest inode number in the filesystem > [-n] returns the next inode number after [num] > [num] returns whether the inode number exists > > i.e. if you want 32 bit inodes in the fs, you can use [-n num] to > iterate all the inode numbers above 32 bits in size... > Ok, np > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- Carlos From penguin-kernel@I-love.SAKURA.ne.jp Tue Sep 22 03:04:12 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 67EBE7F37 for ; Tue, 22 Sep 2015 03:04:12 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 39883304039 for ; Tue, 22 Sep 2015 01:04:08 -0700 (PDT) X-ASG-Debug-ID: 1442909045-04bdf046286b7b0001-NocioJ Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by cuda.sgi.com with ESMTP id uc1yt6Gw9YagbB7m (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 22 Sep 2015 01:04:06 -0700 (PDT) X-Barracuda-Envelope-From: penguin-kernel@I-love.SAKURA.ne.jp X-Barracuda-Apparent-Source-IP: 202.181.97.72 Received: from fsav104.sakura.ne.jp (fsav104.sakura.ne.jp [27.133.134.231]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8M83vTR067866; Tue, 22 Sep 2015 17:03:57 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav104.sakura.ne.jp (F-Secure/fsigk_smtp/522/fsav104.sakura.ne.jp); Tue, 22 Sep 2015 17:03:57 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/522/fsav104.sakura.ne.jp) Received: from ccsecurity.localdomain (softbank126074231104.bbtec.net [126.74.231.104]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8M83oUu067803 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Sep 2015 17:03:57 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) From: Tetsuo Handa To: david@fromorbit.com Cc: xfs@oss.sgi.com, linux-mm@kvack.org, Tetsuo Handa , Michal Hocko Subject: [PATCH v3] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks Date: Tue, 22 Sep 2015 17:03:43 +0900 X-ASG-Orig-Subj: [PATCH v3] xfs: Print comm name and pid when open-coded __GFP_NOFAIL allocation stucks Message-Id: <1442909023-4088-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <20150922051253.GB3902@dastard> References: <20150922051253.GB3902@dastard> X-Barracuda-Connect: www262.sakura.ne.jp[202.181.97.72] X-Barracuda-Start-Time: 1442909046 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22778 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header This patch adds comm name and pid to warning messages printed by kmem_alloc(), kmem_zone_alloc() and xfs_buf_allocate_memory(). This will help telling which memory allocations (e.g. kernel worker threads, OOM victim tasks, neither) are stalling because these functions are passing __GFP_NOWARN which suppresses not only backtrace but comm name and pid. [ 66.089978] Kill process 8505 (a.out) sharing same memory [ 69.748060] XFS: a.out(8082) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 69.798580] XFS: kworker/u16:28(381) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 69.876952] XFS: xfs-data/sda1(399) possible memory allocation deadlock in kmem_alloc (mode:0x8250) [ 70.359518] XFS: a.out(8412) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 73.299509] XFS: kworker/u16:28(381) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 73.470350] XFS: xfs-data/sda1(399) possible memory allocation deadlock in kmem_alloc (mode:0x8250) [ 73.664420] XFS: a.out(8082) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 73.967434] XFS: a.out(8412) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 76.950038] XFS: kworker/u16:28(381) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 76.957938] XFS: xfs-data/sda1(399) possible memory allocation deadlock in kmem_alloc (mode:0x8250) (Strictly speaking, we want task_lock()/task_unlock() when reading comm name.) Signed-off-by: Tetsuo Handa Cc: Michal Hocko --- fs/xfs/kmem.c | 10 ++++++---- fs/xfs/xfs_buf.c | 3 ++- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c index a7a3a63..535c136 100644 --- a/fs/xfs/kmem.c +++ b/fs/xfs/kmem.c @@ -55,8 +55,9 @@ kmem_alloc(size_t size, xfs_km_flags_t flags) return ptr; if (!(++retries % 100)) xfs_err(NULL, - "possible memory allocation deadlock in %s (mode:0x%x)", - __func__, lflags); + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, + __func__, lflags); congestion_wait(BLK_RW_ASYNC, HZ/50); } while (1); } @@ -120,8 +121,9 @@ kmem_zone_alloc(kmem_zone_t *zone, xfs_km_flags_t flags) return ptr; if (!(++retries % 100)) xfs_err(NULL, - "possible memory allocation deadlock in %s (mode:0x%x)", - __func__, lflags); + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, + __func__, lflags); congestion_wait(BLK_RW_ASYNC, HZ/50); } while (1); } diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index 8ecffb3..cac62e1 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -354,7 +354,8 @@ retry: */ if (!(++retries % 100)) xfs_err(NULL, - "possible memory allocation deadlock in %s (mode:0x%x)", + "%s(%u) possible memory allocation deadlock in %s (mode:0x%x)", + current->comm, current->pid, __func__, gfp_mask); XFS_STATS_INC(xb_page_retries); -- 1.8.3.1 From mika.eloranta@ohmu.fi Tue Sep 22 03:06:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id B5E587F37 for ; Tue, 22 Sep 2015 03:06:43 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id A52DB8F8033 for ; Tue, 22 Sep 2015 01:06:40 -0700 (PDT) X-ASG-Debug-ID: 1442909198-04cb6c6b07640e0001-NocioJ Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by cuda.sgi.com with ESMTP id XBRG9lfFOkLsAX1G (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 01:06:38 -0700 (PDT) X-Barracuda-Envelope-From: mika.eloranta@ohmu.fi X-Barracuda-Apparent-Source-IP: 66.111.4.25 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CA7992101E for ; Tue, 22 Sep 2015 04:06:37 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 22 Sep 2015 04:06:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=J7mSAriI7IJDrQd oKttVhEnph4E=; b=WfgIVdJ0ASD1UAbDAArhdowfs1eQdl1zsDfKE4M/aUKon3e TmmyUBdYqxca4hpqW5dHfxCP5O31aKjZ3Jqqueh2ckCeUXeI/MVMlzYFYZHodUnG VpAdbLUwgKNplcT1T1dpmts+OAG/ziH66Gu/C9OS9L4/aakhuFEgrD+8cRJc= X-Sasl-enc: JUNplOwLcECBHa5bNeN/k0hDZFU/lq7tFYHFLpsani6l 1442909197 Received: from [192.168.43.240] (37-219-227-24.nat.bb.dnainternet.fi [37.219.227.24]) by mail.messagingengine.com (Postfix) with ESMTPA id E43C9C00016; Tue, 22 Sep 2015 04:06:36 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [PATCH] mkfs.xfs: add [-U uuid] option From: Mika Eloranta X-ASG-Orig-Subj: Re: [PATCH] mkfs.xfs: add [-U uuid] option In-Reply-To: <20150922075249.GI19114@dastard> Date: Tue, 22 Sep 2015 11:06:35 +0300 Cc: xfs@oss.sgi.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <1442855060-38259-1-git-send-email-mel@ohmu.fi> <20150921221839.GC19114@dastard> <2640913C-6C95-4128-9055-B155AECA0206@ohmu.fi> <20150921233627.GE19114@dastard> <5E0C9EC9-8ABE-47CC-BB7F-2BC0A872AEDB@ohmu.fi> <20150922075249.GI19114@dastard> To: Dave Chinner X-Mailer: Apple Mail (2.2104) X-Barracuda-Connect: out1-smtp.messagingengine.com[66.111.4.25] X-Barracuda-Start-Time: 1442909198 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22778 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 > On 22 Sep 2015, at 10:52, Dave Chinner wrote: >=20 > On Tue, Sep 22, 2015 at 09:43:34AM +0300, Mika Eloranta wrote: >> On 22 Sep 2015, at 02:36, Dave Chinner wrote: >>>=20 >>> On Tue, Sep 22, 2015 at 01:56:53AM +0300, Mika Eloranta wrote: >>>> On 22 Sep 2015, at 01:18, Dave Chinner >>>> wrote: >>>>>=20 >>>>> On Mon, Sep 21, 2015 at 08:04:20PM +0300, Mika Eloranta wrote: >>>>>> The UUID can now be optionally specified during filesystem >>>>>> creation. >>>>>=20 >>>>> Which UUID are you wanting to set - the metadata uuid or the >>>>> user visible UUID label? Or both? Can you explain the use case >>>>> for this? i.e. I'm trying to work out why Why doesn't mkfs.xfs >>>>> + xfs_admin -U doesn't work for you? >>>>=20 >>>> I want to set the user visible UUID (same as xfs_admin -U/-u). >>>> Whether this impacts the "metadata uuid=E2=80=9D or not, I do not >>>> know, I=E2=80=99m not an expert on the XFS internals, just a user. >>>=20 >>> Which tells me what I need to know - You are trying to use the UUID >>> as a user controlled filesystem label. Funnily enough, we have a >>> thing for this already - a user controlled filesystem label: >>>=20 >>> # mkfs.xfs -L "label" .... >>>=20 >>> It's 12 characters long, so more than enough for any sort of unique >>> identification scheme you want to use for your filesystems. >>> xfs_admin enables you to change it after the fact, all major >>> filesystems support it and all the infrastructure know about it >>> (lsblk, /etc/fstab. /dev/disk/by-label, etc) so using it is no >>> different to using UUIDs. Except that, unlike UUIDs, you can make >>> fileystem labels human readable. :) >>>=20 >>> Perhaps you should try using filesystem labels seeing as everything >>> you need is already there? >>=20 >> Labels are great for user-readable identifiers, but UUID is nowadays >> pretty much the norm for random-generated identifiers. My use-case >> concerns distributed and automated virtual systems, where filesystems >> are constantly built and torn down. >=20 > Sure. Your use case boils down to "we need to replace a randomly > generated mkfs UUID with our own randomly generated UUID". Why not > just read the randomly generated UUID out of the filesystem and put > that in the database? >=20 > There are many ways ot skin a cat, and I'm trying to understand why > you need to skin it in this particular way... :/ >=20 >> Using the filesystem label to store a truncated version of a UUID is >> kind of an option, but I'd really rather use the entire UUID because: >>=20 >> 1) Identifying an orphan filesystem based on its contents becomes >> more straightforward, e.g. if they are already listed in a = key-value >> store based on their full UUID and prefix lookups are not possible. >>=20 >> 2) The label is actually rather short for storing a random ID. For >> example storing 48 bits from the UUID in the label hex-encoded >> would give me a collision already in 20 million fs instances with >>> 50% probability. >=20 > A label stores characters, not hex-encoded values. 12 characters, > assuming A-Z, a-z, 0-9 is 62^12 possible combinations that can be > stored. Indeed, Just 6 characters (half the label) gives you 56 > *billion* unique labels. But that's not obvious until you stop > thinking about using UUIDs for everything=E2=80=A6.. You are absolutely correct. However, when I have a UUID in my hand and there is a slot called =E2=80=9CUUID" and it is user-settable and it = fits my ID perfectly, to me it is rather natural to use it instead of trying to invent new = encoding schemes for storing a part of it. > [ I'm starting to think the mere mention of "UUID" causes people to > lose 20 IQ points instantly. :P ] No comments about this one. >> I thought adding the option would be a rather straightforward thing, >> especially when more problematic "xfs_admin -U" is (was?) already >> supported. >=20 > Bugs are a reality we have to live with. We've fixed them (I think). And I thank you guys for that. Never had a showstopper with XFS. Unlike with some other, krmh, unnamed options... >> Is there technical reason why assigning the UUID is no longer >> recommended? >=20 > The changing of the XFS UUID was added for a very specific use case > - allowing writable clones of a filesystem to be mounted so the > "nouuid" mount option was unnecessary. You're the first person n > 10 years to ask for something new in UUID handling and that is why > I'm asking lots of questions.... >=20 >> The patch only allows optionally using a user-specified UUID >> instead of a one generated randomly on the spot within mkfs.xfs, >> and I cannot see any harm in that. >=20 > Sure, there may be no harm, but I'm starting from the position of > knowing nothing about why you want the feature or how it will be > used so I can't make that judgement just by looking at the code. >=20 > Think on that for a moment - do you just include random code changes > in your code base that you really know nothing about? Or do you ask > questions and try to understand why it is needed first? Indeed, > would you trust software maintained by someone who doesn't care to > make informed decisions about the code base they are responsible > for maintaining? >=20 > Don't get me wrong here - I will take an updated patch from you for > this functionality. Both you and Eric have very good points as to > why mkfs should allow this, but I need to make sure /I/ understand > the bigger picture before committing it=E2=80=A6 Lesson learned. Coming from my problem domain the feature seemed obvious, but I can see the need for being more verbose about the = =E2=80=9Cwhy?=E2=80=9D part. I did not realize this feature is not so commonly used. Regarding updating the patch: =E2=80=9C-U uuid=E2=80=9D = (mkfs.ext*/mkfs.btrfs -style) or "-m uuid=3D=E2=80=9D as per proposal by Carlos? I=E2=80=99ll also try to summarize a better commit message. Cheers, - Mika From david@fromorbit.com Tue Sep 22 03:07:34 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 121EB7F37 for ; Tue, 22 Sep 2015 03:07:34 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 91828AC004 for ; Tue, 22 Sep 2015 01:07:30 -0700 (PDT) X-ASG-Debug-ID: 1442909247-04cb6c6b0464100001-NocioJ Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id 1k92xmPP6FvYaBXW for ; Tue, 22 Sep 2015 01:07:27 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BRCgA9CwFWPOV8LHlVCIMkgT2GWaJUAQEBAQEGinWRIgICAQECgTpNAQEBAQEBBwEBAQFBP4QlAQEEJxMcIxAIAw4KCSUPBSUDBxoTiC3LMgEBAQEBBQEBAQEeGYYThUSENAJXB4MYgRQFlWWNBIFShDWDIZF6gnQcgWYsM4glAh4HgSEBAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail06.adl6.internode.on.net with ESMTP; 22 Sep 2015 17:37:27 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeIbm-0007gk-0O; Tue, 22 Sep 2015 18:07:26 +1000 Date: Tue, 22 Sep 2015 18:07:25 +1000 From: Dave Chinner To: Brian Foster Cc: xfs@oss.sgi.com Subject: Re: [RFC v2 2/2] xfs: validate metadata LSNs against log on v5 superblocks Message-ID: <20150922080725.GC3902@dastard> X-ASG-Orig-Subj: Re: [RFC v2 2/2] xfs: validate metadata LSNs against log on v5 superblocks References: <1441997635-36644-1-git-send-email-bfoster@redhat.com> <1441997635-36644-3-git-send-email-bfoster@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441997635-36644-3-git-send-email-bfoster@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1442909247 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22778 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Fri, Sep 11, 2015 at 02:53:55PM -0400, Brian Foster wrote: > Since the onset of v5 superblocks, the LSN of the last modification has > been included in a variety of on-disk data structures. This LSN is used > to provide log recovery ordering guarantees (e.g., to ensure an older > log recovery item is not replayed over a newer target data structure). > > While this works correctly from the point a filesystem is formatted and > mounted, userspace tools have some problematic behaviors that defeat > this mechanism. For example, xfs_repair historically zeroes out the log > unconditionally (regardless of whether corruption is detected). If this > occurs, the LSN of the filesystem is reset and the log is now in a > problematic state with respect to on-disk metadata structures that might > have a larger LSN. Until either the log catches up to the highest > previously used metadata LSN or each affected data structure is modified > and written out without incident (which resets the metadata LSN), log > recovery is susceptible to filesystem corruption. > > This problem is ultimately addressed and repaired in the associated > userspace tools. The kernel is still responsible to detect the problem > and notify the user that something is wrong. Check the superblock LSN at > mount time and notify the user and fail the mount if it is invalid. > From that point on, simply warn the user if an invalid metadata LSN is > detected from the various metadata I/O verifiers. A new xfs_mount flag > is added to guarantee that a warning fires at least once for each > affected filesystem mount. From that point forward, further instances of > the problem are rate limited to a once per 24 hour period. > > Signed-off-by: Brian Foster > --- > fs/xfs/libxfs/xfs_alloc.c | 9 +++++-- > fs/xfs/libxfs/xfs_attr_leaf.c | 2 ++ > fs/xfs/libxfs/xfs_btree.c | 14 +++++++++-- > fs/xfs/libxfs/xfs_da_btree.c | 3 +++ > fs/xfs/libxfs/xfs_dir2_block.c | 1 + > fs/xfs/libxfs/xfs_dir2_data.c | 1 + > fs/xfs/libxfs/xfs_dir2_leaf.c | 1 + > fs/xfs/libxfs/xfs_dir2_node.c | 1 + > fs/xfs/libxfs/xfs_ialloc.c | 8 +++++-- > fs/xfs/libxfs/xfs_sb.c | 8 +++++++ > fs/xfs/libxfs/xfs_symlink_remote.c | 3 +++ > fs/xfs/xfs_log.c | 1 - > fs/xfs/xfs_log_priv.h | 24 +++++++++++++++++++ > fs/xfs/xfs_log_recover.c | 15 +++++++++++- > fs/xfs/xfs_mount.c | 49 ++++++++++++++++++++++++++++++++++++++ > fs/xfs/xfs_mount.h | 3 +++ > 16 files changed, 135 insertions(+), 8 deletions(-) > > diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c > index ffad7f2..cb26016 100644 > --- a/fs/xfs/libxfs/xfs_alloc.c > +++ b/fs/xfs/libxfs/xfs_alloc.c > @@ -482,6 +482,8 @@ xfs_agfl_verify( > be32_to_cpu(agfl->agfl_bno[i]) >= mp->m_sb.sb_agblocks) > return false; > } > + > + xfs_detect_invalid_lsn(mp, be64_to_cpu(XFS_BUF_TO_AGFL(bp)->agfl_lsn)); > return true; xfs_log_check_lsn(mp, ); > +/* > + * The LSN is valid so long as it is behind the current LSN. If it isn't, this > + * means that the next log record that includes this metadata could have a > + * smaller LSN. In turn, this means that the modification in the log would not > + * replay. > + */ > +static inline bool > +xlog_valid_lsn( > + struct xlog *log, > + xfs_lsn_t lsn) > +{ > + int cycle = CYCLE_LSN(lsn); > + int block = BLOCK_LSN(lsn); > + bool valid = true; > + > + spin_lock(&log->l_icloglock); > + if ((cycle > log->l_curr_cycle) || > + (cycle == log->l_curr_cycle && block > log->l_curr_block)) > + valid = false; > + spin_unlock(&log->l_icloglock); > + > + return valid; > +} We do not want to take the l_icloglock in metadata IO context. It's a global fs lock, and it's a hot lock, too, so we do not want to be taking this during every metadata IO completion. I think, at minimum, we need to sample the current values and do an unlocked check, then if the result is suspect we need to do an accurate locked check. This means that we will almost never take the l_icloglock here. e.g: { int cycle = ACCESS_ONCE(log->l_curr_cycle); int block = ACCESS_ONCE(log->l_curr_block); if (CYCLE_LSN(lsn) > cycle || (CYCLE_LSN(lsn) == cycle && BLOCK_LSN(lsn) > block)) { /* suspect, take icloglock to check again */ bool valid = true; .... return valid; } return true; } > --- a/fs/xfs/xfs_mount.c > +++ b/fs/xfs/xfs_mount.c > @@ -41,6 +41,7 @@ > #include "xfs_trace.h" > #include "xfs_icache.h" > #include "xfs_sysfs.h" > +#include "xfs_log_priv.h" > > > static DEFINE_MUTEX(xfs_uuid_table_mutex); > @@ -1301,3 +1302,51 @@ xfs_dev_is_read_only( > } > return 0; > } > + > +/* > + * Verify that an LSN stamped into a piece of metadata is valid. This is > + * intended for use in read verifiers on v5 superblocks. > + */ > +void > +xfs_detect_invalid_lsn( > + struct xfs_mount *mp, > + xfs_lsn_t lsn) > +{ This shoul dbe called xfs_log_check_lsn() and be located in xfs_log.c. > + struct xlog *log = mp->m_log; > + int cycle = CYCLE_LSN(lsn); > + int block = BLOCK_LSN(lsn); > + const char *fmt; > + > + /* > + * 'norecovery' mode skips mount-time log processing and unconditionally > + * resets the LSN. > + */ > + if (mp->m_flags & XFS_MOUNT_NORECOVERY) > + return; > + > + if (xlog_valid_lsn(mp->m_log, lsn)) > + return; > + > + /* > + * Warn at least once for each filesystem susceptible to this problem > + * and once per day thereafter. > + * > + * XXX: Specify the minimum xfs_repair version required to resolve? > + * Older versions will silently reintroduce the problem. > + * > + * We should eventually convert this condition into a hard error (via > + * verifier failure). Defer that behavior for a few release cycles or so > + * until the userspace fixes have had the opportunity to propogate > + * throughout the various distributions. > + */ > + fmt = "WARNING: Metadata has LSN (%d:%d) ahead of current LSN (%d:%d). " > +"This may result in filesystem failure. Please unmount and run xfs_repair to resolve."; > + if (!mp->m_warned_bad_lsn) { > + mp->m_warned_bad_lsn = true; > + xfs_warn(mp, fmt, cycle, block, log->l_curr_cycle, > + log->l_curr_block); > + } else { > + xfs_warn_daily(mp, fmt, cycle, block, log->l_curr_cycle, > + log->l_curr_block); > + } That's really ugly. Rate limited prints should always occur at least once for each ratelimit key, and now i've seen this I can say the first patch needs rework. that is, each xfs_warn_daily() caller needs it's own ratelimit key, rather than sharing the global ratelimit key that all other XFS messages share. e.g.: xfs_warn_daily(mp, mp->m_log->l_lsn_rlstate, "Corruption warning: Metadata has LSN (%d:%d) ahead of current LSN (%d:%d). " "Please unmount and run xfs_repair (>= v4.3) to resolve.". cycle, block, log->l_curr_cycle, log->l_curr_block); But really, thinking on this further (the "corruption warning" bit) I'm starting to think we should just shut the filesystem down when we hit this and force the user to fix it immediately. if we don't, then who knows whether we are making things worse or not... > --- a/fs/xfs/xfs_mount.h > +++ b/fs/xfs/xfs_mount.h > @@ -127,6 +127,7 @@ typedef struct xfs_mount { > int64_t m_low_space[XFS_LOWSP_MAX]; > /* low free space thresholds */ > struct xfs_kobj m_kobj; > + bool m_warned_bad_lsn;/* bad metadata lsn detected */ That's where I'd put the ratelimit key (or in the struct xlog). Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Tue Sep 22 03:25:14 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 5247E7F37 for ; Tue, 22 Sep 2015 03:25:14 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3DE0C8F8033 for ; Tue, 22 Sep 2015 01:25:14 -0700 (PDT) X-ASG-Debug-ID: 1442910311-04cbb033b372450001-NocioJ Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id wHPUE4x3tlgsdoQM for ; Tue, 22 Sep 2015 01:25:11 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BTCgD6DwFWPOV8LHldgySBPYZZolUBAQEBAQaKdZEiAgIBAQKBPE0BAQEBAQEHAQEBAUE/hCQBAQEDASMPASMVDgULCAMYAgIFIQICDwUlAwcaE4gmB7Z3lDUBAQEBBgIBHxmBCYUKhUSFDQeCaS+BFAWVZY0EgVKENZUbgnQcgWYsM4ltAQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail06.adl6.internode.on.net with ESMTP; 22 Sep 2015 17:55:10 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeIsv-0007iU-V0; Tue, 22 Sep 2015 18:25:10 +1000 Date: Tue, 22 Sep 2015 18:25:09 +1000 From: Dave Chinner To: Mika Eloranta Cc: xfs@oss.sgi.com Subject: Re: [PATCH] mkfs.xfs: add [-U uuid] option Message-ID: <20150922082509.GD3902@dastard> X-ASG-Orig-Subj: Re: [PATCH] mkfs.xfs: add [-U uuid] option References: <1442855060-38259-1-git-send-email-mel@ohmu.fi> <20150921221839.GC19114@dastard> <2640913C-6C95-4128-9055-B155AECA0206@ohmu.fi> <20150921233627.GE19114@dastard> <5E0C9EC9-8ABE-47CC-BB7F-2BC0A872AEDB@ohmu.fi> <20150922075249.GI19114@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1442910311 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22779 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 22, 2015 at 11:06:35AM +0300, Mika Eloranta wrote: > > On 22 Sep 2015, at 10:52, Dave Chinner wrote: > > Don't get me wrong here - I will take an updated patch from you for > > this functionality. Both you and Eric have very good points as to > > why mkfs should allow this, but I need to make sure /I/ understand > > the bigger picture before committing it… > > Lesson learned. Coming from my problem domain the feature seemed > obvious, but I can see the need for being more verbose about the “why?†> part. I did not realize this feature is not so commonly used. The usual problem - we're all subject matter experts in our own domains, and what is obvious to us isn't obvious to someone in a slightly different domain, even though they interact at some level. > Regarding updating the patch: “-U uuid†(mkfs.ext*/mkfs.btrfs -style) or > "-m uuid=†as per proposal by Carlos? -m uuid=, please. Cheers, Dave. -- Dave Chinner david@fromorbit.com From billodo@redhat.com Tue Sep 22 07:08:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id BA9587F37 for ; Tue, 22 Sep 2015 07:08:05 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 90F8C8F8037 for ; Tue, 22 Sep 2015 05:08:05 -0700 (PDT) X-ASG-Debug-ID: 1442923682-04bdf04622715f0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Nz8C1lSXtaf1AsWG (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 05:08:03 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 8531CA2A1A for ; Tue, 22 Sep 2015 12:08:02 +0000 (UTC) Received: from localhost.localdomain.com (vpn-53-129.rdu2.redhat.com [10.10.53.129]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MC81nf022782 for ; Tue, 22 Sep 2015 08:08:02 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 0/5 v7] xfs: stats in sysfs Date: Tue, 22 Sep 2015 07:07:46 -0500 X-ASG-Orig-Subj: [PATCH 0/5 v7] xfs: stats in sysfs Message-Id: <1442923671-14125-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442923683 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at sgi.com Hello- Following is the next iteration of the series to add xfs stats to sysfs. This iteration adds patch 5/5 to incorporate sysfs/kobject into xfsstats. ----------history--------------- v7: -add patch 5/5: incorporate sysfs/kobject in xfsstats: handlers take kobjects. Allocate & deallocate per-fs stats structures and set up the sysfs entries for them. Add kobject and a pointer to a per-cpu struct xfsstats. Modify the macros that manipulate the stats accordingly. v6: -add patch 4/4: move to_xlog(kobject) to the relevant show/store operations. This keeps the xfs_sysfs_object_show/store functions generic. Also, with the change, there can be some cleanup of the show/store function arguments. v5: -optimization of sysfs_ops function. -style fixups v4: -whitespace fixup of patch 1 -add patch 4 (sysfs ops consolidation - dbg, stats, log) v3: -style fixups and removal of extraneous printk. v2: -style fixups. v1: -------------------------------- The series provides infrastructure for per-fs stats (in addition to global accumulative stats). We already have per-fs information in /sys, so it makes sense to have per-fs stats there too. As a first step, moving existing global stats infrastructure to /sys will allow us to re-use that sysfs code for per-fs stats as well. Patch 1 handles the bring-up and tear down of xfs/stats directory structure in sysfs when an fs is mounted. The directory contains the stats file and the stats_clear file. The stats file contents mimic those of /proc/fs/xfs/stat. The stats_clear file is empty, and much like the current stat_clear command, handles the zeroing of the stats file when a "1" is echoed to the stats_clear file. Patch 2 creates the symlink for stats from procfs to sysfs. Patch 3 removes the now unused portions of procfs for stat. Patch 4 consolidates the sysfs ops for dbg, stats, log. Patch 5 allocates and deallocates per-fs stats structures and sets up the sysfs entries for them. Add kobject and a pointer to a per-cpu struct xfsstats. Modify the macros that manipulate the stats accordingly. Again, comments and questions are welcome. Thanks- Bill From billodo@redhat.com Tue Sep 22 07:08:07 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 579017F50 for ; Tue, 22 Sep 2015 07:08:07 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 37238304048 for ; Tue, 22 Sep 2015 05:08:07 -0700 (PDT) X-ASG-Debug-ID: 1442923684-04cb6c6b0669690001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Tqi5bcXXEs72zA96 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 05:08:05 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 8157BC0A1469 for ; Tue, 22 Sep 2015 12:08:04 +0000 (UTC) Received: from localhost.localdomain.com (vpn-53-129.rdu2.redhat.com [10.10.53.129]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MC81nj022782 for ; Tue, 22 Sep 2015 08:08:04 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 4/5] xfs: consolidate sysfs ops (dbg, stats, log) Date: Tue, 22 Sep 2015 07:07:50 -0500 X-ASG-Orig-Subj: [PATCH 4/5] xfs: consolidate sysfs ops (dbg, stats, log) Message-Id: <1442923671-14125-5-git-send-email-billodo@redhat.com> In-Reply-To: <1442923671-14125-1-git-send-email-billodo@redhat.com> References: <1442923671-14125-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442923684 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the series to move xfs global stats from procfs to sysfs, this patch consolidates the sysfs ops functions and removes redundancy. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 2 +- fs/xfs/xfs_sysfs.c | 182 +++++++++++++++++++---------------------------------- 2 files changed, 64 insertions(+), 120 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 05d5227..dc6ca67 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -92,7 +92,7 @@ int xfs_stats_format(char *buf) 0); #endif -return len; + return len; } void xfs_stats_clearall(void) diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index a094e20..ab4850b 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -25,8 +25,9 @@ struct xfs_sysfs_attr { struct attribute attr; - ssize_t (*show)(char *buf, void *data); - ssize_t (*store)(const char *buf, size_t count, void *data); + ssize_t (*show)(struct kobject *kobject, char *buf); + ssize_t (*store)(struct kobject *kobject, const char *buf, + size_t count); }; static inline struct xfs_sysfs_attr * @@ -54,14 +55,42 @@ struct kobj_type xfs_mp_ktype = { .release = xfs_sysfs_release, }; +STATIC ssize_t +xfs_sysfs_object_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->show ? xfs_attr->show(kobject, buf) : 0; +} + +STATIC ssize_t +xfs_sysfs_object_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->store ? xfs_attr->store(kobject, buf, count) : 0; +} + +static const struct sysfs_ops xfs_sysfs_ops = { + .show = xfs_sysfs_object_show, + .store = xfs_sysfs_object_store, +}; + #ifdef DEBUG /* debug */ STATIC ssize_t log_recovery_delay_store( + struct kobject *kobject, const char *buf, - size_t count, - void *data) + size_t count) { int ret; int val; @@ -80,8 +109,8 @@ log_recovery_delay_store( STATIC ssize_t log_recovery_delay_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { return snprintf(buf, PAGE_SIZE, "%d\n", xfs_globals.log_recovery_delay); } @@ -92,49 +121,20 @@ static struct attribute *xfs_dbg_attrs[] = { NULL, }; -STATIC ssize_t -xfs_dbg_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; -} - -STATIC ssize_t -xfs_dbg_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; -} - -static struct sysfs_ops xfs_dbg_ops = { - .show = xfs_dbg_show, - .store = xfs_dbg_store, -}; - struct kobj_type xfs_dbg_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_dbg_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_dbg_attrs, }; #endif /* DEBUG */ - /* stats */ STATIC ssize_t stats_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { return xfs_stats_format(buf); } @@ -142,9 +142,9 @@ XFS_SYSFS_ATTR_RO(stats); STATIC ssize_t stats_clear_store( + struct kobject *kobject, const char *buf, - size_t count, - void *data) + size_t count) { int ret; int val; @@ -166,50 +166,30 @@ static struct attribute *xfs_stats_attrs[] = { NULL, }; -STATIC ssize_t -xfs_stats_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; -} - -STATIC ssize_t -xfs_stats_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; -} - -static struct sysfs_ops xfs_stats_ops = { - .show = xfs_stats_show, - .store = xfs_stats_store, -}; - struct kobj_type xfs_stats_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_stats_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_stats_attrs, }; /* xlog */ +static inline struct xlog * +to_xlog(struct kobject *kobject) +{ + struct xfs_kobj *kobj = to_kobj(kobject); + + return container_of(kobj, struct xlog, l_kobj); +} + STATIC ssize_t log_head_lsn_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { - struct xlog *log = data; int cycle; int block; + struct xlog *log = to_xlog(kobject); spin_lock(&log->l_icloglock); cycle = log->l_curr_cycle; @@ -222,12 +202,12 @@ XFS_SYSFS_ATTR_RO(log_head_lsn); STATIC ssize_t log_tail_lsn_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { - struct xlog *log = data; int cycle; int block; + struct xlog *log = to_xlog(kobject); xlog_crack_atomic_lsn(&log->l_tail_lsn, &cycle, &block); return snprintf(buf, PAGE_SIZE, "%d:%d\n", cycle, block); @@ -236,12 +216,13 @@ XFS_SYSFS_ATTR_RO(log_tail_lsn); STATIC ssize_t reserve_grant_head_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) + { - struct xlog *log = data; int cycle; int bytes; + struct xlog *log = to_xlog(kobject); xlog_crack_grant_head(&log->l_reserve_head.grant, &cycle, &bytes); return snprintf(buf, PAGE_SIZE, "%d:%d\n", cycle, bytes); @@ -250,12 +231,12 @@ XFS_SYSFS_ATTR_RO(reserve_grant_head); STATIC ssize_t write_grant_head_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { - struct xlog *log = data; int cycle; int bytes; + struct xlog *log = to_xlog(kobject); xlog_crack_grant_head(&log->l_write_head.grant, &cycle, &bytes); return snprintf(buf, PAGE_SIZE, "%d:%d\n", cycle, bytes); @@ -270,45 +251,8 @@ static struct attribute *xfs_log_attrs[] = { NULL, }; -static inline struct xlog * -to_xlog(struct kobject *kobject) -{ - struct xfs_kobj *kobj = to_kobj(kobject); - return container_of(kobj, struct xlog, l_kobj); -} - -STATIC ssize_t -xfs_log_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xlog *log = to_xlog(kobject); - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, log) : 0; -} - -STATIC ssize_t -xfs_log_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xlog *log = to_xlog(kobject); - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, log) : 0; -} - -static struct sysfs_ops xfs_log_ops = { - .show = xfs_log_show, - .store = xfs_log_store, -}; - struct kobj_type xfs_log_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_log_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_log_attrs, }; -- 2.4.3 From billodo@redhat.com Tue Sep 22 07:08:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 43BFE7F50 for ; Tue, 22 Sep 2015 07:08:08 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 34EDB304039 for ; Tue, 22 Sep 2015 05:08:08 -0700 (PDT) X-ASG-Debug-ID: 1442923685-04cb6c6b0569690001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id MhBervSWVPE35PEs (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 05:08:05 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 0B2BFA8D for ; Tue, 22 Sep 2015 12:08:05 +0000 (UTC) Received: from localhost.localdomain.com (vpn-53-129.rdu2.redhat.com [10.10.53.129]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MC81nk022782 for ; Tue, 22 Sep 2015 08:08:04 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 5/5] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. Date: Tue, 22 Sep 2015 07:07:51 -0500 X-ASG-Orig-Subj: [PATCH 5/5] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. Message-Id: <1442923671-14125-6-git-send-email-billodo@redhat.com> In-Reply-To: <1442923671-14125-1-git-send-email-billodo@redhat.com> References: <1442923671-14125-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442923685 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 This patch is the next step toward per-fs xfs stats. Allocate & deallocate per-fs stats structures and set up the sysfs entries for them. Instead of a single global xfsstats structure, add kobject and a pointer to a per-cpu struct xfsstats. Modify the macros that manipulate the stats accordingly: XFS_STATS_INC, XFS_STATS_DEC, and XFS_STATS_ADD now access xfsstats->xs_stats. The sysfs functions need to get from the kobject back to the xfsstats structure which contains it, and pass the pointer to the ->xs_stats percpu structure into the show & clear routines. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_linux.h | 7 +++++++ fs/xfs/xfs_stats.c | 47 ++++++++++++++++++++++++----------------------- fs/xfs/xfs_stats.h | 13 ++++++------- fs/xfs/xfs_super.c | 15 ++++++++------- fs/xfs/xfs_sysctl.c | 2 +- fs/xfs/xfs_sysfs.c | 17 +++++++++++++++-- 6 files changed, 61 insertions(+), 40 deletions(-) diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h index 85f883d..f1a8505 100644 --- a/fs/xfs/xfs_linux.h +++ b/fs/xfs/xfs_linux.h @@ -171,6 +171,13 @@ struct xfs_kobj { struct completion complete; }; +struct xstats { + struct xfsstats __percpu *xs_stats; + struct xfs_kobj xs_kobj; +}; + +extern struct xstats xfsstats; + /* Kernel uid/gid conversion. These are used to convert to/from the on disk * uid_t/gid_t types to the kuid_t/kgid_t types that the kernel uses internally. * The conversion here is type only, the value will remain the same since we diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index dc6ca67..ab79973 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -18,18 +18,18 @@ #include "xfs.h" #include -DEFINE_PER_CPU(struct xfsstats, xfsstats); +struct xstats xfsstats; -static int counter_val(int idx) +static int counter_val(struct xfsstats __percpu *stats, int idx) { int val = 0, cpu; for_each_possible_cpu(cpu) - val += *(((__u32 *)&per_cpu(xfsstats, cpu) + idx)); + val += *(((__u32 *)&per_cpu(*stats, cpu) + idx)); return val; } -int xfs_stats_format(char *buf) +int xfs_stats_format(struct xfsstats __percpu *stats, char *buf) { int i, j; int len = 0; @@ -73,14 +73,14 @@ int xfs_stats_format(char *buf) /* inner loop does each group */ for (; j < xstats[i].endpoint; j++) len += snprintf(buf + len, PATH_MAX - len, " %u", - counter_val(j)); + counter_val(stats, j)); len += snprintf(buf + len, PATH_MAX - len, "\n"); } /* extra precision counters */ for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; + xs_xstrat_bytes += per_cpu(*stats, i).xs_xstrat_bytes; + xs_write_bytes += per_cpu(*stats, i).xs_write_bytes; + xs_read_bytes += per_cpu(*stats, i).xs_read_bytes; } len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", @@ -95,7 +95,7 @@ int xfs_stats_format(char *buf) return len; } -void xfs_stats_clearall(void) +void xfs_stats_clearall(struct xfsstats __percpu *stats) { int c; __uint32_t vn_active; @@ -104,10 +104,10 @@ void xfs_stats_clearall(void) for_each_possible_cpu(c) { preempt_disable(); /* save vn_active, it's a universal truth! */ - vn_active = per_cpu(xfsstats, c).vn_active; - memset(&per_cpu(xfsstats, c), 0, - sizeof(struct xfsstats)); - per_cpu(xfsstats, c).vn_active = vn_active; + vn_active = per_cpu(*stats, c).vn_active; + memset(&per_cpu(*stats, c), 0, + sizeof(*stats)); + per_cpu(*stats, c).vn_active = vn_active; preempt_enable(); } } @@ -119,9 +119,10 @@ static int xqm_proc_show(struct seq_file *m, void *v) /* maximum; incore; ratio free to inuse; freelist */ seq_printf(m, "%d\t%d\t%d\t%u\n", 0, - counter_val(XFSSTAT_END_XQMSTAT), + counter_val(xfsstats.xs_stats, XFSSTAT_END_XQMSTAT), 0, - counter_val(XFSSTAT_END_XQMSTAT + 1)); + counter_val(xfsstats.xs_stats, + XFSSTAT_END_XQMSTAT + 1)); return 0; } @@ -145,7 +146,7 @@ static int xqmstat_proc_show(struct seq_file *m, void *v) seq_printf(m, "qm"); for (j = XFSSTAT_END_IBT_V2; j < XFSSTAT_END_XQMSTAT; j++) - seq_printf(m, " %u", counter_val(j)); + seq_printf(m, " %u", counter_val(xfsstats.xs_stats, j)); seq_putc(m, '\n'); return 0; } @@ -171,28 +172,28 @@ xfs_init_procfs(void) goto out; if (!proc_symlink("fs/xfs/stat", NULL, - "/sys/fs/xfs/stats/stats")) + "/sys/fs/xfs/stats/stats")) goto out_remove_xfs_dir; #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, - &xqmstat_proc_fops)) + &xqmstat_proc_fops)) goto out_remove_stat_file; if (!proc_create("fs/xfs/xqm", 0, NULL, - &xqm_proc_fops)) + &xqm_proc_fops)) goto out_remove_xqmstat_file; #endif return 0; #ifdef CONFIG_XFS_QUOTA - out_remove_xqmstat_file: +out_remove_xqmstat_file: remove_proc_entry("fs/xfs/xqmstat", NULL); - out_remove_stat_file: +out_remove_stat_file: remove_proc_entry("fs/xfs/stat", NULL); #endif - out_remove_xfs_dir: +out_remove_xfs_dir: remove_proc_entry("fs/xfs", NULL); - out: +out: return -ENOMEM; } diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index 18807b5..672fe83 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -18,9 +18,6 @@ #ifndef __XFS_STATS_H__ #define __XFS_STATS_H__ -int xfs_stats_format(char *buf); -void xfs_stats_clearall(void); - #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) #include @@ -217,15 +214,17 @@ struct xfsstats { __uint64_t xs_read_bytes; }; -DECLARE_PER_CPU(struct xfsstats, xfsstats); +int xfs_stats_format(struct xfsstats __percpu *stats, char *buf); +void xfs_stats_clearall(struct xfsstats __percpu *stats); +extern struct xstats xfsstats; /* * We don't disable preempt, not too worried about poking the * wrong CPU's stat for now (also aggregated before reporting). */ -#define XFS_STATS_INC(v) (per_cpu(xfsstats, current_cpu()).v++) -#define XFS_STATS_DEC(v) (per_cpu(xfsstats, current_cpu()).v--) -#define XFS_STATS_ADD(v, inc) (per_cpu(xfsstats, current_cpu()).v += (inc)) +#define XFS_STATS_INC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v++) +#define XFS_STATS_DEC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v--) +#define XFS_STATS_ADD(v, inc) (per_cpu(*xfsstats.xs_stats, current_cpu()).v += (inc)) extern int xfs_init_procfs(void); extern void xfs_cleanup_procfs(void); diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 31ad281..f1ea1c9 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -61,7 +61,6 @@ static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; static struct kset *xfs_kset; /* top-level xfs sysfs dir */ -static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ #ifdef DEBUG static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ #endif @@ -1802,6 +1801,7 @@ xfs_destroy_workqueues(void) destroy_workqueue(xfs_alloc_wq); } + STATIC int __init init_xfs_fs(void) { @@ -1842,8 +1842,9 @@ init_xfs_fs(void) goto out_sysctl_unregister; } - xfs_stats_kobj.kobject.kset = xfs_kset; - error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, + xfsstats.xs_stats = alloc_percpu(struct xfsstats); + xfsstats.xs_kobj.kobject.kset = xfs_kset; + error = xfs_sysfs_init(&xfsstats.xs_kobj, &xfs_stats_ktype, NULL, "stats"); if (error) goto out_kset_unregister; @@ -1852,7 +1853,7 @@ init_xfs_fs(void) xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_remove_stats_kobj; + goto out_remove_stats; #endif error = xfs_qm_init(); @@ -1869,9 +1870,9 @@ init_xfs_fs(void) out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_remove_stats_kobj: + out_remove_stats: #endif - xfs_sysfs_del(&xfs_stats_kobj); + free_percpu(xfsstats.xs_stats); out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: @@ -1898,7 +1899,7 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif - xfs_sysfs_del(&xfs_stats_kobj); + free_percpu(xfsstats.xs_stats); kset_unregister(xfs_kset); xfs_sysctl_unregister(); xfs_cleanup_procfs(); diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c index 5defabb..aed74d3 100644 --- a/fs/xfs/xfs_sysctl.c +++ b/fs/xfs/xfs_sysctl.c @@ -37,7 +37,7 @@ xfs_stats_clear_proc_handler( ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); if (!ret && write && *valp) { - xfs_stats_clearall(); + xfs_stats_clearall(xfsstats.xs_stats); xfs_stats_clear = 0; } diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index ab4850b..3275408 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -131,12 +131,23 @@ struct kobj_type xfs_dbg_ktype = { /* stats */ +static inline struct xstats * +to_xstats(struct kobject *kobject) +{ + struct xfs_kobj *kobj = to_kobj(kobject); + + return container_of(kobj, struct xstats, xs_kobj); +} + + STATIC ssize_t stats_show( struct kobject *kobject, char *buf) { - return xfs_stats_format(buf); + struct xstats *stats = to_xstats(kobject); + + return xfs_stats_format(stats->xs_stats, buf); } XFS_SYSFS_ATTR_RO(stats); @@ -148,6 +159,7 @@ stats_clear_store( { int ret; int val; + struct xstats *stats = to_xstats(kobject); ret = kstrtoint(buf, 0, &val); if (ret) @@ -155,7 +167,8 @@ stats_clear_store( if (val != 1) return -EINVAL; - xfs_stats_clearall(); + + xfs_stats_clearall(stats->xs_stats); return count; } XFS_SYSFS_ATTR_WO(stats_clear); -- 2.4.3 From billodo@redhat.com Tue Sep 22 07:08:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 7CC207F54 for ; Tue, 22 Sep 2015 07:08:08 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 71A79304039 for ; Tue, 22 Sep 2015 05:08:08 -0700 (PDT) X-ASG-Debug-ID: 1442923683-04cb6c6b0569680001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id EyS6JKEAQ91Jqb9w (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 05:08:03 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 077FDC0A1497 for ; Tue, 22 Sep 2015 12:08:03 +0000 (UTC) Received: from localhost.localdomain.com (vpn-53-129.rdu2.redhat.com [10.10.53.129]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MC81ng022782 for ; Tue, 22 Sep 2015 08:08:02 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 1/5] xfs: create global stats and stats_clear in sysfs Date: Tue, 22 Sep 2015 07:07:47 -0500 X-ASG-Orig-Subj: [PATCH 1/5] xfs: create global stats and stats_clear in sysfs Message-Id: <1442923671-14125-2-git-send-email-billodo@redhat.com> In-Reply-To: <1442923671-14125-1-git-send-email-billodo@redhat.com> References: <1442923671-14125-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442923683 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Currently, xfs global stats are in procfs. This patch introduces (replicates) the global stats in sysfs. Additionally a stats_clear file is introduced in sysfs. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_stats.h | 2 ++ fs/xfs/xfs_super.c | 20 +++++++++---- fs/xfs/xfs_sysctl.c | 15 ++-------- fs/xfs/xfs_sysfs.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_sysfs.h | 1 + 6 files changed, 179 insertions(+), 17 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index f224038..6008e25 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -29,6 +29,89 @@ static int counter_val(int idx) return val; } +int xfs_stats_format(char *buf) +{ + int i, j; + int len = 0; + __uint64_t xs_xstrat_bytes = 0; + __uint64_t xs_write_bytes = 0; + __uint64_t xs_read_bytes = 0; + + static const struct xstats_entry { + char *desc; + int endpoint; + } xstats[] = { + { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, + { "abt", XFSSTAT_END_ALLOC_BTREE }, + { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, + { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, + { "dir", XFSSTAT_END_DIRECTORY_OPS }, + { "trans", XFSSTAT_END_TRANSACTIONS }, + { "ig", XFSSTAT_END_INODE_OPS }, + { "log", XFSSTAT_END_LOG_OPS }, + { "push_ail", XFSSTAT_END_TAIL_PUSHING }, + { "xstrat", XFSSTAT_END_WRITE_CONVERT }, + { "rw", XFSSTAT_END_READ_WRITE_OPS }, + { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, + { "icluster", XFSSTAT_END_INODE_CLUSTER }, + { "vnodes", XFSSTAT_END_VNODE_OPS }, + { "buf", XFSSTAT_END_BUF }, + { "abtb2", XFSSTAT_END_ABTB_V2 }, + { "abtc2", XFSSTAT_END_ABTC_V2 }, + { "bmbt2", XFSSTAT_END_BMBT_V2 }, + { "ibt2", XFSSTAT_END_IBT_V2 }, + { "fibt2", XFSSTAT_END_FIBT_V2 }, + /* we print both series of quota information together */ + { "qm", XFSSTAT_END_QM }, + }; + + /* Loop over all stats groups */ + + for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { + len += snprintf(buf + len, PATH_MAX - len, "%s", + xstats[i].desc); + /* inner loop does each group */ + for (; j < xstats[i].endpoint; j++) + len += snprintf(buf + len, PATH_MAX - len, " %u", + counter_val(j)); + len += snprintf(buf + len, PATH_MAX - len, "\n"); + } + /* extra precision counters */ + for_each_possible_cpu(i) { + xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; + xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; + xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; + } + + len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", + xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); + len += snprintf(buf+len, PATH_MAX-len, "debug %u\n", +#if defined(DEBUG) + 1); +#else + 0); +#endif + +return len; +} + +void xfs_stats_clearall(void) +{ + int c; + __uint32_t vn_active; + + xfs_notice(NULL, "Clearing xfsstats"); + for_each_possible_cpu(c) { + preempt_disable(); + /* save vn_active, it's a universal truth! */ + vn_active = per_cpu(xfsstats, c).vn_active; + memset(&per_cpu(xfsstats, c), 0, + sizeof(struct xfsstats)); + per_cpu(xfsstats, c).vn_active = vn_active; + preempt_enable(); + } +} + static int xfs_stat_proc_show(struct seq_file *m, void *v) { int i, j; diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index c8f238b..18807b5 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -18,6 +18,8 @@ #ifndef __XFS_STATS_H__ #define __XFS_STATS_H__ +int xfs_stats_format(char *buf); +void xfs_stats_clearall(void); #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 3bf503a..31ad281 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -61,6 +61,7 @@ static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; static struct kset *xfs_kset; /* top-level xfs sysfs dir */ +static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ #ifdef DEBUG static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ #endif @@ -1838,19 +1839,25 @@ init_xfs_fs(void) xfs_kset = kset_create_and_add("xfs", NULL, fs_kobj); if (!xfs_kset) { error = -ENOMEM; - goto out_sysctl_unregister;; + goto out_sysctl_unregister; } + xfs_stats_kobj.kobject.kset = xfs_kset; + error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, + "stats"); + if (error) + goto out_kset_unregister; + #ifdef DEBUG xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_kset_unregister; + goto out_remove_stats_kobj; #endif error = xfs_qm_init(); if (error) - goto out_remove_kobj; + goto out_remove_dbg_kobj; error = register_filesystem(&xfs_fs_type); if (error) @@ -1859,11 +1866,13 @@ init_xfs_fs(void) out_qm_exit: xfs_qm_exit(); - out_remove_kobj: + out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_kset_unregister: + out_remove_stats_kobj: #endif + xfs_sysfs_del(&xfs_stats_kobj); + out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: xfs_sysctl_unregister(); @@ -1889,6 +1898,7 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif + xfs_sysfs_del(&xfs_stats_kobj); kset_unregister(xfs_kset); xfs_sysctl_unregister(); xfs_cleanup_procfs(); diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c index a0c8067..5defabb 100644 --- a/fs/xfs/xfs_sysctl.c +++ b/fs/xfs/xfs_sysctl.c @@ -19,6 +19,7 @@ #include #include #include "xfs_error.h" +#include "xfs_stats.h" static struct ctl_table_header *xfs_table_header; @@ -31,22 +32,12 @@ xfs_stats_clear_proc_handler( size_t *lenp, loff_t *ppos) { - int c, ret, *valp = ctl->data; - __uint32_t vn_active; + int ret, *valp = ctl->data; ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); if (!ret && write && *valp) { - xfs_notice(NULL, "Clearing xfsstats"); - for_each_possible_cpu(c) { - preempt_disable(); - /* save vn_active, it's a universal truth! */ - vn_active = per_cpu(xfsstats, c).vn_active; - memset(&per_cpu(xfsstats, c), 0, - sizeof(struct xfsstats)); - per_cpu(xfsstats, c).vn_active = vn_active; - preempt_enable(); - } + xfs_stats_clearall(); xfs_stats_clear = 0; } diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index aa03670..a094e20 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -21,6 +21,7 @@ #include "xfs_log_format.h" #include "xfs_log.h" #include "xfs_log_priv.h" +#include "xfs_stats.h" struct xfs_sysfs_attr { struct attribute attr; @@ -38,6 +39,8 @@ to_attr(struct attribute *attr) static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RW(name) #define XFS_SYSFS_ATTR_RO(name) \ static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RO(name) +#define XFS_SYSFS_ATTR_WO(name) \ + static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_WO(name) #define ATTR_LIST(name) &xfs_sysfs_attr_##name.attr @@ -125,6 +128,78 @@ struct kobj_type xfs_dbg_ktype = { #endif /* DEBUG */ + +/* stats */ + +STATIC ssize_t +stats_show( + char *buf, + void *data) +{ + return xfs_stats_format(buf); +} +XFS_SYSFS_ATTR_RO(stats); + +STATIC ssize_t +stats_clear_store( + const char *buf, + size_t count, + void *data) +{ + int ret; + int val; + + ret = kstrtoint(buf, 0, &val); + if (ret) + return ret; + + if (val != 1) + return -EINVAL; + xfs_stats_clearall(); + return count; +} +XFS_SYSFS_ATTR_WO(stats_clear); + +static struct attribute *xfs_stats_attrs[] = { + ATTR_LIST(stats), + ATTR_LIST(stats_clear), + NULL, +}; + +STATIC ssize_t +xfs_stats_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; +} + +STATIC ssize_t +xfs_stats_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; +} + +static struct sysfs_ops xfs_stats_ops = { + .show = xfs_stats_show, + .store = xfs_stats_store, +}; + +struct kobj_type xfs_stats_ktype = { + .release = xfs_sysfs_release, + .sysfs_ops = &xfs_stats_ops, + .default_attrs = xfs_stats_attrs, +}; + /* xlog */ STATIC ssize_t diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h index 240eee3..be692e5 100644 --- a/fs/xfs/xfs_sysfs.h +++ b/fs/xfs/xfs_sysfs.h @@ -22,6 +22,7 @@ extern struct kobj_type xfs_mp_ktype; /* xfs_mount */ extern struct kobj_type xfs_dbg_ktype; /* debug */ extern struct kobj_type xfs_log_ktype; /* xlog */ +extern struct kobj_type xfs_stats_ktype; /* stats */ static inline struct xfs_kobj * to_kobj(struct kobject *kobject) -- 2.4.3 From billodo@redhat.com Tue Sep 22 07:08:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 9C0007F55 for ; Tue, 22 Sep 2015 07:08:08 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 809E2304048 for ; Tue, 22 Sep 2015 05:08:05 -0700 (PDT) X-ASG-Debug-ID: 1442923683-04bdf0462871600001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id FNKlBlHSQCh1i1mG (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 05:08:03 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 837B3C0B2B57 for ; Tue, 22 Sep 2015 12:08:03 +0000 (UTC) Received: from localhost.localdomain.com (vpn-53-129.rdu2.redhat.com [10.10.53.129]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MC81nh022782 for ; Tue, 22 Sep 2015 08:08:03 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 2/5] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Date: Tue, 22 Sep 2015 07:07:48 -0500 X-ASG-Orig-Subj: [PATCH 2/5] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-Id: <1442923671-14125-3-git-send-email-billodo@redhat.com> In-Reply-To: <1442923671-14125-1-git-send-email-billodo@redhat.com> References: <1442923671-14125-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442923683 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 6008e25..a9f05de 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -244,9 +244,10 @@ xfs_init_procfs(void) if (!proc_mkdir("fs/xfs", NULL)) goto out; - if (!proc_create("fs/xfs/stat", 0, NULL, - &xfs_stat_proc_fops)) + if (!proc_symlink("fs/xfs/stat", NULL, + "/sys/fs/xfs/stats/stats")) goto out_remove_xfs_dir; + #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, &xqmstat_proc_fops)) -- 2.4.3 From billodo@redhat.com Tue Sep 22 07:08:09 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 43D2E7F59 for ; Tue, 22 Sep 2015 07:08:09 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id B5A80AC00B for ; Tue, 22 Sep 2015 05:08:05 -0700 (PDT) X-ASG-Debug-ID: 1442923684-04cb6c6b0769690001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 1vMg5veRSTHwlAB3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 05:08:04 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 05769A0BA0 for ; Tue, 22 Sep 2015 12:08:04 +0000 (UTC) Received: from localhost.localdomain.com (vpn-53-129.rdu2.redhat.com [10.10.53.129]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MC81ni022782 for ; Tue, 22 Sep 2015 08:08:03 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 3/5] xfs: remove unused procfs code Date: Tue, 22 Sep 2015 07:07:49 -0500 X-ASG-Orig-Subj: [PATCH 3/5] xfs: remove unused procfs code Message-Id: <1442923671-14125-4-git-send-email-billodo@redhat.com> In-Reply-To: <1442923671-14125-1-git-send-email-billodo@redhat.com> References: <1442923671-14125-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442923684 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch removes the now unused procfs code that was xfs stat specific. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 74 ------------------------------------------------------ 1 file changed, 74 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index a9f05de..05d5227 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -112,80 +112,6 @@ void xfs_stats_clearall(void) } } -static int xfs_stat_proc_show(struct seq_file *m, void *v) -{ - int i, j; - __uint64_t xs_xstrat_bytes = 0; - __uint64_t xs_write_bytes = 0; - __uint64_t xs_read_bytes = 0; - - static const struct xstats_entry { - char *desc; - int endpoint; - } xstats[] = { - { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, - { "abt", XFSSTAT_END_ALLOC_BTREE }, - { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, - { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, - { "dir", XFSSTAT_END_DIRECTORY_OPS }, - { "trans", XFSSTAT_END_TRANSACTIONS }, - { "ig", XFSSTAT_END_INODE_OPS }, - { "log", XFSSTAT_END_LOG_OPS }, - { "push_ail", XFSSTAT_END_TAIL_PUSHING }, - { "xstrat", XFSSTAT_END_WRITE_CONVERT }, - { "rw", XFSSTAT_END_READ_WRITE_OPS }, - { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, - { "icluster", XFSSTAT_END_INODE_CLUSTER }, - { "vnodes", XFSSTAT_END_VNODE_OPS }, - { "buf", XFSSTAT_END_BUF }, - { "abtb2", XFSSTAT_END_ABTB_V2 }, - { "abtc2", XFSSTAT_END_ABTC_V2 }, - { "bmbt2", XFSSTAT_END_BMBT_V2 }, - { "ibt2", XFSSTAT_END_IBT_V2 }, - { "fibt2", XFSSTAT_END_FIBT_V2 }, - /* we print both series of quota information together */ - { "qm", XFSSTAT_END_QM }, - }; - - /* Loop over all stats groups */ - for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { - seq_printf(m, "%s", xstats[i].desc); - /* inner loop does each group */ - for (; j < xstats[i].endpoint; j++) - seq_printf(m, " %u", counter_val(j)); - seq_putc(m, '\n'); - } - /* extra precision counters */ - for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; - } - - seq_printf(m, "xpc %Lu %Lu %Lu\n", - xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); - seq_printf(m, "debug %u\n", -#if defined(DEBUG) - 1); -#else - 0); -#endif - return 0; -} - -static int xfs_stat_proc_open(struct inode *inode, struct file *file) -{ - return single_open(file, xfs_stat_proc_show, NULL); -} - -static const struct file_operations xfs_stat_proc_fops = { - .owner = THIS_MODULE, - .open = xfs_stat_proc_open, - .read = seq_read, - .llseek = seq_lseek, - .release = single_release, -}; - /* legacy quota interfaces */ #ifdef CONFIG_XFS_QUOTA static int xqm_proc_show(struct seq_file *m, void *v) -- 2.4.3 From bfoster@redhat.com Tue Sep 22 07:22:42 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id DA1397F56 for ; Tue, 22 Sep 2015 07:22:42 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id BAABA304048 for ; Tue, 22 Sep 2015 05:22:42 -0700 (PDT) X-ASG-Debug-ID: 1442924561-04cb6c6b0669b10001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id fgCSZDU13aVEnql5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 05:22:41 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id DF13DC0A1479; Tue, 22 Sep 2015 12:22:40 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MCMedk009369; Tue, 22 Sep 2015 08:22:40 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 7DCD31202D2; Tue, 22 Sep 2015 08:22:39 -0400 (EDT) Date: Tue, 22 Sep 2015 08:22:39 -0400 From: Brian Foster To: Dave Chinner , xfs@oss.sgi.com Subject: Re: [PATCH] xfs_io: Implement inodes64 command Message-ID: <20150922122238.GA46026@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH] xfs_io: Implement inodes64 command References: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> <20150921220832.GB19114@dastard> <20150922075432.GC26699@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150922075432.GC26699@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442924561 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 22, 2015 at 09:54:32AM +0200, Carlos Maiolino wrote: > On Tue, Sep 22, 2015 at 08:08:32AM +1000, Dave Chinner wrote: > > On Mon, Sep 21, 2015 at 10:56:08AM +0200, Carlos Maiolino wrote: ... > > > + > > > + bulkreq.lastip = &last; > > > + bulkreq.icount = 1; > > > + bulkreq.ubuffer = &igroup; > > > + bulkreq.ocount = &count; > > > + > > > + if (!xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { > > > + if (count > 0) { > > > + printf("Filesystem does have 64bit inodes\n"); > > > + return 0; > > > + } else { > > > + printf("Filesystem does not have 64bit inodes\n"); > > > + return 0; > > > + } > > > + } > > > + perror("xfsctl(XFS_IOC_FSINUMBERS)"); > > > > I'd do this the other way around: > > > > if (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { > > perror("XFS_IOC_FSINUMBERS"); > > exitcode = 1; > > return 0; > > } > > > > if (count > 0) > > printf("Filesystem does have 64bit inodes\n"); > > else > > printf("Filesystem does not have 64bit inodes\n"); > > return 0; > > > > is sufficient, xfsctl is a one line wrapper around ioctl(). > > > > Ok, I'll change this, but, just a matter of curiosity, what are the technical > reasons to write the conditional this way, instead of the way I wrote first? > Just to avoid entering the conditional? > Not to speak for Dave, but I had the same thought just skimming through the patch. I don't think it's a technical reason so much as a style one. The further the function is grown, the easier it is to see that this kind of flow is not the most friendly thing. E.g.: ret = do_stuff(); if (!ret) { ... ret = do_more_stuff(); if (!ret) { ... } } In other words, the common execution path of the function starts to flow "inward" rather than the natural top-down flow of the function: ret = do_stuff(); if (ret) handle_err; ret = do_more_stuff(); if (ret) handle_err; ... The latter tends to be easier to follow, easier to review the error handling cases, probably avoids indentation problems down the road, etc. The function as it is right now is simple and so this probably isn't a big deal, but I suspect seeing the latter form so frequently in all of our other code is probably what causes something like the former to stand out (even in a simple/harmless example). Just my .02. :) Brian > > > > @@ -815,6 +847,12 @@ open_init(void) > > > _("get/set preferred extent size (in bytes) for the open file"); > > > extsize_cmd.help = extsize_help; > > > > > > + inodes64_cmd.name = "inodes64"; > > > + inodes64_cmd.cfunc = inodes64_f; > > > + inodes64_cmd.flags = CMD_NOMAP_OK; > > > + inodes64_cmd.oneline = > > > + _("Checks if filesyste contais 64bit inodes"); > > ^^^ ^^ 64 bit > > > > "inodes64" could be improved as a command name. e.g: > > > > oneline = _("Query inode number usage in the filesystem") > > > > And could do a little more to help users work out what the > > problematic inode is. e.g: > > > > Long help: > > > > Inode_numbers [-s|-l] [num] > > > > [-s] returns the physical size of the largest inode > > number in the filesystem (32 bit of 64 bit) > > [-l] returns the largest inode number in the filesystem > > [-n] returns the next inode number after [num] > > [num] returns whether the inode number exists > > > > i.e. if you want 32 bit inodes in the fs, you can use [-n num] to > > iterate all the inode numbers above 32 bits in size... > > > > Ok, np > > > Cheers, > > > > Dave. > > -- > > Dave Chinner > > david@fromorbit.com > > > > _______________________________________________ > > xfs mailing list > > xfs@oss.sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs > > -- > Carlos > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From mel@ohmu.fi Tue Sep 22 07:25:00 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id A80C27F58 for ; Tue, 22 Sep 2015 07:25:00 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 87BEE8F8035 for ; Tue, 22 Sep 2015 05:25:00 -0700 (PDT) X-ASG-Debug-ID: 1442924697-04cbb033b3781d0001-NocioJ Received: from smtp.suomicom.fi (smtp.suomicom.fi [217.119.36.23]) by cuda.sgi.com with ESMTP id pxwBWLahX3nuJs2H (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 05:24:58 -0700 (PDT) X-Barracuda-Envelope-From: mel@ohmu.fi X-Barracuda-Apparent-Source-IP: 217.119.36.23 Received: from 79-134-127-219.cust.suomicom.net ([79.134.127.219] helo=localhost.localdomain) by smtp.suomicom.fi with esmtp (Exim 4.72) (envelope-from ) id 1ZeMcU-0001Jf-Qx; Tue, 22 Sep 2015 15:24:26 +0300 From: Mika Eloranta To: xfs@oss.sgi.com Cc: Mika Eloranta Subject: [PATCH] mkfs.xfs: option for using a pre-defined filesystem UUID Date: Tue, 22 Sep 2015 15:24:51 +0300 X-ASG-Orig-Subj: [PATCH] mkfs.xfs: option for using a pre-defined filesystem UUID Message-Id: <1442924691-42001-1-git-send-email-mel@ohmu.fi> X-Mailer: git-send-email 2.3.5 X-Barracuda-Connect: smtp.suomicom.fi[217.119.36.23] X-Barracuda-Start-Time: 1442924698 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_RULE_7580D X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22783 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.75 BSF_RULE_7580D Custom Rule 7580D Usage: mkfs.xfs -m uuid= The filesystem UUID can now be optionally specified during filesystem creation. The default behavior is still to generate a random UUID. Allows using pre-generated UUIDs for identifying a filesystem based on the metadata stored inside the filesystem. Filesystem labels can be used for the same purpose, but are limited by their length (12 chars in the case of xfs) whereas the UUID field can store an entire 128bit UUID, which is plenty for e.g. random ID collision avoidance. Random UUID generated during the creation of the filesystem is not always feasible when an external DB or other system is used to track the created filesystem, e.g. in automated VM provisioning systems, as this would require a feedback mechanism which is not always available. In these cases the best approach often is to generate a random UUID for the filesystem before the filesystem even exists, store it in the tracking DB and later create the filesystem directly with the correct UUID (instead of "mkfs.xfs + xfs_admin -U "). --- man/man8/mkfs.xfs.8 | 4 ++++ mkfs/xfs_mkfs.c | 15 +++++++++++++-- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/man/man8/mkfs.xfs.8 b/man/man8/mkfs.xfs.8 index 6260e0c..e98b94d 100644 --- a/man/man8/mkfs.xfs.8 +++ b/man/man8/mkfs.xfs.8 @@ -169,6 +169,10 @@ will create free inode btrees for filesystems created with the (default) option set. When the option .B \-m crc=0 is used, the free inode btree feature is not supported and is disabled. +.TP +.BI uuid= value +Use the given value as the filesystem UUID for the newly created filesystem. +The default is to generate a random UUID. .RE .TP .BI \-d " data_section_options" diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c index d993fc0..696c96d 100644 --- a/mkfs/xfs_mkfs.c +++ b/mkfs/xfs_mkfs.c @@ -181,6 +181,8 @@ char *mopts[] = { "crc", #define M_FINOBT 1 "finobt", +#define M_UUID 2 + "uuid", NULL }; @@ -948,6 +950,7 @@ main( bool finobtflag; int spinodes; + platform_uuid_clear(&uuid); progname = basename(argv[0]); setlocale(LC_ALL, ""); bindtextdomain(PACKAGE, LOCALEDIR); @@ -1488,6 +1491,12 @@ main( finobt = c; finobtflag = true; break; + case M_UUID: + if (!value || *value == '\0') + reqval('m', mopts, M_UUID); + if (platform_uuid_parse(value, &uuid)) + illegal(optarg, "m uuid"); + break; default: unknown('m', value); } @@ -2550,7 +2559,9 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"), sbp->sb_dblocks = dblocks; sbp->sb_rblocks = rtblocks; sbp->sb_rextents = rtextents; - platform_uuid_generate(&uuid); + if (platform_uuid_is_null(&uuid)) { + platform_uuid_generate(&uuid); + } platform_uuid_copy(&sbp->sb_uuid, &uuid); /* Only in memory; libxfs expects this as if read from disk */ platform_uuid_copy(&sbp->sb_meta_uuid, &uuid); @@ -3163,7 +3174,7 @@ usage( void ) { fprintf(stderr, _("Usage: %s\n\ /* blocksize */ [-b log=n|size=num]\n\ -/* metadata */ [-m crc=0|1,finobt=0|1]\n\ +/* metadata */ [-m crc=0|1,finobt=0|1,uuid=xxx]\n\ /* data subvol */ [-d agcount=n,agsize=n,file,name=xxx,size=num,\n\ (sunit=value,swidth=value|su=num,sw=num|noalign),\n\ sectlog=n|sectsize=num\n\ -- 2.3.5 From angelo.dureghello@nomovok.com Tue Sep 22 07:41:12 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 1524929DF5 for ; Tue, 22 Sep 2015 07:41:12 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id E623B8F8033 for ; Tue, 22 Sep 2015 05:41:11 -0700 (PDT) X-ASG-Debug-ID: 1442925668-04cbb033b078790001-NocioJ Received: from mail.nomovok.com (mail.nomovok.com [83.150.122.238]) by cuda.sgi.com with ESMTP id lJwFEEkv6ctGj0m1 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Sep 2015 05:41:09 -0700 (PDT) X-Barracuda-Envelope-From: angelo.dureghello@nomovok.com X-Barracuda-Apparent-Source-IP: 83.150.122.238 Received: from [192.168.0.111] (host46-236-dynamic.8-87-r.retail.telecomitalia.it [87.8.236.46]) by mail.nomovok.com (Postfix) with ESMTPSA id 49652AE17E for ; Tue, 22 Sep 2015 15:41:07 +0300 (EEST) Message-ID: <56014C62.1070403@nomovok.com> Date: Tue, 22 Sep 2015 14:41:06 +0200 From: Angelo Dureghello User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: xfstests, bad generic tests 009 and 308 References: <55FC3E0E.9060506@nomovok.com> <20150918224412.GE26895@dastard> <55FFE665.7040004@nomovok.com> <20150921225244.GD19114@dastard> X-ASG-Orig-Subj: Re: xfstests, bad generic tests 009 and 308 In-Reply-To: <20150921225244.GD19114@dastard> Content-Type: multipart/mixed; boundary="------------090109000100090403070109" X-Barracuda-Connect: mail.nomovok.com[83.150.122.238] X-Barracuda-Start-Time: 1442925668 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22783 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words This is a multi-part message in MIME format. --------------090109000100090403070109 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, still thanks for following. >> I am using actually gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf > So gcc-4.9 patched with a bunch of stuff from linaro and built as a > cross compiler from x86-64 to 32 bit arm? ISTR we had a bunch of > different compiler problems at one point that only showed up in > kernels build with a x86-64 to arm cross-compiler. In case you > haven't guessed, XFS has a history of being bitten by ARM compiler > problems. There's been a lot more problems in the past couple of > years than the historical trend, though. > > As it is, I highly recommend that you try a current 4.3 kernel, as > there are several code fixes in the XFS kernel code that work around > compiler issues we know about. AFAIA, the do_div() asm bug that > trips recent gcc optimisations isn't in the upstream kernel yet, but > that can be worked around by setting CONFIG_CC_OPTIMIZE_FOR_SIZE=y > in your build. Well, i updated to this toolchain recently, but built the kernel also with an i686 4.9 toolchain, and had exactly same tests errors. Yes i am always cross compiling for armhf btw. I am using a 4.1.5-rt from TI, will try possibly some more recent version and let you know. >> I have recent git version of xfstests, but generic/308 shows >> >> #! /bin/bash >> # FS QA Test No. 308 >> # >> # Regression test for commit: >> # f17722f ext4: Fix max file size and logical block counting of >> extent format file > More that one filesystem had problems with maximum file sizes on 32 > bit systems. Compare the contents of the test; don't stop reading > because the summary of the test makes you think the rest of the test > is unrelated to the problem at hand. > >> I have a 16MB partition, and wondering why xfs allows from test 308 >> to create a 16TB file. >> >> -rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 > https://en.wikipedia.org/wiki/Sparse_file > >> QA output created by 009 >> 1. into a hole >> 0: [0..39]: hole >> daa100df6e6711906b61c9ab5aa16032 >> 2. into allocated space >> cc58a7417c2d7763adc45b6fcd3fa024 >> 3. into unwritten space >> daa100df6e6711906b61c9ab5aa16032 > I don't need to look any further to see that something is badly > wrong here. This is telling me that no extents are being allocated > at all, which indicates either fiemap is broken, awk/sed is > broken or misbehaving (and hence mangling the output) or something > deep in the filesystem code is fundamentally broken in some > strange, silent way. > > Can you create an xfs filesystem on your scratch device, and > manually run this command and post the output: > > # mkfs.xfs -V > # mkfs.xfs > # mount /mnt/xfs > # xfs_io -f -c "pwrite 0 64k" -c sync \ > -c "bmap -vp" -c "fiemap -v" \ > -c "falloc 1024k 256k" -c sync \ > -c "pwrite 1088k 64k" -c sync \ > -c "bmap -vp" -c "fiemap -v" \ > /mnt/xfs/testfile > > and attach the entire output? I attached the output. I can be completely wrong, but file system seems quite reliable for rootfs operations until now. At least, never had any issue after installing and removing several and several debian packages. Only issues i had are created from test 308 that, if left running too long, it damages the fs. > It would also be good if you can run this command under trace-cmd > and capture all the XFS events that occur during the test. See Ok, about test 308, the 2 xfs_io operations passes, it stops on the rm exiting the tests, while trying to erase the 16t file. # Create a sparse file with an extent lays at one block before old s_maxbytes offset=$(((2**32 - 2) * $block_size)) $XFS_IO_PROG -f -c "pwrite $offset $block_size" -c fsync $testfile >$seqres.full 2>&1 rm can remove remove correctly this file (17592186040320) # Write to the block after the extent just created offset=$(((2**32 - 1) * $block_size)) $XFS_IO_PROG -f -c "pwrite $offset $block_size" -c fsync $testfile >>$seqres.full 2>&1 while rm hangs on removing this file (17592186044415) Magic sysrq l or t is not helping, nothing useful comes out. But i collected the strace log. Since the issue is at unlinkat(). Many thanks Best regards Angelo -- Best regards, Angelo Dureghello --------------090109000100090403070109 Content-Type: text/plain; charset=UTF-8; name="mkfs_output.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mkfs_output.txt" root[249] ~ # mkfs.xfs -V mkfs.xfs version 3.2.1 root[250] ~ # mkfs.xfs /dev/mmcblk0p6 mkfs.xfs: /dev/mmcblk0p6 appears to contain an existing filesystem (xfs). mkfs.xfs: Use the -f option to force overwrite. root[251] ~ # mkfs.xfs -f /dev/mmcblk0p6 meta-data=/dev/mmcblk0p6 isize=256 agcount=4, agsize=551008 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=2204032, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 root[252] ~ # mount /dev/mmcblk0p6 /media/p6 [38946.599770] XFS (mmcblk0p6): Mounting V4 Filesystem [38946.800708] XFS (mmcblk0p6): Ending clean mount # xfs_io -f -c "pwrite 0 64k" -c sync \ -c "bmap -vp" -c "fiemap -v" \ -c "falloc 1024k 256k" -c sync \ -c "pwrite 1088k 64k" -c sync \ -c "bmap -vp" -c "fiemap -v" \ /media/p6/testfile wrote 65536/65536 bytes at offset 0 64 KiB, 16 ops; 0.0000 sec (96.154 MiB/sec and 24615.3846 ops/sec) command "sync" not found /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..127]: 96..223 0 (96..223) 128 00000 /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 96..223 128 0x1 command "sync" not found wrote 65536/65536 bytes at offset 1114112 64 KiB, 16 ops; 0.0000 sec (112.208 MiB/sec and 28725.3142 ops/sec) command "sync" not found /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..127]: 96..223 0 (96..223) 128 00000 1: [128..2047]: hole 1920 2: [2048..2559]: 2144..2655 0 (2144..2655) 512 10000 /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 96..223 128 0x0 1: [128..2047]: hole 1920 2: [2048..2175]: 2144..2271 128 0x800 3: [2176..2303]: 2272..2399 128 0x0 4: [2304..2559]: 2400..2655 256 0x801 Step by step xfs_io ------------------- Due to the "sync" is missing, i tried also command by command with shell "sync" after each command. Output is exactly the same. --------------090109000100090403070109 Content-Type: text/plain; charset=UTF-8; name="strace_rm_308.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="strace_rm_308.txt" -rw------- 1 root root 17592186040320 Sep 22 10:55 testfile.308 rm ok -rw------- 1 root root 17592186044415 Sep 22 10:58 testfile.308 total 496 drwxr-xr-x 11 root root 4096 Sep 22 10:58 . drwxr-xr-x 4 root root 101 Sep 22 08:40 .. -rw------- 1 root root 131072 Sep 21 14:50 008.24410 -rw------- 1 root root 131072 Sep 21 14:52 008.2913 -rw------- 1 root root 4096 Sep 21 14:50 009.25001 -rw------- 1 root root 4096 Sep 21 14:52 009.3505 -rw------- 1 root root 81920 Sep 21 14:50 012.26531 -rw------- 1 root root 49152 Sep 21 14:52 012.5039 drwxr-xr-x 3 root root 4096 Sep 21 15:16 14536 drwxr-xr-x 3 root root 38 Sep 21 15:25 16802 drwxr-xr-x 3 root root 4096 Sep 21 15:26 18438 drwxr-xr-x 3 root root 38 Sep 21 15:27 21042 drwxr-xr-x 3 root root 38 Sep 21 14:50 27593 drwxr-xr-x 3 root root 70 Sep 21 15:08 8274 drwxr-xr-x 3 root root 15 Sep 21 14:53 fsstress.5653.1 drwxr-xr-x 22 root root 4096 Sep 21 14:53 fsstress.5653.2 -rw------- 1 root root 17592186044415 Sep 22 11:44 testfile.308 drwxr-xr-x 2 root root 20 Sep 21 15:12 tmp root[252] vpc24 /media/p5 # rm testfile.308 # strace rm testfile.308 execve("/bin/rm", ["rm", "testfile.308"], [/* 16 vars */]) = 0 brk(0) = 0x2a000 uname({sys="Linux", node="vpc24", ...}) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f36000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=34089, ...}) = 0 mmap2(NULL, 34089, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f2d000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0Mw\1\0004\0\0\0"..., 512) = 512 lseek(3, 899996, SEEK_SET) = 899996 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2880) = 2880 lseek(3, 896548, SEEK_SET) = 896548 read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\3\f"..., 53) = 53 fstat64(3, {st_mode=S_IFREG|0755, st_size=902876, ...}) = 0 mmap2(NULL, 972200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e23000 mprotect(0xb6efc000, 61440, PROT_NONE) = 0 mmap2(0xb6f0b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd8000) = 0xb6f0b000 mmap2(0xb6f0e000, 9640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f0e000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f2c000 set_tls(0xb6f2c850, 0xb6f39050, 0xb6f2cf38, 0xb6f2c850, 0xb6f39050) = 0 mprotect(0xb6f0b000, 8192, PROT_READ) = 0 mprotect(0x28000, 4096, PROT_READ) = 0 mprotect(0xb6f38000, 4096, PROT_READ) = 0 munmap(0xb6f2d000, 34089) = 0 brk(0) = 0x2a000 brk(0x4b000) = 0x4b000 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B115200 opost isig icanon echo ...}) = 0 newfstatat(AT_FDCWD, "testfile.308", {st_mode=S_IFREG|0600, st_size=17592186044415, ...}, AT_SYMLINK_NOFOLLOW) = 0 geteuid32() = 0 unlinkat(AT_FDCWD, "testfile.308", 0 --------------090109000100090403070109-- From bfoster@redhat.com Tue Sep 22 09:21:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 8571F7F5E for ; Tue, 22 Sep 2015 09:21:08 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 75F7D304032 for ; Tue, 22 Sep 2015 07:21:05 -0700 (PDT) X-ASG-Debug-ID: 1442931663-04cb6c6b056e100001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id u7l1vYDpeuhtmU7U (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 07:21:04 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 2A5E88C1BC; Tue, 22 Sep 2015 14:21:03 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MEL20p007355; Tue, 22 Sep 2015 10:21:02 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 532301202D2; Tue, 22 Sep 2015 10:21:01 -0400 (EDT) Date: Tue, 22 Sep 2015 10:21:01 -0400 From: Brian Foster To: Dave Chinner Cc: xfs@oss.sgi.com Subject: Re: [RFC v2 2/2] xfs: validate metadata LSNs against log on v5 superblocks Message-ID: <20150922142100.GB46026@bfoster.bfoster> X-ASG-Orig-Subj: Re: [RFC v2 2/2] xfs: validate metadata LSNs against log on v5 superblocks References: <1441997635-36644-1-git-send-email-bfoster@redhat.com> <1441997635-36644-3-git-send-email-bfoster@redhat.com> <20150922080725.GC3902@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150922080725.GC3902@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1442931663 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 22, 2015 at 06:07:25PM +1000, Dave Chinner wrote: > On Fri, Sep 11, 2015 at 02:53:55PM -0400, Brian Foster wrote: > > Since the onset of v5 superblocks, the LSN of the last modification has > > been included in a variety of on-disk data structures. This LSN is used > > to provide log recovery ordering guarantees (e.g., to ensure an older > > log recovery item is not replayed over a newer target data structure). > > > > While this works correctly from the point a filesystem is formatted and > > mounted, userspace tools have some problematic behaviors that defeat > > this mechanism. For example, xfs_repair historically zeroes out the log > > unconditionally (regardless of whether corruption is detected). If this > > occurs, the LSN of the filesystem is reset and the log is now in a > > problematic state with respect to on-disk metadata structures that might > > have a larger LSN. Until either the log catches up to the highest > > previously used metadata LSN or each affected data structure is modified > > and written out without incident (which resets the metadata LSN), log > > recovery is susceptible to filesystem corruption. > > > > This problem is ultimately addressed and repaired in the associated > > userspace tools. The kernel is still responsible to detect the problem > > and notify the user that something is wrong. Check the superblock LSN at > > mount time and notify the user and fail the mount if it is invalid. > > From that point on, simply warn the user if an invalid metadata LSN is > > detected from the various metadata I/O verifiers. A new xfs_mount flag > > is added to guarantee that a warning fires at least once for each > > affected filesystem mount. From that point forward, further instances of > > the problem are rate limited to a once per 24 hour period. > > > > Signed-off-by: Brian Foster > > --- > > fs/xfs/libxfs/xfs_alloc.c | 9 +++++-- > > fs/xfs/libxfs/xfs_attr_leaf.c | 2 ++ > > fs/xfs/libxfs/xfs_btree.c | 14 +++++++++-- > > fs/xfs/libxfs/xfs_da_btree.c | 3 +++ > > fs/xfs/libxfs/xfs_dir2_block.c | 1 + > > fs/xfs/libxfs/xfs_dir2_data.c | 1 + > > fs/xfs/libxfs/xfs_dir2_leaf.c | 1 + > > fs/xfs/libxfs/xfs_dir2_node.c | 1 + > > fs/xfs/libxfs/xfs_ialloc.c | 8 +++++-- > > fs/xfs/libxfs/xfs_sb.c | 8 +++++++ > > fs/xfs/libxfs/xfs_symlink_remote.c | 3 +++ > > fs/xfs/xfs_log.c | 1 - > > fs/xfs/xfs_log_priv.h | 24 +++++++++++++++++++ > > fs/xfs/xfs_log_recover.c | 15 +++++++++++- > > fs/xfs/xfs_mount.c | 49 ++++++++++++++++++++++++++++++++++++++ > > fs/xfs/xfs_mount.h | 3 +++ > > 16 files changed, 135 insertions(+), 8 deletions(-) > > > > diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c > > index ffad7f2..cb26016 100644 > > --- a/fs/xfs/libxfs/xfs_alloc.c > > +++ b/fs/xfs/libxfs/xfs_alloc.c > > @@ -482,6 +482,8 @@ xfs_agfl_verify( > > be32_to_cpu(agfl->agfl_bno[i]) >= mp->m_sb.sb_agblocks) > > return false; > > } > > + > > + xfs_detect_invalid_lsn(mp, be64_to_cpu(XFS_BUF_TO_AGFL(bp)->agfl_lsn)); > > return true; > > xfs_log_check_lsn(mp, ); > Ok. > > +/* > > + * The LSN is valid so long as it is behind the current LSN. If it isn't, this > > + * means that the next log record that includes this metadata could have a > > + * smaller LSN. In turn, this means that the modification in the log would not > > + * replay. > > + */ > > +static inline bool > > +xlog_valid_lsn( > > + struct xlog *log, > > + xfs_lsn_t lsn) > > +{ > > + int cycle = CYCLE_LSN(lsn); > > + int block = BLOCK_LSN(lsn); > > + bool valid = true; > > + > > + spin_lock(&log->l_icloglock); > > + if ((cycle > log->l_curr_cycle) || > > + (cycle == log->l_curr_cycle && block > log->l_curr_block)) > > + valid = false; > > + spin_unlock(&log->l_icloglock); > > + > > + return valid; > > +} > > We do not want to take the l_icloglock in metadata IO > context. It's a global fs lock, and it's a hot lock, too, so we > do not want to be taking this during every metadata IO completion. > > I think, at minimum, we need to sample the current values and do an > unlocked check, then if the result is suspect we need to do an > accurate locked check. This means that we will almost never take the > l_icloglock here. e.g: > > { > int cycle = ACCESS_ONCE(log->l_curr_cycle); > int block = ACCESS_ONCE(log->l_curr_block); > > if (CYCLE_LSN(lsn) > cycle || > (CYCLE_LSN(lsn) == cycle && BLOCK_LSN(lsn) > block)) { > /* suspect, take icloglock to check again */ > bool valid = true; > > .... > return valid; > } > return true; > } > Good point. In this case, I may just lift the lock out of the helper and allow this to be the responsibility of the caller, but I'll see how it looks. > > > --- a/fs/xfs/xfs_mount.c > > +++ b/fs/xfs/xfs_mount.c > > @@ -41,6 +41,7 @@ > > #include "xfs_trace.h" > > #include "xfs_icache.h" > > #include "xfs_sysfs.h" > > +#include "xfs_log_priv.h" > > > > > > static DEFINE_MUTEX(xfs_uuid_table_mutex); > > @@ -1301,3 +1302,51 @@ xfs_dev_is_read_only( > > } > > return 0; > > } > > + > > +/* > > + * Verify that an LSN stamped into a piece of metadata is valid. This is > > + * intended for use in read verifiers on v5 superblocks. > > + */ > > +void > > +xfs_detect_invalid_lsn( > > + struct xfs_mount *mp, > > + xfs_lsn_t lsn) > > +{ > > This shoul dbe called xfs_log_check_lsn() and be located in > xfs_log.c. > Ok. > > + struct xlog *log = mp->m_log; > > + int cycle = CYCLE_LSN(lsn); > > + int block = BLOCK_LSN(lsn); > > + const char *fmt; > > + > > + /* > > + * 'norecovery' mode skips mount-time log processing and unconditionally > > + * resets the LSN. > > + */ > > + if (mp->m_flags & XFS_MOUNT_NORECOVERY) > > + return; > > + > > + if (xlog_valid_lsn(mp->m_log, lsn)) > > + return; > > + > > + /* > > + * Warn at least once for each filesystem susceptible to this problem > > + * and once per day thereafter. > > + * > > + * XXX: Specify the minimum xfs_repair version required to resolve? > > + * Older versions will silently reintroduce the problem. > > + * > > + * We should eventually convert this condition into a hard error (via > > + * verifier failure). Defer that behavior for a few release cycles or so > > + * until the userspace fixes have had the opportunity to propogate > > + * throughout the various distributions. > > + */ > > + fmt = "WARNING: Metadata has LSN (%d:%d) ahead of current LSN (%d:%d). " > > +"This may result in filesystem failure. Please unmount and run xfs_repair to resolve."; > > + if (!mp->m_warned_bad_lsn) { > > + mp->m_warned_bad_lsn = true; > > + xfs_warn(mp, fmt, cycle, block, log->l_curr_cycle, > > + log->l_curr_block); > > + } else { > > + xfs_warn_daily(mp, fmt, cycle, block, log->l_curr_cycle, > > + log->l_curr_block); > > + } > > That's really ugly. Rate limited prints should always occur at least > once for each ratelimit key, and now i've seen this I can say the > first patch needs rework. > This is definitely more ugly than the shutdown approach. As mentioned, I've been waffling back and forth on how to handle this condition. I had already sent the shutdown version, so I figured I would put together what I thought would be necessary to handle this with a warning for comparison. > that is, each xfs_warn_daily() caller needs it's own ratelimit key, > rather than sharing the global ratelimit key that all other XFS > messages share. > What do you mean by a key? What is the purpose? On further thought... I think I see what you mean. Each mount should report in the ratelimited timeframe independently. Or in other words, the rate limit of one mount should not affect message delivery on another. > e.g.: > xfs_warn_daily(mp, mp->m_log->l_lsn_rlstate, > "Corruption warning: Metadata has LSN (%d:%d) ahead of current LSN (%d:%d). " > "Please unmount and run xfs_repair (>= v4.3) to resolve.". > cycle, block, log->l_curr_cycle, log->l_curr_block); > > But really, thinking on this further (the "corruption warning" bit) > I'm starting to think we should just shut the filesystem down when > we hit this and force the user to fix it immediately. if we don't, > then who knows whether we are making things worse or not... > I was originally thinking the shutdown might not be ideal because we induce the very situation we're warning about (forcing a log recovery). Since this verifies on metadata reads, however, we should in theory avoid the problem before it could ever be introduced. My follow on question to that was whether a shutdown is appropriate for something that is somewhat minor and self-corrective..? Given the ugliness of the multiple warnings, new mount flag, additional complication of the ratelimit mechanism, etc., I might just go back to the shutdown and call it a day. ;) I think the subtle point raised above about calling this a corruption is a sufficient argument. While this might be minor and self-correcting, it is still technically a corruption of sorts and should be identified and repaired appropriately. Thanks for the feedback. Brian > > --- a/fs/xfs/xfs_mount.h > > +++ b/fs/xfs/xfs_mount.h > > @@ -127,6 +127,7 @@ typedef struct xfs_mount { > > int64_t m_low_space[XFS_LOWSP_MAX]; > > /* low free space thresholds */ > > struct xfs_kobj m_kobj; > > + bool m_warned_bad_lsn;/* bad metadata lsn detected */ > > That's where I'd put the ratelimit key (or in the struct xlog). > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com From sandeen@sandeen.net Tue Sep 22 09:48:02 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 7C70D7F37 for ; Tue, 22 Sep 2015 09:48:02 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 6A2458F8035 for ; Tue, 22 Sep 2015 07:48:02 -0700 (PDT) X-ASG-Debug-ID: 1442933279-04cbb033b17c540001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id 7n9YL0mfqFt8IENn for ; Tue, 22 Sep 2015 07:47:59 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 2784365AFD0F for ; Tue, 22 Sep 2015 09:47:59 -0500 (CDT) Subject: Re: [PATCH 5/5] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 5/5] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. References: <1442923671-14125-1-git-send-email-billodo@redhat.com> <1442923671-14125-6-git-send-email-billodo@redhat.com> From: Eric Sandeen X-Enigmail-Draft-Status: N1110 Message-ID: <56016A1E.8080103@sandeen.net> Date: Tue, 22 Sep 2015 09:47:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1442923671-14125-6-git-send-email-billodo@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1442933279 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22785 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/22/15 7:07 AM, Bill O'Donnell wrote: > This patch is the next step toward per-fs xfs stats. Allocate & > deallocate per-fs stats structures and set up the sysfs entries for them. Ok, the patch doesn't actually do that last sentence yet, so I'd leave it out of the description. :) You could mumble about how this enables the next patch, though, i.e. this makes the show & clear routines able to handle any stats structure associated with a kobject. > Instead of a single global xfsstats structure, add kobject and a pointer > to a per-cpu struct xfsstats. Modify the macros that manipulate the stats > accordingly: XFS_STATS_INC, XFS_STATS_DEC, and XFS_STATS_ADD now access > xfsstats->xs_stats. > > The sysfs functions need to get from the kobject back to the xfsstats > structure which contains it, and pass the pointer to the ->xs_stats > percpu structure into the show & clear routines. > > > Signed-off-by: Bill O'Donnell > --- > fs/xfs/xfs_linux.h | 7 +++++++ > fs/xfs/xfs_stats.c | 47 ++++++++++++++++++++++++----------------------- > fs/xfs/xfs_stats.h | 13 ++++++------- > fs/xfs/xfs_super.c | 15 ++++++++------- > fs/xfs/xfs_sysctl.c | 2 +- > fs/xfs/xfs_sysfs.c | 17 +++++++++++++++-- > 6 files changed, 61 insertions(+), 40 deletions(-) > > diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h > index 85f883d..f1a8505 100644 > --- a/fs/xfs/xfs_linux.h > +++ b/fs/xfs/xfs_linux.h > @@ -171,6 +171,13 @@ struct xfs_kobj { > struct completion complete; > }; > > +struct xstats { > + struct xfsstats __percpu *xs_stats; > + struct xfs_kobj xs_kobj; nitpick, I'd fiddle w/ whitespace a little to make the 2 members line up nicely. > +}; > + > +extern struct xstats xfsstats; > + > /* Kernel uid/gid conversion. These are used to convert to/from the on disk > * uid_t/gid_t types to the kuid_t/kgid_t types that the kernel uses internally. > * The conversion here is type only, the value will remain the same since we > diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > index dc6ca67..ab79973 100644 > --- a/fs/xfs/xfs_stats.c > +++ b/fs/xfs/xfs_stats.c > @@ -18,18 +18,18 @@ > #include "xfs.h" > #include > > -DEFINE_PER_CPU(struct xfsstats, xfsstats); > +struct xstats xfsstats; > > -static int counter_val(int idx) > +static int counter_val(struct xfsstats __percpu *stats, int idx) > { > int val = 0, cpu; > > for_each_possible_cpu(cpu) > - val += *(((__u32 *)&per_cpu(xfsstats, cpu) + idx)); > + val += *(((__u32 *)&per_cpu(*stats, cpu) + idx)); Now that we are referring to a pointer to a percpu structure (instead of the old global xfsstats structure itself), I think it's a lot cleaner & more legible to do: + val += *(((__u32 *)per_cpu_ptr(stats, cpu) + idx)); (ok the cast gyrations may not qualify as "clean and legible" but it helps - see also below) > return val; > } > > -int xfs_stats_format(char *buf) > +int xfs_stats_format(struct xfsstats __percpu *stats, char *buf) > { > int i, j; > int len = 0; > @@ -73,14 +73,14 @@ int xfs_stats_format(char *buf) > /* inner loop does each group */ > for (; j < xstats[i].endpoint; j++) > len += snprintf(buf + len, PATH_MAX - len, " %u", > - counter_val(j)); > + counter_val(stats, j)); > len += snprintf(buf + len, PATH_MAX - len, "\n"); > } > /* extra precision counters */ > for_each_possible_cpu(i) { > - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; > - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; > - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; > + xs_xstrat_bytes += per_cpu(*stats, i).xs_xstrat_bytes; > + xs_write_bytes += per_cpu(*stats, i).xs_write_bytes; > + xs_read_bytes += per_cpu(*stats, i).xs_read_bytes; ditto here, + xs_xstrat_bytes += per_cpu_ptr(stats, i)->xs_xstrat_bytes; + xs_write_bytes += per_cpu_ptr(stats, i)->xs_write_bytes; + xs_read_bytes += per_cpu_ptr(stats, i)->xs_read_bytes; > } > > len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", > @@ -95,7 +95,7 @@ int xfs_stats_format(char *buf) > return len; > } > > -void xfs_stats_clearall(void) > +void xfs_stats_clearall(struct xfsstats __percpu *stats) > { > int c; > __uint32_t vn_active; > @@ -104,10 +104,10 @@ void xfs_stats_clearall(void) > for_each_possible_cpu(c) { > preempt_disable(); > /* save vn_active, it's a universal truth! */ > - vn_active = per_cpu(xfsstats, c).vn_active; > - memset(&per_cpu(xfsstats, c), 0, > - sizeof(struct xfsstats)); > - per_cpu(xfsstats, c).vn_active = vn_active; > + vn_active = per_cpu(*stats, c).vn_active; > + memset(&per_cpu(*stats, c), 0, > + sizeof(*stats)); > + per_cpu(*stats, c).vn_active = vn_active; > preempt_enable(); > } > } + vn_active = per_cpu_ptr(stats, c)->vn_active; + memset(per_cpu_ptr(stats, c), 0, sizeof(*stats)); + per_cpu_ptr(stats, c)->vn_active = vn_active; > @@ -119,9 +119,10 @@ static int xqm_proc_show(struct seq_file *m, void *v) > /* maximum; incore; ratio free to inuse; freelist */ > seq_printf(m, "%d\t%d\t%d\t%u\n", > 0, > - counter_val(XFSSTAT_END_XQMSTAT), > + counter_val(xfsstats.xs_stats, XFSSTAT_END_XQMSTAT), > 0, > - counter_val(XFSSTAT_END_XQMSTAT + 1)); > + counter_val(xfsstats.xs_stats, > + XFSSTAT_END_XQMSTAT + 1)); might be able to make this fit on one line by lining up the "0" with the "%d" but *shrug* now i'm really being stupidly nitpicky. > return 0; > } > > @@ -145,7 +146,7 @@ static int xqmstat_proc_show(struct seq_file *m, void *v) > > seq_printf(m, "qm"); > for (j = XFSSTAT_END_IBT_V2; j < XFSSTAT_END_XQMSTAT; j++) > - seq_printf(m, " %u", counter_val(j)); > + seq_printf(m, " %u", counter_val(xfsstats.xs_stats, j)); > seq_putc(m, '\n'); > return 0; > } > @@ -171,28 +172,28 @@ xfs_init_procfs(void) > goto out; > > if (!proc_symlink("fs/xfs/stat", NULL, > - "/sys/fs/xfs/stats/stats")) > + "/sys/fs/xfs/stats/stats")) intentional whitespace changes? > goto out_remove_xfs_dir; > > #ifdef CONFIG_XFS_QUOTA > if (!proc_create("fs/xfs/xqmstat", 0, NULL, > - &xqmstat_proc_fops)) > + &xqmstat_proc_fops)) > goto out_remove_stat_file; > if (!proc_create("fs/xfs/xqm", 0, NULL, > - &xqm_proc_fops)) > + &xqm_proc_fops)) Same question. (did checkpatch complain or something?) > goto out_remove_xqmstat_file; > #endif > return 0; > > #ifdef CONFIG_XFS_QUOTA > - out_remove_xqmstat_file: > +out_remove_xqmstat_file: > remove_proc_entry("fs/xfs/xqmstat", NULL); > - out_remove_stat_file: > +out_remove_stat_file: > remove_proc_entry("fs/xfs/stat", NULL); > #endif > - out_remove_xfs_dir: > +out_remove_xfs_dir: > remove_proc_entry("fs/xfs", NULL); > - out: > +out: > return -ENOMEM; > } same whitespace question. unless there's a reason, I'd not include these nonfunctional changes in this patch. > diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h > index 18807b5..672fe83 100644 > --- a/fs/xfs/xfs_stats.h > +++ b/fs/xfs/xfs_stats.h > @@ -18,9 +18,6 @@ > #ifndef __XFS_STATS_H__ > #define __XFS_STATS_H__ > > -int xfs_stats_format(char *buf); > -void xfs_stats_clearall(void); > - > #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) > > #include > @@ -217,15 +214,17 @@ struct xfsstats { > __uint64_t xs_read_bytes; > }; > > -DECLARE_PER_CPU(struct xfsstats, xfsstats); > +int xfs_stats_format(struct xfsstats __percpu *stats, char *buf); > +void xfs_stats_clearall(struct xfsstats __percpu *stats); > +extern struct xstats xfsstats; > > /* > * We don't disable preempt, not too worried about poking the > * wrong CPU's stat for now (also aggregated before reporting). > */ > -#define XFS_STATS_INC(v) (per_cpu(xfsstats, current_cpu()).v++) > -#define XFS_STATS_DEC(v) (per_cpu(xfsstats, current_cpu()).v--) > -#define XFS_STATS_ADD(v, inc) (per_cpu(xfsstats, current_cpu()).v += (inc)) > +#define XFS_STATS_INC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v++) > +#define XFS_STATS_DEC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v--) > +#define XFS_STATS_ADD(v, inc) (per_cpu(*xfsstats.xs_stats, current_cpu()).v += (inc)) Line > 80 chars > > extern int xfs_init_procfs(void); > extern void xfs_cleanup_procfs(void); > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > index 31ad281..f1ea1c9 100644 > --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -61,7 +61,6 @@ static kmem_zone_t *xfs_ioend_zone; > mempool_t *xfs_ioend_pool; > > static struct kset *xfs_kset; /* top-level xfs sysfs dir */ > -static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ > #ifdef DEBUG > static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ > #endif > @@ -1802,6 +1801,7 @@ xfs_destroy_workqueues(void) > destroy_workqueue(xfs_alloc_wq); > } > > + no need for a new newline here > STATIC int __init > init_xfs_fs(void) > { > @@ -1842,8 +1842,9 @@ init_xfs_fs(void) > goto out_sysctl_unregister; > } > > - xfs_stats_kobj.kobject.kset = xfs_kset; > - error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, > + xfsstats.xs_stats = alloc_percpu(struct xfsstats); need to check for allocation failure here, and fix up the goto/cleanup targets as a result. > + xfsstats.xs_kobj.kobject.kset = xfs_kset; > + error = xfs_sysfs_init(&xfsstats.xs_kobj, &xfs_stats_ktype, NULL, > "stats"); > if (error) > goto out_kset_unregister; > @@ -1852,7 +1853,7 @@ init_xfs_fs(void) > xfs_dbg_kobj.kobject.kset = xfs_kset; > error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); > if (error) > - goto out_remove_stats_kobj; > + goto out_remove_stats; > #endif > > error = xfs_qm_init(); > @@ -1869,9 +1870,9 @@ init_xfs_fs(void) > out_remove_dbg_kobj: > #ifdef DEBUG > xfs_sysfs_del(&xfs_dbg_kobj); > - out_remove_stats_kobj: > + out_remove_stats: > #endif > - xfs_sysfs_del(&xfs_stats_kobj); > + free_percpu(xfsstats.xs_stats); > out_kset_unregister: > kset_unregister(xfs_kset); > out_sysctl_unregister: > @@ -1898,7 +1899,7 @@ exit_xfs_fs(void) > #ifdef DEBUG > xfs_sysfs_del(&xfs_dbg_kobj); > #endif > - xfs_sysfs_del(&xfs_stats_kobj); > + free_percpu(xfsstats.xs_stats); still need to delete the sysfs entry, even though it's no longer the xfs_stats_kobj - now it's the xfsstats.xs_kobj right? > kset_unregister(xfs_kset); > xfs_sysctl_unregister(); > xfs_cleanup_procfs(); > diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c > index 5defabb..aed74d3 100644 > --- a/fs/xfs/xfs_sysctl.c > +++ b/fs/xfs/xfs_sysctl.c > @@ -37,7 +37,7 @@ xfs_stats_clear_proc_handler( > ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); > > if (!ret && write && *valp) { > - xfs_stats_clearall(); > + xfs_stats_clearall(xfsstats.xs_stats); > xfs_stats_clear = 0; > } > > diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c > index ab4850b..3275408 100644 > --- a/fs/xfs/xfs_sysfs.c > +++ b/fs/xfs/xfs_sysfs.c > @@ -131,12 +131,23 @@ struct kobj_type xfs_dbg_ktype = { > > /* stats */ > > +static inline struct xstats * > +to_xstats(struct kobject *kobject) > +{ > + struct xfs_kobj *kobj = to_kobj(kobject); > + > + return container_of(kobj, struct xstats, xs_kobj); > +} > + > + > STATIC ssize_t > stats_show( > struct kobject *kobject, > char *buf) > { > - return xfs_stats_format(buf); > + struct xstats *stats = to_xstats(kobject); nitpick, tab before *stats to line it all up. > + > + return xfs_stats_format(stats->xs_stats, buf); > } > XFS_SYSFS_ATTR_RO(stats); > > @@ -148,6 +159,7 @@ stats_clear_store( > { > int ret; > int val; > + struct xstats *stats = to_xstats(kobject); nitpick, tab before *stats to line it all up. Thanks, -Eric > > ret = kstrtoint(buf, 0, &val); > if (ret) > @@ -155,7 +167,8 @@ stats_clear_store( > > if (val != 1) > return -EINVAL; > - xfs_stats_clearall(); > + > + xfs_stats_clearall(stats->xs_stats); > return count; > } > XFS_SYSFS_ATTR_WO(stats_clear); > From billodo@redhat.com Tue Sep 22 10:16:15 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 4DCF47F37 for ; Tue, 22 Sep 2015 10:16:15 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id BFC46AC005 for ; Tue, 22 Sep 2015 08:16:11 -0700 (PDT) X-ASG-Debug-ID: 1442934968-04cb6c6b076fdc0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id dsIOcbfdzt31hO1T (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 08:16:09 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 964EA8EA30; Tue, 22 Sep 2015 15:16:08 +0000 (UTC) Received: from redhat.com (vpn-53-129.rdu2.redhat.com [10.10.53.129]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MFG6RQ005184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Sep 2015 11:16:07 -0400 Date: Tue, 22 Sep 2015 10:16:05 -0500 From: "Bill O'Donnell" To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 5/5] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. Message-ID: <20150922151605.GA29067@redhat.com> X-ASG-Orig-Subj: Re: [PATCH 5/5] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. References: <1442923671-14125-1-git-send-email-billodo@redhat.com> <1442923671-14125-6-git-send-email-billodo@redhat.com> <56016A1E.8080103@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56016A1E.8080103@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1442934969 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Thanks for the review, Eric. On Tue, Sep 22, 2015 at 09:47:58AM -0500, Eric Sandeen wrote: > On 9/22/15 7:07 AM, Bill O'Donnell wrote: > > This patch is the next step toward per-fs xfs stats. Allocate & > > deallocate per-fs stats structures and set up the sysfs entries for them. > > Ok, the patch doesn't actually do that last sentence yet, so > I'd leave it out of the description. :) Agreed. > > You could mumble about how this enables the next patch, though, i.e. > this makes the show & clear routines able to handle any stats structure > associated with a kobject. Yep. > > > Instead of a single global xfsstats structure, add kobject and a pointer > > to a per-cpu struct xfsstats. Modify the macros that manipulate the stats > > accordingly: XFS_STATS_INC, XFS_STATS_DEC, and XFS_STATS_ADD now access > > xfsstats->xs_stats. > > > > The sysfs functions need to get from the kobject back to the xfsstats > > structure which contains it, and pass the pointer to the ->xs_stats > > percpu structure into the show & clear routines. > > > > > > Signed-off-by: Bill O'Donnell > > --- > > fs/xfs/xfs_linux.h | 7 +++++++ > > fs/xfs/xfs_stats.c | 47 ++++++++++++++++++++++++----------------------- > > fs/xfs/xfs_stats.h | 13 ++++++------- > > fs/xfs/xfs_super.c | 15 ++++++++------- > > fs/xfs/xfs_sysctl.c | 2 +- > > fs/xfs/xfs_sysfs.c | 17 +++++++++++++++-- > > 6 files changed, 61 insertions(+), 40 deletions(-) > > > > diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h > > index 85f883d..f1a8505 100644 > > --- a/fs/xfs/xfs_linux.h > > +++ b/fs/xfs/xfs_linux.h > > @@ -171,6 +171,13 @@ struct xfs_kobj { > > struct completion complete; > > }; > > > > +struct xstats { > > + struct xfsstats __percpu *xs_stats; > > + struct xfs_kobj xs_kobj; > > nitpick, I'd fiddle w/ whitespace a little to make the 2 members line > up nicely. Ok > > > +}; > > + > > +extern struct xstats xfsstats; > > + > > /* Kernel uid/gid conversion. These are used to convert to/from the on disk > > * uid_t/gid_t types to the kuid_t/kgid_t types that the kernel uses internally. > > * The conversion here is type only, the value will remain the same since we > > diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > > index dc6ca67..ab79973 100644 > > --- a/fs/xfs/xfs_stats.c > > +++ b/fs/xfs/xfs_stats.c > > @@ -18,18 +18,18 @@ > > #include "xfs.h" > > #include > > > > -DEFINE_PER_CPU(struct xfsstats, xfsstats); > > +struct xstats xfsstats; > > > > -static int counter_val(int idx) > > +static int counter_val(struct xfsstats __percpu *stats, int idx) > > { > > int val = 0, cpu; > > > > for_each_possible_cpu(cpu) > > - val += *(((__u32 *)&per_cpu(xfsstats, cpu) + idx)); > > + val += *(((__u32 *)&per_cpu(*stats, cpu) + idx)); > > Now that we are referring to a pointer to a percpu structure > (instead of the old global xfsstats structure itself), I think it's > a lot cleaner & more legible to do: > > + val += *(((__u32 *)per_cpu_ptr(stats, cpu) + idx)); > > (ok the cast gyrations may not qualify as "clean and legible" but it > helps - see also below) Agreed. > > > return val; > > } > > > > -int xfs_stats_format(char *buf) > > +int xfs_stats_format(struct xfsstats __percpu *stats, char *buf) > > { > > int i, j; > > int len = 0; > > @@ -73,14 +73,14 @@ int xfs_stats_format(char *buf) > > /* inner loop does each group */ > > for (; j < xstats[i].endpoint; j++) > > len += snprintf(buf + len, PATH_MAX - len, " %u", > > - counter_val(j)); > > + counter_val(stats, j)); > > len += snprintf(buf + len, PATH_MAX - len, "\n"); > > } > > /* extra precision counters */ > > for_each_possible_cpu(i) { > > - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; > > - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; > > - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; > > + xs_xstrat_bytes += per_cpu(*stats, i).xs_xstrat_bytes; > > + xs_write_bytes += per_cpu(*stats, i).xs_write_bytes; > > + xs_read_bytes += per_cpu(*stats, i).xs_read_bytes; > > ditto here, > > + xs_xstrat_bytes += per_cpu_ptr(stats, i)->xs_xstrat_bytes; > + xs_write_bytes += per_cpu_ptr(stats, i)->xs_write_bytes; > + xs_read_bytes += per_cpu_ptr(stats, i)->xs_read_bytes; > > > } > > > > len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", > > @@ -95,7 +95,7 @@ int xfs_stats_format(char *buf) > > return len; > > } > > > > -void xfs_stats_clearall(void) > > +void xfs_stats_clearall(struct xfsstats __percpu *stats) > > { > > int c; > > __uint32_t vn_active; > > @@ -104,10 +104,10 @@ void xfs_stats_clearall(void) > > for_each_possible_cpu(c) { > > preempt_disable(); > > /* save vn_active, it's a universal truth! */ > > - vn_active = per_cpu(xfsstats, c).vn_active; > > - memset(&per_cpu(xfsstats, c), 0, > > - sizeof(struct xfsstats)); > > - per_cpu(xfsstats, c).vn_active = vn_active; > > + vn_active = per_cpu(*stats, c).vn_active; > > + memset(&per_cpu(*stats, c), 0, > > + sizeof(*stats)); > > + per_cpu(*stats, c).vn_active = vn_active; > > preempt_enable(); > > } > > } > > > + vn_active = per_cpu_ptr(stats, c)->vn_active; > + memset(per_cpu_ptr(stats, c), 0, sizeof(*stats)); > + per_cpu_ptr(stats, c)->vn_active = vn_active; > > > > @@ -119,9 +119,10 @@ static int xqm_proc_show(struct seq_file *m, void *v) > > /* maximum; incore; ratio free to inuse; freelist */ > > seq_printf(m, "%d\t%d\t%d\t%u\n", > > 0, > > - counter_val(XFSSTAT_END_XQMSTAT), > > + counter_val(xfsstats.xs_stats, XFSSTAT_END_XQMSTAT), > > 0, > > - counter_val(XFSSTAT_END_XQMSTAT + 1)); > > + counter_val(xfsstats.xs_stats, > > + XFSSTAT_END_XQMSTAT + 1)); > > might be able to make this fit on one line by lining up the "0" > with the "%d" but *shrug* now i'm really being stupidly nitpicky. ;) > > > return 0; > > } > > > > @@ -145,7 +146,7 @@ static int xqmstat_proc_show(struct seq_file *m, void *v) > > > > seq_printf(m, "qm"); > > for (j = XFSSTAT_END_IBT_V2; j < XFSSTAT_END_XQMSTAT; j++) > > - seq_printf(m, " %u", counter_val(j)); > > + seq_printf(m, " %u", counter_val(xfsstats.xs_stats, j)); > > seq_putc(m, '\n'); > > return 0; > > } > > @@ -171,28 +172,28 @@ xfs_init_procfs(void) > > goto out; > > > > if (!proc_symlink("fs/xfs/stat", NULL, > > - "/sys/fs/xfs/stats/stats")) > > + "/sys/fs/xfs/stats/stats")) > > intentional whitespace changes? > > > goto out_remove_xfs_dir; > > > > #ifdef CONFIG_XFS_QUOTA > > if (!proc_create("fs/xfs/xqmstat", 0, NULL, > > - &xqmstat_proc_fops)) > > + &xqmstat_proc_fops)) > > goto out_remove_stat_file; > > if (!proc_create("fs/xfs/xqm", 0, NULL, > > - &xqm_proc_fops)) > > + &xqm_proc_fops)) > > Same question. (did checkpatch complain or something?) Yes. Checkpatch didn't like any spaces, so I turned em into tabs. > > > goto out_remove_xqmstat_file; > > #endif > > return 0; > > > > #ifdef CONFIG_XFS_QUOTA > > - out_remove_xqmstat_file: > > +out_remove_xqmstat_file: > > remove_proc_entry("fs/xfs/xqmstat", NULL); > > - out_remove_stat_file: > > +out_remove_stat_file: > > remove_proc_entry("fs/xfs/stat", NULL); > > #endif > > - out_remove_xfs_dir: > > +out_remove_xfs_dir: > > remove_proc_entry("fs/xfs", NULL); > > - out: > > +out: > > return -ENOMEM; > > } > > same whitespace question. unless there's a reason, I'd not include > these nonfunctional changes in this patch. Again, checkpatch didn't care for the preceding space on out_blah... > > > diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h > > index 18807b5..672fe83 100644 > > --- a/fs/xfs/xfs_stats.h > > +++ b/fs/xfs/xfs_stats.h > > @@ -18,9 +18,6 @@ > > #ifndef __XFS_STATS_H__ > > #define __XFS_STATS_H__ > > > > -int xfs_stats_format(char *buf); > > -void xfs_stats_clearall(void); > > - > > #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) > > > > #include > > @@ -217,15 +214,17 @@ struct xfsstats { > > __uint64_t xs_read_bytes; > > }; > > > > -DECLARE_PER_CPU(struct xfsstats, xfsstats); > > +int xfs_stats_format(struct xfsstats __percpu *stats, char *buf); > > +void xfs_stats_clearall(struct xfsstats __percpu *stats); > > +extern struct xstats xfsstats; > > > > /* > > * We don't disable preempt, not too worried about poking the > > * wrong CPU's stat for now (also aggregated before reporting). > > */ > > -#define XFS_STATS_INC(v) (per_cpu(xfsstats, current_cpu()).v++) > > -#define XFS_STATS_DEC(v) (per_cpu(xfsstats, current_cpu()).v--) > > -#define XFS_STATS_ADD(v, inc) (per_cpu(xfsstats, current_cpu()).v += (inc)) > > +#define XFS_STATS_INC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v++) > > +#define XFS_STATS_DEC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v--) > > +#define XFS_STATS_ADD(v, inc) (per_cpu(*xfsstats.xs_stats, current_cpu()).v += (inc)) > > Line > 80 chars I'll fix it. > > > > > extern int xfs_init_procfs(void); > > extern void xfs_cleanup_procfs(void); > > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > > index 31ad281..f1ea1c9 100644 > > --- a/fs/xfs/xfs_super.c > > +++ b/fs/xfs/xfs_super.c > > @@ -61,7 +61,6 @@ static kmem_zone_t *xfs_ioend_zone; > > mempool_t *xfs_ioend_pool; > > > > static struct kset *xfs_kset; /* top-level xfs sysfs dir */ > > -static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ > > #ifdef DEBUG > > static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ > > #endif > > @@ -1802,6 +1801,7 @@ xfs_destroy_workqueues(void) > > destroy_workqueue(xfs_alloc_wq); > > } > > > > + > > no need for a new newline here > > > STATIC int __init > > init_xfs_fs(void) > > { > > @@ -1842,8 +1842,9 @@ init_xfs_fs(void) > > goto out_sysctl_unregister; > > } > > > > - xfs_stats_kobj.kobject.kset = xfs_kset; > > - error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, > > + xfsstats.xs_stats = alloc_percpu(struct xfsstats); > > > need to check for allocation failure here, and fix up the goto/cleanup > targets as a result. Will do. > > > + xfsstats.xs_kobj.kobject.kset = xfs_kset; > > + error = xfs_sysfs_init(&xfsstats.xs_kobj, &xfs_stats_ktype, NULL, > > "stats"); > > if (error) > > goto out_kset_unregister; > > @@ -1852,7 +1853,7 @@ init_xfs_fs(void) > > xfs_dbg_kobj.kobject.kset = xfs_kset; > > error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); > > if (error) > > - goto out_remove_stats_kobj; > > + goto out_remove_stats; > > #endif > > > > error = xfs_qm_init(); > > @@ -1869,9 +1870,9 @@ init_xfs_fs(void) > > out_remove_dbg_kobj: > > #ifdef DEBUG > > xfs_sysfs_del(&xfs_dbg_kobj); > > - out_remove_stats_kobj: > > + out_remove_stats: > > #endif > > - xfs_sysfs_del(&xfs_stats_kobj); > > + free_percpu(xfsstats.xs_stats); > > out_kset_unregister: > > kset_unregister(xfs_kset); > > out_sysctl_unregister: > > @@ -1898,7 +1899,7 @@ exit_xfs_fs(void) > > #ifdef DEBUG > > xfs_sysfs_del(&xfs_dbg_kobj); > > #endif > > - xfs_sysfs_del(&xfs_stats_kobj); > > + free_percpu(xfsstats.xs_stats); > > still need to delete the sysfs entry, even though it's no longer > the xfs_stats_kobj - now it's the xfsstats.xs_kobj right? Correct. > > > kset_unregister(xfs_kset); > > xfs_sysctl_unregister(); > > xfs_cleanup_procfs(); > > diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c > > index 5defabb..aed74d3 100644 > > --- a/fs/xfs/xfs_sysctl.c > > +++ b/fs/xfs/xfs_sysctl.c > > @@ -37,7 +37,7 @@ xfs_stats_clear_proc_handler( > > ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); > > > > if (!ret && write && *valp) { > > - xfs_stats_clearall(); > > + xfs_stats_clearall(xfsstats.xs_stats); > > xfs_stats_clear = 0; > > } > > > > diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c > > index ab4850b..3275408 100644 > > --- a/fs/xfs/xfs_sysfs.c > > +++ b/fs/xfs/xfs_sysfs.c > > @@ -131,12 +131,23 @@ struct kobj_type xfs_dbg_ktype = { > > > > /* stats */ > > > > +static inline struct xstats * > > +to_xstats(struct kobject *kobject) > > +{ > > + struct xfs_kobj *kobj = to_kobj(kobject); > > + > > + return container_of(kobj, struct xstats, xs_kobj); > > +} > > + > > + > > STATIC ssize_t > > stats_show( > > struct kobject *kobject, > > char *buf) > > { > > - return xfs_stats_format(buf); > > + struct xstats *stats = to_xstats(kobject); > > nitpick, tab before *stats to line it all up. > > > + > > + return xfs_stats_format(stats->xs_stats, buf); > > } > > XFS_SYSFS_ATTR_RO(stats); > > > > @@ -148,6 +159,7 @@ stats_clear_store( > > { > > int ret; > > int val; > > + struct xstats *stats = to_xstats(kobject); > > nitpick, tab before *stats to line it all up. > > Thanks, > -Eric > > > > > ret = kstrtoint(buf, 0, &val); > > if (ret) > > @@ -155,7 +167,8 @@ stats_clear_store( > > > > if (val != 1) > > return -EINVAL; > > - xfs_stats_clearall(); > > + > > + xfs_stats_clearall(stats->xs_stats); > > return count; > > } > > XFS_SYSFS_ATTR_WO(stats_clear); > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From dhowells@redhat.com Tue Sep 22 10:25:01 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id CF6D67F3F for ; Tue, 22 Sep 2015 10:25:00 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 7B604AC005 for ; Tue, 22 Sep 2015 08:25:00 -0700 (PDT) X-ASG-Debug-ID: 1442935495-04bdf0462277520001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 6HwrDbgY3mFfhrf1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 08:24:55 -0700 (PDT) X-Barracuda-Envelope-From: dhowells@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 5607F461D3; Tue, 22 Sep 2015 15:24:55 +0000 (UTC) Received: from warthog.procyon.org.uk ([10.3.112.5]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MFOpwS017724; Tue, 22 Sep 2015 11:24:52 -0400 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Subject: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel From: David Howells X-ASG-Orig-Subj: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel To: viro@zeniv.linux.org.uk Cc: dhowells@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com Date: Tue, 22 Sep 2015 16:24:50 +0100 Message-ID: <20150922152450.32539.55285.stgit@warthog.procyon.org.uk> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442935495 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 We don't need to use O_LARGEFILE anymore inside the kernel and can for the most part just let it sit in the UAPI headers and ignore it everywhere else. Indeed on 64-bit arches, we enforce the use of O_LARGEFILE. Quite a few places turn it on, but only the following places actually take any notice of it directly: (1) fs/9p/vfs_inode_dotl.c. Converts O_LARGEFILE to P9_DOTL_LARGEFILE but otherwise seems to ignore it. Possibly it gets sent to a server. (2) fs/notify/fanotify/fanotify_user.c. Pass in event_f_flags. (3) fs/hfsplus/inode.c. Length check in hfsplus_file_open(). (4) fs/open.c: Length check in ftruncate(). (5) fs/open.c: Length check in generic_file_open(). (6) fs/xfs/xfs_file.c: Length check in xfs_file_open(). (7) mm/filemap.c: Length check in generic_write_checks(). All but the first two are just making length checks that are waived unconditionally on a 64-bit system. Just skip the length checks, assuming that O_LARGEFILE is actually set. There's also things like fcntl(F_GETFL) and fuse that pass it to userspace. NFS may be in the same boat, but if it is, I can't see where the flag->protocol translation takes place for it. For F_GETFL, fuse and fanotify, just set it unconditionally in the places that then pass it to userspace. We don't actually then set it in file->f_flags - except when userspace passes it in - since nothing then examines the bit in f_flags. Signed-off-by: David Howells --- fs/compat.c | 9 +++------ fs/fcntl.c | 2 +- fs/fhandle.c | 8 +------- fs/fuse/file.c | 7 ++++--- fs/hfsplus/inode.c | 2 -- fs/notify/fanotify/fanotify_user.c | 3 +-- fs/open.c | 28 ++++------------------------ fs/xfs/xfs_file.c | 2 -- fs/xfs/xfs_ioctl.c | 4 ---- mm/filemap.c | 10 ---------- 10 files changed, 14 insertions(+), 61 deletions(-) diff --git a/fs/compat.c b/fs/compat.c index 6fd272d455e4..51579f09a135 100644 --- a/fs/compat.c +++ b/fs/compat.c @@ -1084,8 +1084,7 @@ COMPAT_SYSCALL_DEFINE3(getdents64, unsigned int, fd, #endif /* __ARCH_WANT_COMPAT_SYS_GETDENTS64 */ /* - * Exactly like fs/open.c:sys_open(), except that it doesn't set the - * O_LARGEFILE flag. + * Exactly like fs/open.c:sys_open(). */ COMPAT_SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode) { @@ -1093,8 +1092,7 @@ COMPAT_SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, } /* - * Exactly like fs/open.c:sys_openat(), except that it doesn't set the - * O_LARGEFILE flag. + * Exactly like fs/open.c:sys_openat(). */ COMPAT_SYSCALL_DEFINE4(openat, int, dfd, const char __user *, filename, int, flags, umode_t, mode) { @@ -1470,8 +1468,7 @@ COMPAT_SYSCALL_DEFINE5(ppoll, struct pollfd __user *, ufds, #ifdef CONFIG_FHANDLE /* - * Exactly like fs/open.c:sys_open_by_handle_at(), except that it - * doesn't set the O_LARGEFILE flag. + * Exactly like fs/open.c:sys_open_by_handle_at(). */ COMPAT_SYSCALL_DEFINE3(open_by_handle_at, int, mountdirfd, struct file_handle __user *, handle, int, flags) diff --git a/fs/fcntl.c b/fs/fcntl.c index ee85cd4e136a..a7a8e07e0d59 100644 --- a/fs/fcntl.c +++ b/fs/fcntl.c @@ -260,7 +260,7 @@ static long do_fcntl(int fd, unsigned int cmd, unsigned long arg, set_close_on_exec(fd, arg & FD_CLOEXEC); break; case F_GETFL: - err = filp->f_flags; + err = filp->f_flags | O_LARGEFILE; break; case F_SETFL: err = setfl(fd, filp, arg); diff --git a/fs/fhandle.c b/fs/fhandle.c index d59712dfa3e7..93948172d186 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -256,11 +256,5 @@ SYSCALL_DEFINE3(open_by_handle_at, int, mountdirfd, struct file_handle __user *, handle, int, flags) { - long ret; - - if (force_o_largefile()) - flags |= O_LARGEFILE; - - ret = do_handle_open(mountdirfd, handle, flags); - return ret; + return do_handle_open(mountdirfd, handle, flags); } diff --git a/fs/fuse/file.c b/fs/fuse/file.c index f523f2f04c19..680bcbb9613b 100644 --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -28,6 +28,7 @@ static int fuse_send_open(struct fuse_conn *fc, u64 nodeid, struct file *file, memset(&inarg, 0, sizeof(inarg)); inarg.flags = file->f_flags & ~(O_CREAT | O_EXCL | O_NOCTTY); + inarg.flags |= O_LARGEFILE; if (!fc->atomic_o_trunc) inarg.flags &= ~O_TRUNC; args.in.h.opcode = opcode; @@ -235,7 +236,7 @@ static void fuse_prepare_release(struct fuse_file *ff, int flags, int opcode) wake_up_interruptible_all(&ff->poll_wait); inarg->fh = ff->fh; - inarg->flags = flags; + inarg->flags = flags | O_LARGEFILE; req->in.h.opcode = opcode; req->in.h.nodeid = ff->nodeid; req->in.numargs = 1; @@ -505,7 +506,7 @@ void fuse_read_fill(struct fuse_req *req, struct file *file, loff_t pos, inarg->fh = ff->fh; inarg->offset = pos; inarg->size = count; - inarg->flags = file->f_flags; + inarg->flags = file->f_flags | O_LARGEFILE; req->in.h.opcode = opcode; req->in.h.nodeid = ff->nodeid; req->in.numargs = 1; @@ -947,7 +948,7 @@ static size_t fuse_send_write(struct fuse_req *req, struct fuse_io_priv *io, struct fuse_write_in *inarg = &req->misc.write.in; fuse_write_fill(req, ff, pos, count); - inarg->flags = file->f_flags; + inarg->flags = file->f_flags | O_LARGEFILE; if (owner != NULL) { inarg->write_flags |= FUSE_WRITE_LOCKOWNER; inarg->lock_owner = fuse_lock_owner_id(fc, owner); diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c index 6dd107d7421e..0d73a3732532 100644 --- a/fs/hfsplus/inode.c +++ b/fs/hfsplus/inode.c @@ -216,8 +216,6 @@ static int hfsplus_file_open(struct inode *inode, struct file *file) { if (HFSPLUS_IS_RSRC(inode)) inode = HFSPLUS_I(inode)->rsrc_inode; - if (!(file->f_flags & O_LARGEFILE) && i_size_read(inode) > MAX_NON_LFS) - return -EOVERFLOW; atomic_inc(&HFSPLUS_I(inode)->opencnt); return 0; } diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c index 8e8e6bcd1d43..eaf202ef3d99 100644 --- a/fs/notify/fanotify/fanotify_user.c +++ b/fs/notify/fanotify/fanotify_user.c @@ -748,8 +748,7 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, unsigned int, event_f_flags) } group->overflow_event = &oevent->fse; - if (force_o_largefile()) - event_f_flags |= O_LARGEFILE; + event_f_flags |= O_LARGEFILE; group->fanotify_data.f_flags = event_f_flags; #ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS spin_lock_init(&group->fanotify_data.access_lock); diff --git a/fs/open.c b/fs/open.c index b6f1e96a7c0b..d1fbb8ee69f6 100644 --- a/fs/open.c +++ b/fs/open.c @@ -151,7 +151,7 @@ COMPAT_SYSCALL_DEFINE2(truncate, const char __user *, path, compat_off_t, length } #endif -static long do_sys_ftruncate(unsigned int fd, loff_t length, int small) +static long do_sys_ftruncate(unsigned int fd, loff_t length) { struct inode *inode; struct dentry *dentry; @@ -166,21 +166,12 @@ static long do_sys_ftruncate(unsigned int fd, loff_t length, int small) if (!f.file) goto out; - /* explicitly opened as large or we are on 64-bit box */ - if (f.file->f_flags & O_LARGEFILE) - small = 0; - dentry = f.file->f_path.dentry; inode = dentry->d_inode; error = -EINVAL; if (!S_ISREG(inode->i_mode) || !(f.file->f_mode & FMODE_WRITE)) goto out_putf; - error = -EINVAL; - /* Cannot ftruncate over 2^31 bytes without large file support */ - if (small && length > MAX_NON_LFS) - goto out_putf; - error = -EPERM; if (IS_APPEND(inode)) goto out_putf; @@ -200,13 +191,13 @@ out: SYSCALL_DEFINE2(ftruncate, unsigned int, fd, unsigned long, length) { - return do_sys_ftruncate(fd, length, 1); + return do_sys_ftruncate(fd, length); } #ifdef CONFIG_COMPAT COMPAT_SYSCALL_DEFINE2(ftruncate, unsigned int, fd, compat_ulong_t, length) { - return do_sys_ftruncate(fd, length, 1); + return do_sys_ftruncate(fd, length); } #endif @@ -219,7 +210,7 @@ SYSCALL_DEFINE2(truncate64, const char __user *, path, loff_t, length) SYSCALL_DEFINE2(ftruncate64, unsigned int, fd, loff_t, length) { - return do_sys_ftruncate(fd, length, 0); + return do_sys_ftruncate(fd, length); } #endif /* BITS_PER_LONG == 32 */ @@ -1037,18 +1028,12 @@ long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode) SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode) { - if (force_o_largefile()) - flags |= O_LARGEFILE; - return do_sys_open(AT_FDCWD, filename, flags, mode); } SYSCALL_DEFINE4(openat, int, dfd, const char __user *, filename, int, flags, umode_t, mode) { - if (force_o_largefile()) - flags |= O_LARGEFILE; - return do_sys_open(dfd, filename, flags, mode); } @@ -1126,14 +1111,9 @@ SYSCALL_DEFINE0(vhangup) /* * Called when an inode is about to be open. - * We use this to disallow opening large files on 32bit systems if - * the caller didn't specify O_LARGEFILE. On 64bit systems we force - * on this flag in sys_open. */ int generic_file_open(struct inode * inode, struct file * filp) { - if (!(filp->f_flags & O_LARGEFILE) && i_size_read(inode) > MAX_NON_LFS) - return -EOVERFLOW; return 0; } diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index e78feb400e22..7c8d9b4e44eb 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -1031,8 +1031,6 @@ xfs_file_open( struct inode *inode, struct file *file) { - if (!(file->f_flags & O_LARGEFILE) && i_size_read(inode) > MAX_NON_LFS) - return -EFBIG; if (XFS_FORCED_SHUTDOWN(XFS_M(inode->i_sb))) return -EIO; return 0; diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c index ea7d85af5310..0c5b4ae746c0 100644 --- a/fs/xfs/xfs_ioctl.c +++ b/fs/xfs/xfs_ioctl.c @@ -218,10 +218,6 @@ xfs_open_by_handle( goto out_dput; } -#if BITS_PER_LONG != 32 - hreq->oflags |= O_LARGEFILE; -#endif - permflag = hreq->oflags; fmode = OPEN_FMODE(permflag); if ((!(permflag & O_APPEND) || (permflag & O_TRUNC)) && diff --git a/mm/filemap.c b/mm/filemap.c index 72940fb38666..1d1e75aa49cf 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2311,16 +2311,6 @@ inline ssize_t generic_write_checks(struct kiocb *iocb, struct iov_iter *from) } /* - * LFS rule - */ - if (unlikely(pos + iov_iter_count(from) > MAX_NON_LFS && - !(file->f_flags & O_LARGEFILE))) { - if (pos >= MAX_NON_LFS) - return -EFBIG; - iov_iter_truncate(from, MAX_NON_LFS - (unsigned long)pos); - } - - /* * Are we about to exceed the fs block limit ? * * If we have written data it becomes a short write. If we have From dhowells@redhat.com Tue Sep 22 10:25:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id EEE957F3F for ; Tue, 22 Sep 2015 10:25:07 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 6EFF2AC00B for ; Tue, 22 Sep 2015 08:25:07 -0700 (PDT) X-ASG-Debug-ID: 1442935504-04cbb033b27d830001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id uHIhqJ8oUCjCNvA4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 08:25:05 -0700 (PDT) X-Barracuda-Envelope-From: dhowells@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id CDEC68AE72; Tue, 22 Sep 2015 15:25:04 +0000 (UTC) Received: from warthog.procyon.org.uk ([10.3.112.5]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MFP08A007967; Tue, 22 Sep 2015 11:25:02 -0400 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Subject: [RFC PATCH 2/2] VFS: Don't pass O_LARGEFILE when opening a file internally From: David Howells X-ASG-Orig-Subj: [RFC PATCH 2/2] VFS: Don't pass O_LARGEFILE when opening a file internally To: viro@zeniv.linux.org.uk Cc: dhowells@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com Date: Tue, 22 Sep 2015 16:25:00 +0100 Message-ID: <20150922152500.32539.4726.stgit@warthog.procyon.org.uk> In-Reply-To: <20150922152450.32539.55285.stgit@warthog.procyon.org.uk> References: <20150922152450.32539.55285.stgit@warthog.procyon.org.uk> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442935505 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Don't pass O_LARGEFILE when opening a file internally within the kernel because due to the preceeding commit, the flag is now assumed fixed on for all arches, not just 64-bit ones. Signed-off-by: David Howells --- drivers/media/pci/cx25821/cx25821-audio-upstream.c | 4 ++-- drivers/mtd/nand/nandsim.c | 2 +- drivers/staging/lustre/lustre/libcfs/tracefile.c | 4 ++-- drivers/target/target_core_file.c | 4 ++-- drivers/usb/gadget/function/storage_common.c | 4 ++-- fs/block_dev.c | 2 -- fs/cachefiles/rdwr.c | 2 +- fs/coredump.c | 3 +-- fs/ecryptfs/kthread.c | 4 ++-- fs/exec.c | 4 ++-- fs/nfsd/vfs.c | 6 +++--- kernel/acct.c | 2 +- mm/shmem.c | 2 +- mm/swapfile.c | 4 ++-- tools/lguest/lguest.c | 2 +- 15 files changed, 23 insertions(+), 26 deletions(-) diff --git a/drivers/media/pci/cx25821/cx25821-audio-upstream.c b/drivers/media/pci/cx25821/cx25821-audio-upstream.c index 68dbc2dbc982..aa6011bb88cf 100644 --- a/drivers/media/pci/cx25821/cx25821-audio-upstream.c +++ b/drivers/media/pci/cx25821/cx25821-audio-upstream.c @@ -271,7 +271,7 @@ static int cx25821_get_audio_data(struct cx25821_dev *dev, if (dev->_audiofile_status == END_OF_FILE) return 0; - file = filp_open(dev->_audiofilename, O_RDONLY | O_LARGEFILE, 0); + file = filp_open(dev->_audiofilename, O_RDONLY, 0); if (IS_ERR(file)) { pr_err("%s(): ERROR opening file(%s) with errno = %ld!\n", __func__, dev->_audiofilename, -PTR_ERR(file)); @@ -326,7 +326,7 @@ static int cx25821_openfile_audio(struct cx25821_dev *dev, loff_t offset; int i, j; - file = filp_open(dev->_audiofilename, O_RDONLY | O_LARGEFILE, 0); + file = filp_open(dev->_audiofilename, O_RDONLY, 0); if (IS_ERR(file)) { pr_err("%s(): ERROR opening file(%s) with errno = %ld!\n", __func__, dev->_audiofilename, PTR_ERR(file)); diff --git a/drivers/mtd/nand/nandsim.c b/drivers/mtd/nand/nandsim.c index 95d0cc49cfc2..f932022e2ff0 100644 --- a/drivers/mtd/nand/nandsim.c +++ b/drivers/mtd/nand/nandsim.c @@ -575,7 +575,7 @@ static int alloc_device(struct nandsim *ns) int i, err; if (cache_file) { - cfile = filp_open(cache_file, O_CREAT | O_RDWR | O_LARGEFILE, 0600); + cfile = filp_open(cache_file, O_CREAT | O_RDWR, 0600); if (IS_ERR(cfile)) return PTR_ERR(cfile); if (!(cfile->f_mode & FMODE_CAN_READ)) { diff --git a/drivers/staging/lustre/lustre/libcfs/tracefile.c b/drivers/staging/lustre/lustre/libcfs/tracefile.c index effa2af58c13..a862b2f21111 100644 --- a/drivers/staging/lustre/lustre/libcfs/tracefile.c +++ b/drivers/staging/lustre/lustre/libcfs/tracefile.c @@ -683,7 +683,7 @@ int cfs_tracefile_dump_all_pages(char *filename) cfs_tracefile_write_lock(); - filp = filp_open(filename, O_CREAT|O_EXCL|O_WRONLY|O_LARGEFILE, 0600); + filp = filp_open(filename, O_CREAT|O_EXCL|O_WRONLY, 0600); if (IS_ERR(filp)) { rc = PTR_ERR(filp); filp = NULL; @@ -985,7 +985,7 @@ static int tracefiled(void *arg) cfs_tracefile_read_lock(); if (cfs_tracefile[0] != 0) { filp = filp_open(cfs_tracefile, - O_CREAT | O_RDWR | O_LARGEFILE, + O_CREAT | O_RDWR, 0600); if (IS_ERR(filp)) { rc = PTR_ERR(filp); diff --git a/drivers/target/target_core_file.c b/drivers/target/target_core_file.c index e3195700211a..e7474fc79ea8 100644 --- a/drivers/target/target_core_file.c +++ b/drivers/target/target_core_file.c @@ -114,7 +114,7 @@ static int fd_configure_device(struct se_device *dev) * Use O_DSYNC by default instead of O_SYNC to forgo syncing * of pure timestamp updates. */ - flags = O_RDWR | O_CREAT | O_LARGEFILE | O_DSYNC; + flags = O_RDWR | O_CREAT | O_DSYNC; /* * Optionally allow fd_buffered_io=1 to be enabled for people @@ -732,7 +732,7 @@ static int fd_init_prot(struct se_device *dev) struct fd_dev *fd_dev = FD_DEV(dev); struct file *prot_file, *file = fd_dev->fd_file; struct inode *inode; - int ret, flags = O_RDWR | O_CREAT | O_LARGEFILE | O_DSYNC; + int ret, flags = O_RDWR | O_CREAT | O_DSYNC; char buf[FD_MAX_DEV_PROT_NAME]; if (!file) { diff --git a/drivers/usb/gadget/function/storage_common.c b/drivers/usb/gadget/function/storage_common.c index d62683017cf3..73d33930beb8 100644 --- a/drivers/usb/gadget/function/storage_common.c +++ b/drivers/usb/gadget/function/storage_common.c @@ -196,12 +196,12 @@ int fsg_lun_open(struct fsg_lun *curlun, const char *filename) /* R/W if we can, R/O if we must */ ro = curlun->initially_ro; if (!ro) { - filp = filp_open(filename, O_RDWR | O_LARGEFILE, 0); + filp = filp_open(filename, O_RDWR, 0); if (PTR_ERR(filp) == -EROFS || PTR_ERR(filp) == -EACCES) ro = 1; } if (ro) - filp = filp_open(filename, O_RDONLY | O_LARGEFILE, 0); + filp = filp_open(filename, O_RDONLY, 0); if (IS_ERR(filp)) { LINFO(curlun, "unable to open backing file: %s\n", filename); return PTR_ERR(filp); diff --git a/fs/block_dev.c b/fs/block_dev.c index 22ea424ee741..170abedc983a 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -1462,8 +1462,6 @@ static int blkdev_open(struct inode * inode, struct file * filp) * binary needs it. We might want to drop this workaround * during an unstable branch. */ - filp->f_flags |= O_LARGEFILE; - if (filp->f_flags & O_NDELAY) filp->f_mode |= FMODE_NDELAY; if (filp->f_flags & O_EXCL) diff --git a/fs/cachefiles/rdwr.c b/fs/cachefiles/rdwr.c index 3cbb0e834694..9b0c7348cf22 100644 --- a/fs/cachefiles/rdwr.c +++ b/fs/cachefiles/rdwr.c @@ -909,7 +909,7 @@ int cachefiles_write_page(struct fscache_storage *op, struct page *page) * own time */ path.mnt = cache->mnt; path.dentry = object->backer; - file = dentry_open(&path, O_RDWR | O_LARGEFILE, cache->cache_cred); + file = dentry_open(&path, O_RDWR, cache->cache_cred); if (IS_ERR(file)) { ret = PTR_ERR(file); } else { diff --git a/fs/coredump.c b/fs/coredump.c index a8f75640ac86..8e4a0feb145d 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -667,8 +667,7 @@ void do_coredump(const siginfo_t *siginfo) * writes its coredump successfully, not which one. */ cprm.file = filp_open(cn.corename, - O_CREAT | 2 | O_NOFOLLOW | - O_LARGEFILE | O_EXCL, + O_CREAT | 2 | O_NOFOLLOW | O_EXCL, 0600); if (IS_ERR(cprm.file)) goto fail_unlock; diff --git a/fs/ecryptfs/kthread.c b/fs/ecryptfs/kthread.c index 866bb18efefe..3fef39d3345f 100644 --- a/fs/ecryptfs/kthread.c +++ b/fs/ecryptfs/kthread.c @@ -74,7 +74,7 @@ static int ecryptfs_threadfn(void *ignored) kthread_ctl_list); list_del(&req->kthread_ctl_list); *req->lower_file = dentry_open(&req->path, - (O_RDWR | O_LARGEFILE), current_cred()); + O_RDWR, current_cred()); complete(&req->done); } mutex_unlock(&ecryptfs_kthread_ctl.mux); @@ -133,7 +133,7 @@ int ecryptfs_privileged_open(struct file **lower_file, const struct cred *cred) { struct ecryptfs_open_req req; - int flags = O_LARGEFILE; + int flags = 0; int rc = 0; init_completion(&req.done); diff --git a/fs/exec.c b/fs/exec.c index b06623a9347f..35668aaa3400 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -118,7 +118,7 @@ SYSCALL_DEFINE1(uselib, const char __user *, library) struct filename *tmp = getname(library); int error = PTR_ERR(tmp); static const struct open_flags uselib_flags = { - .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, + .open_flag = O_RDONLY | __FMODE_EXEC, .acc_mode = MAY_READ | MAY_EXEC | MAY_OPEN, .intent = LOOKUP_OPEN, .lookup_flags = LOOKUP_FOLLOW, @@ -762,7 +762,7 @@ static struct file *do_open_execat(int fd, struct filename *name, int flags) struct file *file; int err; struct open_flags open_exec_flags = { - .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, + .open_flag = O_RDONLY | __FMODE_EXEC, .acc_mode = MAY_EXEC | MAY_OPEN, .intent = LOOKUP_OPEN, .lookup_flags = LOOKUP_FOLLOW, diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c index 45c04979e7b3..41adbadf9a01 100644 --- a/fs/nfsd/vfs.c +++ b/fs/nfsd/vfs.c @@ -640,7 +640,7 @@ nfsd_open(struct svc_rqst *rqstp, struct svc_fh *fhp, umode_t type, struct path path; struct inode *inode; struct file *file; - int flags = O_RDONLY|O_LARGEFILE; + int flags = O_RDONLY; __be32 err; int host_err = 0; @@ -690,9 +690,9 @@ nfsd_open(struct svc_rqst *rqstp, struct svc_fh *fhp, umode_t type, if (may_flags & NFSD_MAY_WRITE) { if (may_flags & NFSD_MAY_READ) - flags = O_RDWR|O_LARGEFILE; + flags = O_RDWR; else - flags = O_WRONLY|O_LARGEFILE; + flags = O_WRONLY; } file = dentry_open(&path, flags, current_cred()); diff --git a/kernel/acct.c b/kernel/acct.c index 74963d192c5d..c292fdf35757 100644 --- a/kernel/acct.c +++ b/kernel/acct.c @@ -201,7 +201,7 @@ static int acct_on(struct filename *pathname) return -ENOMEM; /* Difference from BSD - they don't do O_APPEND */ - file = file_open_name(pathname, O_WRONLY|O_APPEND|O_LARGEFILE, 0); + file = file_open_name(pathname, O_WRONLY|O_APPEND, 0); if (IS_ERR(file)) { kfree(acct); return PTR_ERR(file); diff --git a/mm/shmem.c b/mm/shmem.c index 48ce82926d93..4073e785cda4 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -2968,7 +2968,7 @@ SYSCALL_DEFINE2(memfd_create, } info = SHMEM_I(file_inode(file)); file->f_mode |= FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE; - file->f_flags |= O_RDWR | O_LARGEFILE; + file->f_flags |= O_RDWR; if (flags & MFD_ALLOW_SEALING) info->seals &= ~F_SEAL_SEAL; diff --git a/mm/swapfile.c b/mm/swapfile.c index 58877312cf6b..53e854ab0960 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -1863,7 +1863,7 @@ SYSCALL_DEFINE1(swapoff, const char __user *, specialfile) if (IS_ERR(pathname)) return PTR_ERR(pathname); - victim = file_open_name(pathname, O_RDWR|O_LARGEFILE, 0); + victim = file_open_name(pathname, O_RDWR, 0); err = PTR_ERR(victim); if (IS_ERR(victim)) goto out; @@ -2419,7 +2419,7 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags) name = NULL; goto bad_swap; } - swap_file = file_open_name(name, O_RDWR|O_LARGEFILE, 0); + swap_file = file_open_name(name, O_RDWR, 0); if (IS_ERR(swap_file)) { error = PTR_ERR(swap_file); swap_file = NULL; diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c index 80159e6811c2..a82e6bc0978e 100644 --- a/tools/lguest/lguest.c +++ b/tools/lguest/lguest.c @@ -3046,7 +3046,7 @@ static void setup_block_file(const char *filename) vblk = dev->priv = malloc(sizeof(*vblk)); /* First we open the file and store the length. */ - vblk->fd = open_or_die(filename, O_RDWR|O_LARGEFILE); + vblk->fd = open_or_die(filename, O_RDWR); vblk->len = lseek64(vblk->fd, 0, SEEK_END); /* Tell Guest how many sectors this device has. */ From tytso@thunk.org Tue Sep 22 10:51:12 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6E79A7F51 for ; Tue, 22 Sep 2015 10:51:12 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 5AA128F8037 for ; Tue, 22 Sep 2015 08:51:09 -0700 (PDT) X-ASG-Debug-ID: 1442937066-04cbb033b27e740001-NocioJ Received: from imap.thunk.org (imap.thunk.org [74.207.234.97]) by cuda.sgi.com with ESMTP id 983vMmIaC6JDGqgM (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 22 Sep 2015 08:51:07 -0700 (PDT) X-Barracuda-Envelope-From: tytso@thunk.org X-Barracuda-Apparent-Source-IP: 74.207.234.97 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=tjWeqbhWy2TSUk82kKay+UONkzoCBgWGuyMMMk0QLgY=; b=xV5bhGjVnJ1McUMETc+bnT75HBd7+2TkJoRXnQ5pDKf8avSvD8TO2//tkNvZK5fOg657NhjQFf5qqdhLCVdos9xCEKoYcYMvuIhL0fKODxXXn07s3Kw7TNwuJd88417V4LzMpC9JMTXbw98ojq+uTogqUc5dZYQd4/yu/0oLQ5A=; Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.84) (envelope-from ) id 1ZePqS-0000Tb-LP; Tue, 22 Sep 2015 15:51:04 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 30A8D82CDF4; Tue, 22 Sep 2015 11:51:04 -0400 (EDT) Date: Tue, 22 Sep 2015 11:51:04 -0400 From: Theodore Ts'o To: David Howells Cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel Message-ID: <20150922155104.GA2296@thunk.org> X-ASG-Orig-Subj: Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel Mail-Followup-To: Theodore Ts'o , David Howells , viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <20150922152450.32539.55285.stgit@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150922152450.32539.55285.stgit@warthog.procyon.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false X-Barracuda-Connect: imap.thunk.org[74.207.234.97] X-Barracuda-Start-Time: 1442937066 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22786 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 On Tue, Sep 22, 2015 at 04:24:50PM +0100, David Howells wrote: > > (4) fs/open.c: Length check in ftruncate(). > > (5) fs/open.c: Length check in generic_file_open(). > > All but the first two are just making length checks that are waived > unconditionally on a 64-bit system. Just skip the length checks, assuming > that O_LARGEFILE is actually set. So what this means is that on 32-bit systems, if we have a userspace program which isn't using the Largefile-enabled, and it opens a file which is larger than can be addressed with a 32-bit off_t, it can get surprised and possibly cause data loss. Is this something we are willing to live with? After all, there was a originally a really good reason for the O_LARGEFILE flag in the first place, and it was primarily about making sure that a non-LARGEFILE capable program would hard fail on the open, instead of after it had trashed the user's data. Granted that 32-bit systems are rarer these days, and hopefully this isn't a situation that would come up that often in embedded systems, but if breaking this functionality is something that we are deliberately going to be doing, we should discuss it explicitly, and document the decision in the commit message. Was there a reason that motivated this change, other than just an clean up? - Ted From dhowells@redhat.com Tue Sep 22 11:12:52 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 006D67F37 for ; Tue, 22 Sep 2015 11:12:52 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 060CDAC00A for ; Tue, 22 Sep 2015 09:12:48 -0700 (PDT) X-ASG-Debug-ID: 1442938367-04cbb033b27f200001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Nol3J3Ok1zFl8SZd (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 09:12:47 -0700 (PDT) X-Barracuda-Envelope-From: dhowells@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id CB911C0B2B58; Tue, 22 Sep 2015 16:12:46 +0000 (UTC) Received: from warthog.procyon.org.uk ([10.3.112.5]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MGChVE022275; Tue, 22 Sep 2015 12:12:44 -0400 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <20150922155104.GA2296@thunk.org> References: <20150922155104.GA2296@thunk.org> <20150922152450.32539.55285.stgit@warthog.procyon.org.uk> To: "Theodore Ts'o" Cc: dhowells@redhat.com, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel Content-Type: text/plain; charset="us-ascii" Content-ID: <1457.1442938362.1@warthog.procyon.org.uk> Date: Tue, 22 Sep 2015 17:12:42 +0100 Message-ID: <1458.1442938362@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1442938367 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Theodore Ts'o wrote: > So what this means is that on 32-bit systems, if we have a userspace > program which isn't using the Largefile-enabled, and it opens a file > which is larger than can be addressed with a 32-bit off_t, it can get > surprised and possibly cause data loss. Good point. I was initially thinking that 32-bit userspace on a 64-bit system would have O_LARGEFILE automatically enabled - but I guess it'll trap through the compat entry points which avoid that. That said, fanotify and xfs_open_by_handle() will both automatically set O_LARGEFILE irrespectively of the 32-bitness of the original caller. Further, path-based truncate() makes no checks based on file-largeness, unlike ftruncate(). > Is this something we are willing to live with? After all, there was a > originally a really good reason for the O_LARGEFILE flag in the first > place, and it was primarily about making sure that a non-LARGEFILE > capable program would hard fail on the open, instead of after it had > trashed the user's data. Okay, that seems reasonable - but it still leaves truncate() dangling. I'm not sure there's a good answer to that, though. > Was there a reason that motivated this change, other than just an > clean up? Overlayfs and one or two other places need to potentially apply O_LARGEFILE to the things that they do on behalf of userspace - but other than suppressing some size checks, it seems to be ignored by the filesystems and the VM. I vaguely seem to remember that at one point there were still filesystems that couldn't handle large files and would reject such opens - but they appear to all have been fixed. David From penguin-kernel@I-love.SAKURA.ne.jp Tue Sep 22 11:34:52 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2DFB67F37 for ; Tue, 22 Sep 2015 11:34:52 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 1A35E30404E for ; Tue, 22 Sep 2015 09:34:51 -0700 (PDT) X-ASG-Debug-ID: 1442939687-04cb6c6b07723f0001-NocioJ Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by cuda.sgi.com with ESMTP id 6eCgAh6nQXJe0J6v (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 22 Sep 2015 09:34:48 -0700 (PDT) X-Barracuda-Envelope-From: penguin-kernel@I-love.SAKURA.ne.jp X-Barracuda-Apparent-Source-IP: 202.181.97.72 Received: from fsav105.sakura.ne.jp (fsav105.sakura.ne.jp [27.133.134.232]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8MGYgHl043072; Wed, 23 Sep 2015 01:34:42 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav105.sakura.ne.jp (F-Secure/fsigk_smtp/522/fsav105.sakura.ne.jp); Wed, 23 Sep 2015 01:34:42 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/522/fsav105.sakura.ne.jp) Received: from ccsecurity.localdomain (softbank126074231104.bbtec.net [126.74.231.104]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id t8MGYcdh043052 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 23 Sep 2015 01:34:42 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) From: Tetsuo Handa To: linux-mm@kvack.org Cc: xfs@oss.sgi.com, Tetsuo Handa Subject: [PATCH] mm/page_alloc: Favor kthread and dying threads over normal threads Date: Wed, 23 Sep 2015 01:34:28 +0900 X-ASG-Orig-Subj: [PATCH] mm/page_alloc: Favor kthread and dying threads over normal threads Message-Id: <1442939668-4421-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> X-Mailer: git-send-email 1.8.3.1 X-Barracuda-Connect: www262.sakura.ne.jp[202.181.97.72] X-Barracuda-Start-Time: 1442939688 X-Barracuda-Encrypted: DHE-RSA-CAMELLIA256-SHA X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22787 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header shrink_inactive_list() and throttle_direct_reclaim() are expecting that dying threads should not be throttled so that they can leave memory allocator functions and exit and release their memory shortly. Also, throttle_direct_reclaim() is expecting that kernel threads should not be throttled as they may be indirectly responsible for cleaning pages necessary for reclaim to make forward progress. Currently __GFP_WAIT && order <= PAGE_ALLOC_COSTLY_ORDER && !__GFP_NORETRY && !__GFP_NOFAIL allocation requests implicitly retry forever unless TIF_MEMDIE is set by the OOM killer. Also, currently the OOM killer sets TIF_MEMDIE to only one thread even if there are 1000 threads sharing the mm struct. All threads get SIGKILL and are treated as dying thread, but only OOM victim threads with TIF_MEMDIE are favored at several locations in memory allocator functions. While OOM victim threads without TIF_MEMDIE can acquire TIF_MEMDIE by calling out_of_memory(), they cannot acquire TIF_MEMDIE unless they are doing __GFP_FS allocations. Therefore, __GFP_WAIT && order <= PAGE_ALLOC_COSTLY_ORDER && !__GFP_NORETRY && !__GFP_NOFAIL && !__GFP_FS allocation requests by dying threads and kernel threads are throttled by above-mentioned implicit retry loop because they are using watermark for normal threads' normal allocation requests. The effect of this throttling becomes visible on XFS (like kernel messages shown below) if we revert commit cc87317726f8 ("mm: page_alloc: revert inadvertent !__GFP_FS retry behavior change"). [ 66.089978] Kill process 8505 (a.out) sharing same memory [ 69.748060] XFS: a.out(8082) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 69.798580] XFS: kworker/u16:28(381) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 69.876952] XFS: xfs-data/sda1(399) possible memory allocation deadlock in kmem_alloc (mode:0x8250) [ 70.359518] XFS: a.out(8412) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 73.299509] XFS: kworker/u16:28(381) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 73.470350] XFS: xfs-data/sda1(399) possible memory allocation deadlock in kmem_alloc (mode:0x8250) [ 73.664420] XFS: a.out(8082) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 73.967434] XFS: a.out(8412) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 76.950038] XFS: kworker/u16:28(381) possible memory allocation deadlock in xfs_buf_allocate_memory (mode:0x250) [ 76.957938] XFS: xfs-data/sda1(399) possible memory allocation deadlock in kmem_alloc (mode:0x8250) Favoring only TIF_MEMDIE threads is prone to cause OOM livelock. Also, favoring only dying threads still causes OOM livelock because sometimes dying threads depend on memory allocations issued by kernel threads (like kernel messages shown above). Kernel threads and dying threads (especially OOM victim threads) want higher priority than normal threads. This patch favors them (as with throttle_direct_reclaim()) by implicitly applying ALLOC_HIGH priority. This patch should help handling OOM events where a multi-threaded program (e.g. java) is chosen as an OOM victim when the victim is contended on unkillable locks (e.g. inode's mutex). Presumably we don't need to apply ALLOC_NO_WATERMARKS priority for TIF_MEMDIE threads if we evenly favor all OOM victim threads. But it is outside of this patch's scope because we after all need to handle cases where killing other threads is necessary for OOM victim threads to make forward progress. Signed-off-by: Tetsuo Handa --- mm/page_alloc.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 9bcfd70..f0c9098 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3010,6 +3010,13 @@ gfp_to_alloc_flags(gfp_t gfp_mask) ((current->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))) alloc_flags |= ALLOC_NO_WATERMARKS; + /* + * Favor kernel threads and dying threads like + * shrink_inactive_list() and throttle_direct_reclaim(). + */ + else if (!atomic && ((current->flags & PF_KTHREAD) || + fatal_signal_pending(current))) + alloc_flags |= ALLOC_HIGH; } #ifdef CONFIG_CMA if (gfpflags_to_migratetype(gfp_mask) == MIGRATE_MOVABLE) -- 1.8.3.1 From tytso@thunk.org Tue Sep 22 14:25:35 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 2EC8B7F37 for ; Tue, 22 Sep 2015 14:25:35 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 0DBF98F8035 for ; Tue, 22 Sep 2015 12:25:32 -0700 (PDT) X-ASG-Debug-ID: 1442949929-04cb6c6b04771e0001-NocioJ Received: from imap.thunk.org (imap.thunk.org [74.207.234.97]) by cuda.sgi.com with ESMTP id 3sbLCgbDOjVC9lE0 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 22 Sep 2015 12:25:29 -0700 (PDT) X-Barracuda-Envelope-From: tytso@thunk.org X-Barracuda-Apparent-Source-IP: 74.207.234.97 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=VSqQmBgWaYDlOJbjDHDiKmM2qqury2uzKP+XR/WK5l8=; b=pNkmNV9Za6GAbU0Dvv8Shd8Go01nMmnvvqe/N59SBby98+cBPzyDixZauUUm6Z+H5h7wHaJ3Y05P3VN74Z8GBz5OIh7YeQoHZFlYHzH6Ex6yYt8X4pG8n5w+Z5aB8w7eolJlMVmELcsKIOOFt9njLeFqnKza1X4rntwMm+8Xcuk=; Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.84) (envelope-from ) id 1ZeTBv-0002j3-Nw; Tue, 22 Sep 2015 19:25:27 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 46C9282CC8E; Tue, 22 Sep 2015 15:25:27 -0400 (EDT) Date: Tue, 22 Sep 2015 15:25:27 -0400 From: Theodore Ts'o To: David Howells Cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel Message-ID: <20150922192527.GA3318@thunk.org> X-ASG-Orig-Subj: Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel Mail-Followup-To: Theodore Ts'o , David Howells , viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <20150922155104.GA2296@thunk.org> <20150922152450.32539.55285.stgit@warthog.procyon.org.uk> <1458.1442938362@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1458.1442938362@warthog.procyon.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false X-Barracuda-Connect: imap.thunk.org[74.207.234.97] X-Barracuda-Start-Time: 1442949929 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22795 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 On Tue, Sep 22, 2015 at 05:12:42PM +0100, David Howells wrote: > > Further, path-based truncate() makes no checks based on file-largeness, unlike > ftruncate(). Right, but truncate in general is used to make files *smaller* so I'm having trouble thinking of a scenario where a largefile-oblivious program could get in trouble by truncating a file > 2TB to some hard-coded length (normally zero). > Overlayfs and one or two other places need to potentially apply O_LARGEFILE to > the things that they do on behalf of userspace - but other than suppressing > some size checks, it seems to be ignored by the filesystems and the VM. The size checks really were the primary points of O_LARGEFILE. As I recall the primary system calls where this really matters is open(2) and stat(2) (since if st_size is too small to represent the size of the file, then the user space program could get really confused). Essentially O_LARGEFILE is an assertion that userspace can handle handle 64-bit files, and won't get confused by system call interfaces where off_t is 32-bit wide, because it will use the 64-bit variants. So it's not at all surprising that the file systems and the VM in general doesn't need to worry about the flag. - Ted From david@fromorbit.com Tue Sep 22 16:27:49 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 3444D7F37 for ; Tue, 22 Sep 2015 16:27:49 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 0F48D8F8040 for ; Tue, 22 Sep 2015 14:27:48 -0700 (PDT) X-ASG-Debug-ID: 1442957262-04cb6c6b0579ec0001-NocioJ Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id j4kHdxvIO8OGgPmA for ; Tue, 22 Sep 2015 14:27:43 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CoMgB+xgFWPOV8LHldgyRULD2CXKZGDwEBAQEBAQZERolsilFdhXMCAgEBAoFMTQEBAQEBAQcBAQEBQT9BA4NgAQEBAwEnExwjBQsIAxgJJQ8FJQMHGhOIJgcOyxoBAQEBAQUBAQEBGgQZhhOFRIUNB4QsBZI+gymFEYJuhQWBU4Q2kTKDbYR2LDOHEIJdAQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail06.adl6.internode.on.net with ESMTP; 23 Sep 2015 06:57:41 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeV6C-0001RB-N8; Wed, 23 Sep 2015 07:27:40 +1000 Date: Wed, 23 Sep 2015 07:27:40 +1000 From: Dave Chinner To: Angelo Dureghello Cc: xfs@oss.sgi.com Subject: Re: xfstests, bad generic tests 009 and 308 Message-ID: <20150922212740.GJ19114@dastard> X-ASG-Orig-Subj: Re: xfstests, bad generic tests 009 and 308 References: <55FC3E0E.9060506@nomovok.com> <20150918224412.GE26895@dastard> <55FFE665.7040004@nomovok.com> <20150921225244.GD19114@dastard> <56014C62.1070403@nomovok.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56014C62.1070403@nomovok.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1442957262 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22800 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words On Tue, Sep 22, 2015 at 02:41:06PM +0200, Angelo Dureghello wrote: > >>I have a 16MB partition, and wondering why xfs allows from test 308 > >>to create a 16TB file. > >> > >>-rw------- 1 root root 17592186044415 Sep 18 09:40 testfile.308 > >https://en.wikipedia.org/wiki/Sparse_file > > > >>QA output created by 009 > >> 1. into a hole > >>0: [0..39]: hole > >>daa100df6e6711906b61c9ab5aa16032 > >> 2. into allocated space > >>cc58a7417c2d7763adc45b6fcd3fa024 > >> 3. into unwritten space > >>daa100df6e6711906b61c9ab5aa16032 > >I don't need to look any further to see that something is badly > >wrong here. This is telling me that no extents are being allocated > >at all, which indicates either fiemap is broken, awk/sed is > >broken or misbehaving (and hence mangling the output) or something > >deep in the filesystem code is fundamentally broken in some > >strange, silent way. > > > >Can you create an xfs filesystem on your scratch device, and > >manually run this command and post the output: > > > ># mkfs.xfs -V > ># mkfs.xfs > ># mount /mnt/xfs > ># xfs_io -f -c "pwrite 0 64k" -c sync \ > > -c "bmap -vp" -c "fiemap -v" \ > > -c "falloc 1024k 256k" -c sync \ > > -c "pwrite 1088k 64k" -c sync \ > > -c "bmap -vp" -c "fiemap -v" \ > > /mnt/xfs/testfile > > > >and attach the entire output? > > I attached the output. Urk, the command should be "fsync", not "sync". Regardless, the last bmap/fiemap pair shows something interesting: bmap-vp: > /media/p6/testfile: > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS > 0: [0..127]: 96..223 0 (96..223) 128 00000 > 1: [128..2047]: hole 1920 > 2: [2048..2559]: 2144..2655 0 (2144..2655) 512 10000 fiemap -v: > /media/p6/testfile: > EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS > 0: [0..127]: 96..223 128 0x0 > 1: [128..2047]: hole 1920 > 2: [2048..2175]: 2144..2271 128 0x800 > 3: [2176..2303]: 2272..2399 128 0x0 > 4: [2304..2559]: 2400..2655 256 0x801 Note that they are different - the former shows an unwritten extent of 256k @ offset 1MB, the later shows that extent split by 64k of data @ 1088k. The bmap -vp output is incorrect - it is supposed to sync data first and so should look the same as the fiemap output. Can you run this test again, this time with s/sync/fsync so the files are clean when bmap/fiemap are run? Can you run it a second time (umount/mkfs again) but with fiemap run first? i.e '-c "fiemap -v" -c "bmap -vp" \' instead of the original order? Next, can you compile your kernel with CONFIG_XFS_DEBUG=y and rerun the tests? Does anything interesting appear in dmesg during the test run? > I can be completely wrong, but file system > seems quite reliable for rootfs operations until now. At least, > never had any issue after installing and removing several and several > debian packages. right, normal distro operation doesn't use preallocation or hole punching, so you won't have seen issues with that. > Ok, about test 308, the 2 xfs_io operations passes, it stops on the > rm exiting > the tests, while trying to erase the 16t file. > > # Create a sparse file with an extent lays at one block before old > s_maxbytes > offset=$(((2**32 - 2) * $block_size)) > $XFS_IO_PROG -f -c "pwrite $offset $block_size" -c fsync $testfile > >$seqres.full 2>&1 > > rm can remove remove correctly this file (17592186040320) What is the large number here? offset: (2**32 - 2) * 4096 = 17592186036224 end file size: (2**32 - 2) * 4096 + 4096 = 17592186040320 So it is the end file size. > # Write to the block after the extent just created > offset=$(((2**32 - 1) * $block_size)) > $XFS_IO_PROG -f -c "pwrite $offset $block_size" -c fsync $testfile > >>$seqres.full 2>&1 This should fail with -EFBIG > while rm hangs on removing this file (17592186044415) offset: (2**32 - 1) * 4096 = 17592186040320 end file size: (2**32 - 1) * 4096 + 4096 = 17592186044416 Hmmm - that file is truncated by one byte. We set sb->s_maxbytes to 17592186044415 in xfs_max_file_offset() on 32 bit systems, so this truncation is expected. Most definitely need to run this under CONFIG_XFS_DEBUG=y - you should enable this whenever running xfstests to check things are working correctly as it enables all sorts of internal consistency and constraint checking (i.e. checking things that "should never, ever happen" haven't actually occurred). > Magic sysrq l or t is not helping, nothing useful comes out. > But i collected the strace log. Since the issue is at unlinkat(). Not actually useful - I need to know what is happening inside the unlinkat() call. I'm going to need a trace-cmd event dump of that xfs_io command and the subsequent rm (at least for the first couple of seconds of the rm). Please put the output file from the trace-cmd record command on a tmpfs filesystem so it doesn't pollute the xfs event trace ;) Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Tue Sep 22 16:45:16 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 15E687F37 for ; Tue, 22 Sep 2015 16:45:16 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id B1C7CAC00E for ; Tue, 22 Sep 2015 14:45:12 -0700 (PDT) X-ASG-Debug-ID: 1442958310-04bdf0462881750001-NocioJ Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id iRFiaSaUT5TzIz5b for ; Tue, 22 Sep 2015 14:45:10 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2A1CwBCywFWPOV8LHldgySBPYJcg32iWAEBAQEBAQaKdpEhAgIBAQKBTE0BAQEBAQEHAQEBAUE/hCUBAQQ6HCMQCAMOCgklDwUlAwcaE4gtyyoBAQgCAR8ZhhOFRIUNB4QsBZVnjQSPBIwkgnQcgWYsM4ltAQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail06.adl6.internode.on.net with ESMTP; 23 Sep 2015 07:15:09 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeVN5-0001Wu-VX; Wed, 23 Sep 2015 07:45:08 +1000 Date: Wed, 23 Sep 2015 07:45:07 +1000 From: Dave Chinner To: David Howells Cc: Theodore Ts'o , linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel Message-ID: <20150922214507.GK19114@dastard> X-ASG-Orig-Subj: Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel References: <20150922155104.GA2296@thunk.org> <20150922152450.32539.55285.stgit@warthog.procyon.org.uk> <1458.1442938362@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1458.1442938362@warthog.procyon.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1442958310 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22800 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 22, 2015 at 05:12:42PM +0100, David Howells wrote: > Theodore Ts'o wrote: > > > So what this means is that on 32-bit systems, if we have a userspace > > program which isn't using the Largefile-enabled, and it opens a file > > which is larger than can be addressed with a 32-bit off_t, it can get > > surprised and possibly cause data loss. > > Good point. I was initially thinking that 32-bit userspace on a 64-bit system > would have O_LARGEFILE automatically enabled - but I guess it'll trap through > the compat entry points which avoid that. > > That said, fanotify and xfs_open_by_handle() will both automatically set > O_LARGEFILE irrespectively of the 32-bitness of the original caller. Any binaries that use xfs_open_by_handle() and then don't support greater than 32bit file offsets are simply broken. No ifs or buts - if you are using low level XFS specific file access ioctls, you need to build binaries that support 64 bit offsets. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Tue Sep 22 17:01:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 7574E7F37 for ; Tue, 22 Sep 2015 17:01:05 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 60799304032 for ; Tue, 22 Sep 2015 15:00:59 -0700 (PDT) X-ASG-Debug-ID: 1442959256-04cbb033b3881d0001-NocioJ Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id HuEqmF5jBlV052yt for ; Tue, 22 Sep 2015 15:00:56 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2A1CwCyzgFWPOV8LHldgySBPYJcg32iWAEBAQEBAQaKdpEhAgIBAQKBTk0BAQEBAQEHAQEBAUE/hCUBAQQnExwjEAgDDgoJJQ8FJQMHGhOILcsoAQEIAgEfGYYThUSFDQeELAWMfYhqjQSBU4dXhVqIN4NthHYsM4ltAQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail06.adl6.internode.on.net with ESMTP; 23 Sep 2015 07:30:55 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeVcM-0001Z7-5J; Wed, 23 Sep 2015 08:00:54 +1000 Date: Wed, 23 Sep 2015 08:00:54 +1000 From: Dave Chinner To: Brian Foster Cc: xfs@oss.sgi.com Subject: Re: [PATCH] xfs_io: Implement inodes64 command Message-ID: <20150922220054.GL19114@dastard> X-ASG-Orig-Subj: Re: [PATCH] xfs_io: Implement inodes64 command References: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> <20150921220832.GB19114@dastard> <20150922075432.GC26699@redhat.com> <20150922122238.GA46026@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150922122238.GA46026@bfoster.bfoster> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1442959256 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22802 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 22, 2015 at 08:22:39AM -0400, Brian Foster wrote: > On Tue, Sep 22, 2015 at 09:54:32AM +0200, Carlos Maiolino wrote: > > On Tue, Sep 22, 2015 at 08:08:32AM +1000, Dave Chinner wrote: > > > On Mon, Sep 21, 2015 at 10:56:08AM +0200, Carlos Maiolino wrote: > ... > > > > + > > > > + bulkreq.lastip = &last; > > > > + bulkreq.icount = 1; > > > > + bulkreq.ubuffer = &igroup; > > > > + bulkreq.ocount = &count; > > > > + > > > > + if (!xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { > > > > + if (count > 0) { > > > > + printf("Filesystem does have 64bit inodes\n"); > > > > + return 0; > > > > + } else { > > > > + printf("Filesystem does not have 64bit inodes\n"); > > > > + return 0; > > > > + } > > > > + } > > > > + perror("xfsctl(XFS_IOC_FSINUMBERS)"); > > > > > > I'd do this the other way around: > > > > > > if (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { > > > perror("XFS_IOC_FSINUMBERS"); > > > exitcode = 1; > > > return 0; > > > } > > > > > > if (count > 0) > > > printf("Filesystem does have 64bit inodes\n"); > > > else > > > printf("Filesystem does not have 64bit inodes\n"); > > > return 0; > > > > > > is sufficient, xfsctl is a one line wrapper around ioctl(). > > > > > > > Ok, I'll change this, but, just a matter of curiosity, what are the technical > > reasons to write the conditional this way, instead of the way I wrote first? > > Just to avoid entering the conditional? > > > > Not to speak for Dave, but I had the same thought just skimming through > the patch. I don't think it's a technical reason so much as a style one. > The further the function is grown, the easier it is to see that this > kind of flow is not the most friendly thing. E.g.: > > ret = do_stuff(); > if (!ret) { > ... > ret = do_more_stuff(); > if (!ret) { > ... > } > } > > In other words, the common execution path of the function starts to flow > "inward" rather than the natural top-down flow of the function: > > ret = do_stuff(); > if (ret) > handle_err; > > ret = do_more_stuff(); > if (ret) > handle_err; > ... > > The latter tends to be easier to follow, easier to review the error > handling cases, probably avoids indentation problems down the road, etc. > The function as it is right now is simple and so this probably isn't a > big deal, but I suspect seeing the latter form so frequently in all of > our other code is probably what causes something like the former to > stand out (even in a simple/harmless example). Just my .02. :) That's pretty much it from a code maintenance POV. Also, though, consider how the compiler optimises code - the code inside an if () condition usually involves resolving a branch due to a jump statement to somewhere else. IOWs, your original code might end up looking something like this: if (condition) goto L1 ret: return L1: if (condition) goto L2 goto ret; L2: if (condition) goto L3 goto ret; L3: ..... and so a series of nested conditions results in lots of branches beign taken during the fast path execution. That leads to a larger CPU instruction cache footprint that the code generated from the latter case, which looks like: if (!condition) goto L1 if (!condition) goto L2 if (!condition) goto L3 ret: return L1: goto ret; L2 goto ret; L3: ..... See the difference in the fast path execution? It's compact and no branches are taken anywhere and so has a smaller instruction cache footprint. And less instruction cache misses mean faster code execution. Hence on top of the code is being easier to read, modify and maintain, and it's also much easier for the compiler to optimise into fast, efficient code.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Tue Sep 22 17:26:41 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 3B63D7F37 for ; Tue, 22 Sep 2015 17:26:41 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 09CB8304032 for ; Tue, 22 Sep 2015 15:26:40 -0700 (PDT) X-ASG-Debug-ID: 1442960797-04bdf0462782650001-NocioJ Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id AXcfvg89zT8M2YBp for ; Tue, 22 Sep 2015 15:26:38 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DHCgCS1AFWPOV8LHlTCoMkgT2CXIN9olgBAQEBAQEGinaRIQQCAoFOTQEBAQEBAQcBAQEBQT+EJQEBBDocIxAIAxgJJQ8FJQMHGhOILcspAQsgGYYThUSEKgYLAVEHhCwFkj6DKY0EgVOVaINtgnQcFoFQLDOILoE/AQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail06.adl6.internode.on.net with ESMTP; 23 Sep 2015 07:56:37 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeW1E-0001cB-M7; Wed, 23 Sep 2015 08:26:36 +1000 Date: Wed, 23 Sep 2015 08:26:36 +1000 From: Dave Chinner To: Bill O'Donnell Cc: Eric Sandeen , xfs@oss.sgi.com Subject: Re: [PATCH 5/5] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. Message-ID: <20150922222636.GM19114@dastard> X-ASG-Orig-Subj: Re: [PATCH 5/5] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. References: <1442923671-14125-1-git-send-email-billodo@redhat.com> <1442923671-14125-6-git-send-email-billodo@redhat.com> <56016A1E.8080103@sandeen.net> <20150922151605.GA29067@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150922151605.GA29067@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1442960797 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22803 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 22, 2015 at 10:16:05AM -0500, Bill O'Donnell wrote: > > > goto out; > > > > > > if (!proc_symlink("fs/xfs/stat", NULL, > > > - "/sys/fs/xfs/stats/stats")) > > > + "/sys/fs/xfs/stats/stats")) > > > > intentional whitespace changes? > > > > > goto out_remove_xfs_dir; > > > > > > #ifdef CONFIG_XFS_QUOTA > > > if (!proc_create("fs/xfs/xqmstat", 0, NULL, > > > - &xqmstat_proc_fops)) > > > + &xqmstat_proc_fops)) > > > goto out_remove_stat_file; > > > if (!proc_create("fs/xfs/xqm", 0, NULL, > > > - &xqm_proc_fops)) > > > + &xqm_proc_fops)) > > > > Same question. (did checkpatch complain or something?) > > Yes. Checkpatch didn't like any spaces, so I turned em into tabs. Checkpatch should be considered harmful. It's a good starting point, but it ends up doing more harm than good because it doesn't understand the subtle differences in code across different subsystems. In this case, the standard we use for XFS is that multi-line parameters should be lined up with the first parameter, unless the new parameters don't fit on a single line, and then we back up the indent by a tab at a time. i.e. This is correct: if (!proc_create("fs/xfs/xqm", 0, NULL, &xqm_proc_fops)) regardless of what checkpatch says. Indeed, if checkpatch had any brains, it would have noticed that a line break is not necessary as this: if (!proc_create("fs/xfs/xqm", 0, NULL, &xqm_proc_fops)) fits in 80 columns just fine. Remember that Documentation/CodingStyle is a set of guidelines, not a strict, enforcable set of rules. The basic guidelines canbe summarised as: 1. Use the same style as the existing code in the file, unless reviewers/maintainers ask otherwise. 2. new files should follow the format used in other files in the subsystem, unless reviewers/maintainer asks otherwise. 3. Do not reformat code that you don't need to directly modify in the patch. 4. modify your editor to highlight common style things that you need reminders to get right 5. Immolate checkpatch before the plague spreads further As to #4, there's plenty of simple things you can do. e.g to identify stray whitespace in files, add this to your .vimrc file (you can do similar with emacs, google it): " highlight whitespace damage highlight RedundantSpaces ctermbg=red guibg=red match RedundantSpaces /\s\+$\| \+\ze\t/ This will catch things like "tab-space-tab" and it will also find trailing whitespace at the end of lines. They will appear in red. > > > -#define XFS_STATS_INC(v) (per_cpu(xfsstats, current_cpu()).v++) > > > -#define XFS_STATS_DEC(v) (per_cpu(xfsstats, current_cpu()).v--) > > > -#define XFS_STATS_ADD(v, inc) (per_cpu(xfsstats, current_cpu()).v += (inc)) > > > +#define XFS_STATS_INC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v++) > > > +#define XFS_STATS_DEC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v--) > > > +#define XFS_STATS_ADD(v, inc) (per_cpu(*xfsstats.xs_stats, current_cpu()).v += (inc)) > > > > Line > 80 chars > > I'll fix it. Checkpatch got changed not to warn about that, because too many people complained about it when modifying files with >80 column formatting. To that end, I also use custom column width highlights based on file names so that line wrapping occurs automatically at the correct spot, and when looking at code I can clearly see long lines: " set the textwidth to 80 characters by default set tw=80 " set the textwidth to 68 characters for guilt commit messages au BufNewFile,BufRead guilt.msg.*,.gitsendemail*,.git* set tw=68 " set the textwidth to 68 characters for replies (email&usenet) au BufNewFile,BufRead .letter,mutt*,nn.*,snd.* set tw=68 " highlight textwidth set cc=+1 If you do little things like this, the need for checkpatch goes away. With a default tw=80 and a highlight, I only have to glance at a patch to know it has lines longer than 80 columns in it. As such, I haven't used checkpatch for years, and I recommend that you develop the right habits and automation such that you don't need to use it after a couple of months, either... Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Tue Sep 22 17:34:45 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id DF4427F37 for ; Tue, 22 Sep 2015 17:34:45 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id AB7EF8F8033 for ; Tue, 22 Sep 2015 15:34:42 -0700 (PDT) X-ASG-Debug-ID: 1442961280-04bdf04626828c0001-NocioJ Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id r0rXveA6Qy6Ird0Z for ; Tue, 22 Sep 2015 15:34:40 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2A1CwAB1wFWPOV8LHldgySBPYJcg32iWAEBAQEBAQaKdpEhAgIBAQKBSk0BAQEBAQEHAQEBAUE/hCQBAQEDAScTHCMFCwgDDgoJJQ8FJQMHGhOIJgfLLAErGYYThUSENFkHhCwFlWeNBJsognQcgWYsM4glgUgBAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail06.adl6.internode.on.net with ESMTP; 23 Sep 2015 08:04:03 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeW8Q-0001dP-VA; Wed, 23 Sep 2015 08:34:02 +1000 Date: Wed, 23 Sep 2015 08:34:02 +1000 From: Dave Chinner To: Mika Eloranta Cc: xfs@oss.sgi.com Subject: Re: [PATCH] mkfs.xfs: option for using a pre-defined filesystem UUID Message-ID: <20150922223402.GN19114@dastard> X-ASG-Orig-Subj: Re: [PATCH] mkfs.xfs: option for using a pre-defined filesystem UUID References: <1442924691-42001-1-git-send-email-mel@ohmu.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442924691-42001-1-git-send-email-mel@ohmu.fi> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1442961280 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22803 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 22, 2015 at 03:24:51PM +0300, Mika Eloranta wrote: > Usage: mkfs.xfs -m uuid= > > The filesystem UUID can now be optionally specified during filesystem > creation. The default behavior is still to generate a random UUID. > > Allows using pre-generated UUIDs for identifying a filesystem based > on the metadata stored inside the filesystem. Filesystem labels can > be used for the same purpose, but are limited by their length > (12 chars in the case of xfs) whereas the UUID field can store an > entire 128bit UUID, which is plenty for e.g. random ID collision > avoidance. > > Random UUID generated during the creation of the filesystem is not > always feasible when an external DB or other system is used to track > the created filesystem, e.g. in automated VM provisioning systems, > as this would require a feedback mechanism which is not always > available. In these cases the best approach often is to generate > a random UUID for the filesystem before the filesystem even exists, > store it in the tracking DB and later create the filesystem directly > with the correct UUID (instead of "mkfs.xfs + xfs_admin -U "). Much nicer! Just needs a signed-off-by tag now... > @@ -948,6 +950,7 @@ main( > bool finobtflag; > int spinodes; > > + platform_uuid_clear(&uuid); > progname = basename(argv[0]); > setlocale(LC_ALL, ""); > bindtextdomain(PACKAGE, LOCALEDIR); You can just call platform_uuid_generate(&uuid) here. > @@ -1488,6 +1491,12 @@ main( > finobt = c; > finobtflag = true; > break; > + case M_UUID: > + if (!value || *value == '\0') > + reqval('m', mopts, M_UUID); > + if (platform_uuid_parse(value, &uuid)) > + illegal(optarg, "m uuid"); > + break; This will overwrite the pre-generated uuid if it is specified. > default: > unknown('m', value); > } > @@ -2550,7 +2559,9 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"), > sbp->sb_dblocks = dblocks; > sbp->sb_rblocks = rtblocks; > sbp->sb_rextents = rtextents; > - platform_uuid_generate(&uuid); > + if (platform_uuid_is_null(&uuid)) { > + platform_uuid_generate(&uuid); > + } And this code can go away completely as we are guaranteed to have a valid uuid by this point. Cheers, Dave. -- Dave Chinner david@fromorbit.com From devon@devon.com Tue Sep 22 18:18:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=BAD_CREDIT,HTML_MESSAGE, T_FRT_CONTACT autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id A02D07F37 for ; Tue, 22 Sep 2015 18:18:40 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 7053E304032 for ; Tue, 22 Sep 2015 16:18:37 -0700 (PDT) X-ASG-Debug-ID: 1442963911-04bdf0462683690001-NocioJ Received: from smtp.jalawave.net.id (mail.jalawave.net.id [60.253.96.21]) by cuda.sgi.com with ESMTP id KTUYC0QFDeiBJIKM; Tue, 22 Sep 2015 16:18:32 -0700 (PDT) X-Barracuda-Envelope-From: devon@devon.com X-Barracuda-Apparent-Source-IP: 60.253.96.21 Received: from localhost (localhost [127.0.0.1]) by smtp.jalawave.net.id (Postfix) with ESMTP id 5FA0E2669CF3; Tue, 22 Sep 2015 21:49:01 +0700 (WIB) Received: from smtp.jalawave.net.id ([127.0.0.1]) by localhost (smtp.jalawave.net.id [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id fTULZ4UZFEPi; Tue, 22 Sep 2015 21:49:01 +0700 (WIB) Received: from localhost (localhost [127.0.0.1]) by smtp.jalawave.net.id (Postfix) with ESMTP id 6EED7266D793; Tue, 22 Sep 2015 21:49:00 +0700 (WIB) X-Virus-Scanned: amavisd-new at smtp.jalawave.net.id Received: from smtp.jalawave.net.id ([127.0.0.1]) by localhost (smtp.jalawave.net.id [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9liZk32wZ6uz; Tue, 22 Sep 2015 21:49:00 +0700 (WIB) Received: from abnmedical.com (unknown [60.253.117.83]) by smtp.jalawave.net.id (Postfix) with SMTP id 3ADC82669B7A; Tue, 22 Sep 2015 21:48:56 +0700 (WIB) Received: from [202.62.73.85] (Unknown [192.168.10.26]) by abnmedical.com with ESMTPA ; Tue, 22 Sep 2015 21:35:10 +0700 Message-ID: <58B8ACA7-45FA-4D7A-876F-3323AA099EE8@abnmedical.com> Content-Type: multipart/alternative; boundary="===============1327556786==" MIME-Version: 1.0 Subject: Re: To: Recipients X-ASG-Orig-Subj: Re: From: "Devon Financial Partners" Date: Tue, 22 Sep 2015 17:30:40 +0300 Reply-To: devonfps@gmail.com X-Barracuda-Connect: mail.jalawave.net.id[60.253.96.21] X-Barracuda-Start-Time: 1442963911 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.03 X-Barracuda-Spam-Status: No, SCORE=1.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BAD_CREDIT, BSF_SC0_SA_TO_FROM_ADDR_MATCH, BSF_SC7_SA298e, FUZZY_CREDIT, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22803 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.33 BAD_CREDIT BODY: Eliminate Bad Credit 0.00 FUZZY_CREDIT BODY: Attempt to obfuscate words in spam 0.00 HTML_MESSAGE BODY: HTML included in message 0.20 BSF_SC7_SA298e Custom Rule SA298e 0.50 BSF_SC0_SA_TO_FROM_ADDR_MATCH Sender Address Matches Recipient Address You will not see this in a MIME-aware mail reader. --===============1327556786== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body Bad Credit Willkommen. Erschwingliche Ratenkredite. Garantierte feste Verg=FCtungen. Haben Sie einen Investor brauchen? Haben Sie gesch=E4ftliche oder pers=F6nliche Darlehen ben=F6tigen? Wir geben Darlehen an jeden einzelnen und Unternehmen bei 3% Zinsen j=E4hrl= ich. F=FCr weitere Informationen, kontaktieren Sie uns per E-Mail: = HINWEIS: Leiten Sie Ihre Antwort nur an diese E-Mail: we give out loan to any individual and company at 3% interest rate yearly.= For more information, Contact us via Email:=20 --===============1327556786== Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body

Bad Credit Willkommen.
Erschwingliche Ra= tenkredite.
Garantierte feste Verg=FCtungen.
Haben Sie einen Investor= brauchen?
Haben Sie gesch=E4ftliche oder pers=F6nliche Darlehen ben=F6t= igen?
Wir geben Darlehen an jeden einzelnen und Unternehmen bei 3% Zinse= n j=E4hrlich. F=FCr weitere Informationen, kontaktieren Sie uns per E-Mail:=

HINWEIS: Leiten Sie Ihre Antwort nur an diese E-Mail:

we give out loan to any individual and company at 3% interest rate yearl= y. For more information,  Contact us via Email:

--===============1327556786==-- From david@fromorbit.com Tue Sep 22 21:08:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id D9A287F37 for ; Tue, 22 Sep 2015 21:08:08 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id B9A938F8037 for ; Tue, 22 Sep 2015 19:08:05 -0700 (PDT) X-ASG-Debug-ID: 1442974081-04bdf046228ac40001-NocioJ Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id WyWnDT8eobiD7DrO for ; Tue, 22 Sep 2015 19:08:01 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AjNgBhCAJWPOV8LHldgyQjMWmGWaJfBop2iyUChXsEgVJNAQEBAQEBBwEBAQFBP0EBAQOEOzskNAUlAwctiC2nJKQ0GYYTim+CF02BMQWSPoMphRGHc4FUhDaIOIQuhE6DbYItAQsBgjwsM4EUgVWHBAEBAQ Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail06.adl6.internode.on.net with ESMTP; 23 Sep 2015 11:38:00 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeZTT-0001zp-Ox for xfs@oss.sgi.com; Wed, 23 Sep 2015 12:07:59 +1000 Date: Wed, 23 Sep 2015 12:07:59 +1000 From: Dave Chinner To: xfs@oss.sgi.com Subject: [ANNOUNCE] xfs: master, for-next branches updated to v4.3-rc2 Message-ID: <20150923020759.GJ3902@dastard> X-ASG-Orig-Subj: [ANNOUNCE] xfs: master, for-next branches updated to v4.3-rc2 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qVHblb/y9DPlgkHs" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1442974081 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22808 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- --qVHblb/y9DPlgkHs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi folks, I've just updated the master and for-next branches of the XFs repository here: git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git to v4.3-rc2. Please update your local dev trees and rebase your current patches against this. Thanks! -Dave. --=20 Dave Chinner david@fromorbit.com --qVHblb/y9DPlgkHs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJWAgl/AAoJEK3oKUf0dfodDv4P/0kNljxs0RQrHARIjM0bCKz2 gMvFX226nBHaDhNwvRmbMLU/JVcPs83rASG6Q8MMWw9XSqB1AlqUZCf65nvlzDpi qyouR8EQ1+Sg3u7MxEOo5PBr2YixJvmQgxVDo2asEb53fWjFbYikPXm9CcQOmET8 Fj5NPPeskMxE1YgrEMeJ3hHdkd55zPNFv14EnLN7Up0n/g4iMgsrR+cE0jE7ebDR 4yJpvAdcVA3PDDVIQBACkruiuHVWSY5oceyAD9+LEmga9KUw03KqiRCFXuwU1TIy 6yp4LAZfqNofMKBsJoV5VyvbOlWZ6Kotp0gfwBzg+qpOpnM5bpQgFusfdtD8Dvwy En1m1C+8QlHusZnVWayIeMvji6bLDdTRUmxqgwgorcBp+8bB8PJPwJCsZNcoCrMj bmlmCyoLOghpiI6t6owqpUkUiRhahVhIKXt+lPzb4J2/pMI/eZ9OhaxW5807Ng8o 172npSv+WdHKBONq6HtP+vUYsEmP+22yk/RcCd4Rg/4NEAvHZt7vUExfwtJ7Co01 b1HAnw7AUk9tpLw8z67oZKiscPN9EAmkhFBjn4OsyXRlXykUJi+N+/f+aCCnP+lQ 37R/lO42JfxVCdTup9szXufQ/n6r8LEv7pmygGbjl4mLT7eILFWFkaZTmSBN+qgn v4T4uAjHlmVda/gCKQC+ =Suz+ -----END PGP SIGNATURE----- --qVHblb/y9DPlgkHs-- From ibsupports@standardbank.co.za Tue Sep 22 21:16:32 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.1 required=5.0 tests=FROM_MISSP_PHISH,HTML_MESSAGE, NORMAL_HTTP_TO_IP,TVD_PH_BODY_ACCOUNTS_PRE,T_HTML_ATTACH autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id E690D7F3F for ; Tue, 22 Sep 2015 21:16:32 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id D136B8F8040 for ; Tue, 22 Sep 2015 19:16:32 -0700 (PDT) X-ASG-Debug-ID: 1442974586-04cbb033b0926c0001-NocioJ Received: from fw7a.wadns.net (fw7a-fritz.wadns.net [41.185.82.26]) by cuda.sgi.com with ESMTP id QsgGOmN9KqLGfYo0 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 22 Sep 2015 19:16:28 -0700 (PDT) X-Barracuda-Envelope-From: ibsupports@standardbank.co.za X-Barracuda-Apparent-Source-IP: 41.185.82.26 Received: from mail11t.wadns.net ([196.220.62.121] helo=mail11.wadns.net) by fw7a.wadns.net with esmtp (Exim 4.80) (envelope-from ) id 1ZeZbT-0001jI-SP; Wed, 23 Sep 2015 04:16:16 +0200 Received: from UnknownHost [90.164.213.212] by mail11.wadns.net with SMTP; Wed, 23 Sep 2015 04:16:15 +0200 Content-Type: multipart/mixed; boundary="===============1073065771==" MIME-Version: 1.0 Subject: Re: PDF-XQMJKSMLKD2015-Deposit To: Recipients X-ASG-Orig-Subj: Re: PDF-XQMJKSMLKD2015-Deposit From: "IBSUPPORT@standardbank.co.za" Cc: You Date: Wed, 23 Sep 2015 04:10:01 +0200 X-Priority: 1 (High) X-Barracuda-Connect: fw7a-fritz.wadns.net[41.185.82.26] X-Barracuda-Start-Time: 1442974587 X-Barracuda-Encrypted: DHE-RSA-AES128-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.78 X-Barracuda-Spam-Status: No, SCORE=0.78 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MJ019, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, BSF_SC7_MJ5792, HTML_MESSAGE, MISSING_MID, NORMAL_HTTP_TO_IP, NO_REAL_NAME, SUBJECT_NOVOWEL X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22808 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 MISSING_MID Missing Message-Id: header 0.00 NO_REAL_NAME From: does not include a real name 0.13 SUBJECT_NOVOWEL Subject: has long non-vowel letter sequence 0.00 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 0.00 HTML_MESSAGE BODY: HTML included in message 0.25 BSF_SC7_MJ5792 Mismatched html tag text 0.25 BSF_SC0_MJ019 Custom Rule MJ019 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Message-Id: <20150923021632.59DBE106C09D@cuda.sgi.com> You will not see this in a MIME-aware mail reader. --===============1073065771== Content-Type: multipart/alternative; boundary="===============0178118433==" MIME-Version: 1.0 --===============0178118433== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body Online Banking Support ***** Deposit Slips Copy.******* Invoice payme= nt has been processed successfully. Statement of funds Transfer Document in PDF-XQMJKSMLKD2015-Deposit Download PDF Document Attachment to VIEW Transfer Process :- Thanks for banking with Us. --------------------------------------------------------------------------= ---------------------------------------------------------------------- =A92014 Standard Bank is a licensed financial services provider in terms o= f the Financial Advisory and Intermediary Services Act and a registered cre= dit provider in terms of the National Credit Act, registration number NCRCP= 15. d --===============0178118433== Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body
<= STRONG>
Online Banking Support
    ***** Deposit Slips Copy.*******

Invoice payment has been processed successfully.

Statement of funds Transfer Document in PDF-XQMJKSMLKD2015-Deposit

<= /STRONG>Download PDF Document Attachment to VIEW Transfer Pro= cess :-

Thanks for banking with Us.

--------------------------------------------------------------= ----------------------------------------------------------------------------------

=A92014 Standard Bank is a licensed financial services provider in terms= of the Financial Advisory and Intermediary Services Act and a registered c= redit provider in terms of the National Credit Act, registration number NCR= CP15. d

 --===============0178118433==-- --===============1073065771== MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="XQMJKSMLKD2015-Deposit.htm" =EF=BB=BF Internet banking

Internet banking




Login


Please enter your password.

=

By logging on I acknowledge that I have read, understood and am bound by the version of the Electronic Banking Agreement that is posted on the website at the time of logging on. (Last updated: 27 September 2013)

Registration


Customer Care Line

South Africa
0860 123 000

International
+27 11 299 4701

Email
Send us an email




3D"Movingforwardtrademarklo=

=C2=A9 2014 Standard bank is a licensed = financial services provider in terms of the Financial Advisory and Intermed= iary Services Act.

--===============1073065771==-- From david@fromorbit.com Tue Sep 22 22:09:12 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 5F8B77F37 for ; Tue, 22 Sep 2015 22:09:12 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 439FD8F8035 for ; Tue, 22 Sep 2015 20:09:09 -0700 (PDT) X-ASG-Debug-ID: 1442977743-04bdf046288c220001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id Z4JKa2qE0rxAUzok for ; Tue, 22 Sep 2015 20:09:03 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AXCADnFgJWPOV8LHldgySBPYZZol8GinaRIgICAQECgU9NAQEBAQEBBwEBAQFBP4QlAQEEOhwjEAgDDgoJJQ8FJQMHGhOILcslAQsgGYYThUSFDQeELAEElWeNBI8GjCWEdiwziW0BAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 23 Sep 2015 12:39:02 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeaQX-00026n-Tq; Wed, 23 Sep 2015 13:09:01 +1000 Date: Wed, 23 Sep 2015 13:09:01 +1000 From: Dave Chinner To: Jan Tulak Cc: xfs@oss.sgi.com Subject: Re: [PATCH 03/14] xfsprogs: avoid dependency on Linux XATTR_SIZE_MAX Message-ID: <20150923030901.GM3902@dastard> X-ASG-Orig-Subj: Re: [PATCH 03/14] xfsprogs: avoid dependency on Linux XATTR_SIZE_MAX References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> <1442311164-12921-4-git-send-email-jtulak@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442311164-12921-4-git-send-email-jtulak@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1442977743 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22809 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 15, 2015 at 11:59:13AM +0200, Jan Tulak wrote: > Currently, we depends on Linux XATTR value for on disk > definitions. Which causes trouble on other platforms and > maybe also if this value was to change. > > Fix it by creating a custom definition independent from > those in Linux (although with the same values), so it is OK > with the be16 fields used for holding these attributes. > > Signed-off-by: Jan Tulak Looks good. We'll need a kernel version of this patch, too. Reviewed-by: Dave Chinner Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Tue Sep 22 22:15:38 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 091977F37 for ; Tue, 22 Sep 2015 22:15:38 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 8897AAC00A for ; Tue, 22 Sep 2015 20:15:37 -0700 (PDT) X-ASG-Debug-ID: 1442978134-04cbb033b394180001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id 8CxhFOhEA6RKlq0b for ; Tue, 22 Sep 2015 20:15:34 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AXCAAcGAJWPOV8LHldgySBPYZZol8GinaRIgICAQECgU9NAQEBAQEBBwEBAQFBP4QkAQEBAwE6HCMFCwgDDgoJJQ8FJQMHGhOIJgfLKAEBAQcCAR8ZhhOFRIQ1WAeELAWVZ40EjwaMJYJ0HIFmLDOIJoFHAQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 23 Sep 2015 12:45:33 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeaWq-00027V-Tm; Wed, 23 Sep 2015 13:15:32 +1000 Date: Wed, 23 Sep 2015 13:15:32 +1000 From: Dave Chinner To: Jan Tulak Cc: xfs@oss.sgi.com Subject: Re: [PATCH 04/14] xfsprogs: prefix XATTR_LIST_MAX with XFS_ Message-ID: <20150923031532.GN3902@dastard> X-ASG-Orig-Subj: Re: [PATCH 04/14] xfsprogs: prefix XATTR_LIST_MAX with XFS_ References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> <1442311164-12921-5-git-send-email-jtulak@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442311164-12921-5-git-send-email-jtulak@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1442978134 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22809 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 15, 2015 at 11:59:14AM +0200, Jan Tulak wrote: > WILL CHANGE THE COMMIT MESSAGE. OK? > All right, I make the renaming with define - though I'm not sure > that with the ifdef for OS X and SIZE_MAX moved to a standalone patch > we need it - shouldn't be this change rather dropped? > > Signed-off-by: Jan Tulak > --- > include/xfs.h | 2 ++ > libhandle/handle.c | 4 ++-- > libhandle/jdm.c | 4 ++-- > 3 files changed, 6 insertions(+), 4 deletions(-) > > diff --git a/include/xfs.h b/include/xfs.h > index bc94068..8ee0106 100644 > --- a/include/xfs.h > +++ b/include/xfs.h > @@ -53,6 +53,8 @@ > # define ASSERT(EX) ((void) 0) > #endif > > +#define XFS_XATTR_LIST_MAX XATTR_LIST_MAX > + This does not belong here - it is a limit that applies to the ioctl API and so must be the same in userspace and the kernel. Such definitions belong in libxfs/xfs_fs.h, and should respect local OS limits if defined. e.g. something like: #ifdef XATTR_LIST_MAX #define XFS_XATTR_LIST_MAX XATTR_LIST_MAX #else #define XFS_XATTR_LIST_MAX 65536 #endif Will work on both the kernel and userspace side. This will also need a kernel side patch... Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Tue Sep 22 22:25:58 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2D7A87F37 for ; Tue, 22 Sep 2015 22:25:58 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 12126304032 for ; Tue, 22 Sep 2015 20:25:55 -0700 (PDT) X-ASG-Debug-ID: 1442978752-04bdf046268c780001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id PkLm2tgp7i2jTHuP for ; Tue, 22 Sep 2015 20:25:52 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DGBwBnGgJWPOV8LHldgySBPYZZol8GinaRIgQCAoFPTQEBAQEBAQcBAQEBQT+EJQEBBCcTHCMQCAMOCgklDwUlAwcaE4gtyyoBAQEHAiAZhhOFRIUNB4QsAQSVZ40EmyuCdByBZiwziW0BAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 23 Sep 2015 12:55:51 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Zeago-00028N-Qb; Wed, 23 Sep 2015 13:25:50 +1000 Date: Wed, 23 Sep 2015 13:25:50 +1000 From: Dave Chinner To: Jan Tulak Cc: xfs@oss.sgi.com Subject: Re: [PATCH 10/14] xfsprogs: Add a timer implementation for OS X Message-ID: <20150923032550.GO3902@dastard> X-ASG-Orig-Subj: Re: [PATCH 10/14] xfsprogs: Add a timer implementation for OS X References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> <1442311164-12921-11-git-send-email-jtulak@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442311164-12921-11-git-send-email-jtulak@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1442978752 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22810 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 15, 2015 at 11:59:20AM +0200, Jan Tulak wrote: > OS X does not have the timer used in xfs_repair. > Add a simple implementation providing the required > capabilities. .... > #endif /* __XFS_DARWIN_H__ */ > diff --git a/repair/progress.c b/repair/progress.c > index 27cbaef..0fee7dc 100644 > --- a/repair/progress.c > +++ b/repair/progress.c > @@ -184,10 +184,22 @@ progress_rpt_thread (void *p) > */ > > timespec.it_value.tv_sec = msgp->interval; > - timespec.it_value.tv_nsec = 0; > timespec.it_interval.tv_sec = msgp->interval; > + /* > + * On some platforms (like OS X), timers and time things are slightly > + * different: itimerspec is replaced with itimerval and timeval struct > + * has no tv_nsec, but just tv_usec member. > + * For compatibility, itimerspec is a macro defined to the existing > + * itimerval on these platforms, and in such case, use usec instead > + * of nsec. > + */ > +#ifndef itimerspec > + timespec.it_value.tv_nsec = 0; > timespec.it_interval.tv_nsec = 0; > - > +#else > + timespec.it_value.tv_usec = 0; > + timespec.it_interval.tv_usec = 0; > +#endif That's pretty nasty. How about this: memset(×pec, 0, sizeof(timespec)); timespec.it_value.tv_sec = msgp->interval; timespec.it_interval.tv_sec = msgp->interval; Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Tue Sep 22 22:32:35 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id DAE907F37 for ; Tue, 22 Sep 2015 22:32:35 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 65523AC00F for ; Tue, 22 Sep 2015 20:32:35 -0700 (PDT) X-ASG-Debug-ID: 1442979152-04cbb033b3945f0001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id Lg64gh8mxJfER4rB for ; Tue, 22 Sep 2015 20:32:32 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AaCADPHAJWPOV8LHldgyRUaYZZol8GinaLJ4V7AgIBAQKBT00BAQEBAQEHAQEBAUE/hCUBAQQ6HCMQCAMOCgklDwUlAwcaE4gtyxwBCwEfGYYThUSEKGUHhCwFlWeFEYdzghqZEYR2LDOIJYFIAQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 23 Sep 2015 13:02:18 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Zean4-000292-JV; Wed, 23 Sep 2015 13:32:18 +1000 Date: Wed, 23 Sep 2015 13:32:18 +1000 From: Dave Chinner To: Jan Tulak Cc: xfs@oss.sgi.com Subject: Re: [PATCH 11/14] xfsprogs: Add statvfs64 for osx Message-ID: <20150923033218.GP3902@dastard> X-ASG-Orig-Subj: Re: [PATCH 11/14] xfsprogs: Add statvfs64 for osx References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> <1442311164-12921-12-git-send-email-jtulak@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442311164-12921-12-git-send-email-jtulak@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1442979152 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22810 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 15, 2015 at 11:59:21AM +0200, Jan Tulak wrote: > Simply rename statvfs64 to statfs with a #define. > OSX version of statvfs is missing some members, so if the renaming > is in effect (stavfs64 is defined), don't try to use them and go > directly for the other member value. > > Signed-off-by: Jan Tulak > --- > fsr/xfs_fsr.c | 14 ++++++++++++++ > include/builddefs.in | 2 +- > include/darwin.h | 5 +++++ > 3 files changed, 20 insertions(+), 1 deletion(-) > > diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c > index e1b7bd6..5f95cdc 100644 > --- a/fsr/xfs_fsr.c > +++ b/fsr/xfs_fsr.c > @@ -36,6 +36,12 @@ > # include > #endif > > +#ifdef __APPLE__ > +//# define statvfs64 statfs; > +# include > +# include > +#endif Why is this here? We've included libxfs.h in this file, so we've got access to the platform specific includes already, and later in the patch you put the commented out define there... > + > #ifndef XFS_XFLAG_NODEFRAG > #define XFS_XFLAG_NODEFRAG 0x00002000 /* src dependancy, remove later */ > #endif > @@ -948,7 +954,11 @@ fsrfile_common( > fname, strerror(errno)); > return -1; > } > +#ifndef statvfs64 > bsize = vfss.f_frsize ? vfss.f_frsize : vfss.f_bsize; > +#else > + bsize = vfss.f_bsize; > +#endif bsize = platform_statvfs_bsize(&vfss); Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Tue Sep 22 22:37:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id F2CBE7F37 for ; Tue, 22 Sep 2015 22:37:07 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 7E4B1AC00C for ; Tue, 22 Sep 2015 20:37:07 -0700 (PDT) X-ASG-Debug-ID: 1442979424-04cb6c6b0785eb0001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id EpEUZo0I40W6NsLa for ; Tue, 22 Sep 2015 20:37:04 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AXCAD6HQJWPOV8LHldgySBPYZZol8GinaRIgICAQECgU9NAQEBAQEBBwEBAQFBP4QlAQEEOhwjEAgDDgoJJQ8FJQMHGhOILcsbAQEIAgEfGYYThUSFDQeELAWHMYZ8hBGDKY0EgVSENoMhkgCEdiwziW0BAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 23 Sep 2015 13:06:55 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZearX-00029V-Jc; Wed, 23 Sep 2015 13:36:55 +1000 Date: Wed, 23 Sep 2015 13:36:55 +1000 From: Dave Chinner To: Jan Tulak Cc: xfs@oss.sgi.com Subject: Re: [PATCH 12/14] xfsprogs: make fsr use mntinfo when there is no mntent Message-ID: <20150923033655.GQ3902@dastard> X-ASG-Orig-Subj: Re: [PATCH 12/14] xfsprogs: make fsr use mntinfo when there is no mntent References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> <1442311164-12921-13-git-send-email-jtulak@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442311164-12921-13-git-send-email-jtulak@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1442979424 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22810 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 15, 2015 at 11:59:22AM +0200, Jan Tulak wrote: > For what fsr needs, mntinfo can be used instead of mntent. > Custom mntent struct is used to avoid too big ifdefs: > We only change few lines and the rest of the code can still > use mntent as before. > > Signed-off-by: Jan Tulak > --- > fsr/Makefile | 8 +++++++ > fsr/xfs_fsr.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++-------- > include/darwin.h | 20 ++++++++++++++++ > 3 files changed, 87 insertions(+), 10 deletions(-) > > diff --git a/fsr/Makefile b/fsr/Makefile > index a9d1bf6..d3521b2 100644 > --- a/fsr/Makefile > +++ b/fsr/Makefile > @@ -9,6 +9,14 @@ LTCOMMAND = xfs_fsr > CFILES = xfs_fsr.c > LLDLIBS = $(LIBHANDLE) > > +ifeq ($(HAVE_GETMNTENT),yes) > +LCFLAGS += -DHAVE_GETMNTENT > +endif > + > +ifeq ($(HAVE_GETMNTINFO),yes) > +LCFLAGS += -DHAVE_GETMNTINFO > +endif > + > default: depend $(LTCOMMAND) > > include $(BUILDRULES) > diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c > index 5f95cdc..ff791d3 100644 > --- a/fsr/xfs_fsr.c > +++ b/fsr/xfs_fsr.c > @@ -32,8 +32,10 @@ > #include > #include > > -#ifdef HAVE_MNTENT > +#if defined(HAVE_GETMNTENT) > # include > +#elif defined(HAVE_GETMNTINFO) > +# include > #endif > > #ifdef __APPLE__ > @@ -191,9 +193,10 @@ find_mountpoint(char *mtab, char *argname, struct stat64 *sb) > { > struct mntent *t; > struct stat64 ms; > - FILE *mtabp; > char *mntp = NULL; > > +#if defined(HAVE_GETMNTENT) > + FILE *mtabp; > mtabp = setmntent(mtab, "r"); > if (!mtabp) { > fprintf(stderr, _("%s: cannot read %s\n"), > @@ -202,6 +205,27 @@ find_mountpoint(char *mtab, char *argname, struct stat64 *sb) > } > > while ((t = getmntent(mtabp))) { > +#elif defined(HAVE_GETMNTINFO) > + struct statfs *stats; > + int error, i, count; > + // because "t" is a pointer, but we don't need to use > + // malloc for this usage > + struct mntent t_tmp; > + t = &t_tmp; > + > + > + error = 0; > + if ((count = getmntinfo(&stats, 0)) < 0) { > + fprintf(stderr, _("%s: getmntinfo() failed: %s\n"), > + progname, strerror(errno)); > + return 0; > + } > + > + for (i = 0; i < count; i++) { > + mntinfo2mntent(&stats[i], t); > +#else > +# error "How do I extract info about mounted filesystems on this platform?" > +#endif No, please don't do that. Having a loop iterator split across two separate defines is unmaintainable. Write two separate functions with the different loop iterators, then factor the common bit out of them into a single function. > /* find all rw xfs file systems */ > mi = 0; > fs = fsbase; > + > +#if defined(HAVE_GETMNTENT) > + FILE *fp; > + fp = setmntent(mtab, "r"); > + if (fp == NULL) { > + fsrprintf(_("could not open mtab file: %s\n"), mtab); > + exit(1); > + } > + > while ((mp = getmntent(fp))) { > +#elif defined(HAVE_GETMNTINFO) > + struct statfs *stats; > + int error, i, count; > + // because "t" is a pointer, but we don't need to use > + // malloc for this usage > + struct mntent mp_tmp; > + mp = &mp_tmp; > + error = 0; > + if ((count = getmntinfo(&stats, 0)) < 0) { > + fprintf(stderr, _("%s: getmntinfo() failed: %s\n"), > + progname, strerror(errno)); > + exit(1); > + } > + > + for (i = 0; i < count; i++) { > + mntinfo2mntent(&stats[i], mp); > +#else > +# error "How do I extract info about mounted filesystems on this platform?" > +#endif > + Same again here. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Tue Sep 22 22:44:11 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 87A187F37 for ; Tue, 22 Sep 2015 22:44:11 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 1053EAC00A for ; Tue, 22 Sep 2015 20:44:11 -0700 (PDT) X-ASG-Debug-ID: 1442979847-04cbb033b094960001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id GBquUt0hWvZskcBL for ; Tue, 22 Sep 2015 20:44:08 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AXCAAaHwJWPOV8LHldgySBPYZZol8GinaRIgICAQECgU9NAQEBAQEBBwEBAQFBP4QlAQEEOhwjEAgDDgoJJQ8FJQMHGhOILcsbAQEIAgEfGYYThUSFDQeELAWVZ40EmyuCdByBZiwziCclgSEBAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 23 Sep 2015 13:14:06 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeayU-0002AN-2H; Wed, 23 Sep 2015 13:44:06 +1000 Date: Wed, 23 Sep 2015 13:44:06 +1000 From: Dave Chinner To: Brian Foster Cc: xfs@oss.sgi.com Subject: Re: [PATCH v2 02/12] libxfs: track largest metadata LSN in use via verifiers Message-ID: <20150923034406.GR3902@dastard> X-ASG-Orig-Subj: Re: [PATCH v2 02/12] libxfs: track largest metadata LSN in use via verifiers References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> <1441997742-37160-3-git-send-email-bfoster@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441997742-37160-3-git-send-email-bfoster@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1442979847 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22810 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Fri, Sep 11, 2015 at 02:55:32PM -0400, Brian Foster wrote: > The LSN validation helper is called in the I/O verifier codepath for > metadata that embed a last-modification LSN. While the codepath exists, > this is not used in userspace as in the kernel because the former > doesn't have an active log. > > xfs_repair does need to check the validity of the LSN metadata with > respect to the on-disk log, however. Use the LSN validation mechanism to > track the largest LSN that has been seen. Export the value so repair can > use it once it has processed the entire filesystem. Note that the helper > continues to always return true to preserve existing behavior. > > Signed-off-by: Brian Foster .... > +xfs_lsn_t libxfs_max_lsn = 0; > +pthread_mutex_t libxfs_max_lsn_lock = PTHREAD_MUTEX_INITIALIZER; > + > void > xfs_detect_invalid_lsn( > struct xfs_mount *mp, > xfs_lsn_t lsn) > { > + int cycle = CYCLE_LSN(lsn); > + int block = BLOCK_LSN(lsn); > + int max_cycle; > + int max_block; > + > + if (lsn == NULLCOMMITLSN) > + return; > + > + pthread_mutex_lock(&libxfs_max_lsn_lock); > + > + max_cycle = CYCLE_LSN(libxfs_max_lsn); > + max_block = BLOCK_LSN(libxfs_max_lsn); > + > + if ((cycle > max_cycle) || > + (cycle == max_cycle && block > max_block)) > + libxfs_max_lsn = lsn; > + > + pthread_mutex_unlock(&libxfs_max_lsn_lock); This will have the same lock contention problems that the kernel code would have had - my repair scalablity tests regularly reach over 1GB/s of metadata being prefetched through tens of threads, so this is going have a significant impact on performance in those tests.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Tue Sep 22 22:48:49 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 2915A7F37 for ; Tue, 22 Sep 2015 22:48:49 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 032888F8035 for ; Tue, 22 Sep 2015 20:48:49 -0700 (PDT) X-ASG-Debug-ID: 1442980126-04cbb033b394ab0001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id QMi8IShEkOADGsyq for ; Tue, 22 Sep 2015 20:48:46 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AXCAAdIAJWPOV8LHldgySBPYZZol8GinaRIgICAQECgU9NAQEBAQEBBwEBAQFBP4QlAQEEJxMcIxAIAw4KCSUPBSUDBxoTiC3LGgEBAQcCAR8ZhhOFRIUNB4QsBZVnjQSbK4J0HIFmLDOJbQEBAQ Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 23 Sep 2015 13:18:45 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Zeb2y-0002Aj-Ta; Wed, 23 Sep 2015 13:48:44 +1000 Date: Wed, 23 Sep 2015 13:48:44 +1000 From: Dave Chinner To: Brian Foster Cc: xfs@oss.sgi.com Subject: Re: [PATCH v2 03/12] libxfs: don't hardcode cycle 1 into unmount op header Message-ID: <20150923034844.GS3902@dastard> X-ASG-Orig-Subj: Re: [PATCH v2 03/12] libxfs: don't hardcode cycle 1 into unmount op header References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> <1441997742-37160-4-git-send-email-bfoster@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441997742-37160-4-git-send-email-bfoster@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1442980126 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22810 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Fri, Sep 11, 2015 at 02:55:33PM -0400, Brian Foster wrote: > The libxfs helper to write a log record after zeroing the log fills much > of the record header and unmount record with dummy data. It also > hardcodes the cycle number into the transaction oh_tid field as the > kernel expects to find the cycle stamped at the top of each block and > the original oh_tid value packed into h_cycle_data of the record header. > > The log clearing code requires the ability to format the log to an > arbitrary cycle number to fix v5 superblock log recovery ordering > problems. As a result, the unmount record helper must not hardcode a > cycle of 1. > > Fix up libxfs_log_header() to pack the unmount record appropriately, as > is already done for extra blocks that might exist beyond the record. Use > h_cycle_data for the original 32-bit word of the log record data block > and stamp the cycle number in its place. This allows unmount_record() to > work for arbitrary cycle numbers and libxfs_log_header() to pack a cycle > value that matches the lsn used in the record header. Note that this > patch does not change behavior as the lsn is still hardcoded to (1:0). > > Signed-off-by: Brian Foster > --- > libxfs/rdwr.c | 23 ++++++++++++++++------- > 1 file changed, 16 insertions(+), 7 deletions(-) > > diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c > index bc77699..ef18749 100644 > --- a/libxfs/rdwr.c > +++ b/libxfs/rdwr.c > @@ -122,7 +122,7 @@ static void unmount_record(void *p) > } magic = { XLOG_UNMOUNT_TYPE, 0, 0 }; > > memset(p, 0, BBSIZE); > - op->oh_tid = cpu_to_be32(1); > + op->oh_tid = cpu_to_be32(0xb0c0d0d0); > op->oh_len = cpu_to_be32(sizeof(magic)); > op->oh_clientid = XFS_LOG; > op->oh_flags = XLOG_UNMOUNT_TRANS; > @@ -188,10 +188,6 @@ libxfs_log_header( > > len = ((version == 2) && sunit) ? BTOBB(sunit) : 1; > > - /* note that oh_tid actually contains the cycle number > - * and the tid is stored in h_cycle_data[0] - that's the > - * way things end up on disk. > - */ This note needs to be hoisted up to the setting of op->oh_tid to explain the magic number being used... Cheers, Dave. -- Dave Chinner david@fromorbit.com From mel@ohmu.fi Wed Sep 23 01:16:42 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id BF3E17F37 for ; Wed, 23 Sep 2015 01:16:42 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 864558F8033 for ; Tue, 22 Sep 2015 23:16:39 -0700 (PDT) X-ASG-Debug-ID: 1442988994-04bdf04622902a0001-NocioJ Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) by cuda.sgi.com with ESMTP id l6VFv4ebnzVN8WmC (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Sep 2015 23:16:35 -0700 (PDT) X-Barracuda-Envelope-From: mel@ohmu.fi X-Barracuda-Apparent-Source-IP: 62.142.5.109 Received: from localhost.localdomain (a88-115-163-75.elisa-laajakaista.fi [88.115.163.75]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id C22F71887E7; Wed, 23 Sep 2015 09:16:33 +0300 (EEST) From: Mika Eloranta To: xfs@oss.sgi.com Cc: Mika Eloranta Subject: [PATCH] mkfs.xfs: option for using a pre-defined filesystem UUID Date: Wed, 23 Sep 2015 09:16:13 +0300 X-ASG-Orig-Subj: [PATCH] mkfs.xfs: option for using a pre-defined filesystem UUID Message-Id: <1442988973-43165-1-git-send-email-mel@ohmu.fi> X-Mailer: git-send-email 2.3.5 X-Barracuda-Connect: emh03.mail.saunalahti.fi[62.142.5.109] X-Barracuda-Start-Time: 1442988995 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_RULE_7580D X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22812 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.75 BSF_RULE_7580D Custom Rule 7580D Usage: mkfs.xfs -m uuid= The filesystem UUID can now be optionally specified during filesystem creation. The default behavior is still to generate a random UUID. Allows using pre-generated UUIDs for identifying a filesystem based on the metadata stored inside the filesystem. Filesystem labels can be used for the same purpose, but are limited by their length (12 chars in the case of xfs) whereas the UUID field can store an entire 128bit UUID, which is plenty for e.g. random ID collision avoidance. Random UUID generated during the creation of the filesystem is not always feasible when an external DB or other system is used to track the created filesystem, e.g. in automated VM provisioning systems, as this would require a feedback mechanism which is not always available. In these cases the best approach often is to generate a random UUID for the filesystem before the filesystem even exists, store it in the tracking DB and later create the filesystem directly with the correct UUID (instead of "mkfs.xfs + xfs_admin -U "). Signed-off-by: Mika Eloranta --- man/man8/mkfs.xfs.8 | 4 ++++ mkfs/xfs_mkfs.c | 12 ++++++++++-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/man/man8/mkfs.xfs.8 b/man/man8/mkfs.xfs.8 index 6260e0c..e98b94d 100644 --- a/man/man8/mkfs.xfs.8 +++ b/man/man8/mkfs.xfs.8 @@ -169,6 +169,10 @@ will create free inode btrees for filesystems created with the (default) option set. When the option .B \-m crc=0 is used, the free inode btree feature is not supported and is disabled. +.TP +.BI uuid= value +Use the given value as the filesystem UUID for the newly created filesystem. +The default is to generate a random UUID. .RE .TP .BI \-d " data_section_options" diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c index d993fc0..84f99b0 100644 --- a/mkfs/xfs_mkfs.c +++ b/mkfs/xfs_mkfs.c @@ -181,6 +181,8 @@ char *mopts[] = { "crc", #define M_FINOBT 1 "finobt", +#define M_UUID 2 + "uuid", NULL }; @@ -948,6 +950,7 @@ main( bool finobtflag; int spinodes; + platform_uuid_generate(&uuid); progname = basename(argv[0]); setlocale(LC_ALL, ""); bindtextdomain(PACKAGE, LOCALEDIR); @@ -1488,6 +1491,12 @@ main( finobt = c; finobtflag = true; break; + case M_UUID: + if (!value || *value == '\0') + reqval('m', mopts, M_UUID); + if (platform_uuid_parse(value, &uuid)) + illegal(optarg, "m uuid"); + break; default: unknown('m', value); } @@ -2550,7 +2559,6 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"), sbp->sb_dblocks = dblocks; sbp->sb_rblocks = rtblocks; sbp->sb_rextents = rtextents; - platform_uuid_generate(&uuid); platform_uuid_copy(&sbp->sb_uuid, &uuid); /* Only in memory; libxfs expects this as if read from disk */ platform_uuid_copy(&sbp->sb_meta_uuid, &uuid); @@ -3163,7 +3171,7 @@ usage( void ) { fprintf(stderr, _("Usage: %s\n\ /* blocksize */ [-b log=n|size=num]\n\ -/* metadata */ [-m crc=0|1,finobt=0|1]\n\ +/* metadata */ [-m crc=0|1,finobt=0|1,uuid=xxx]\n\ /* data subvol */ [-d agcount=n,agsize=n,file,name=xxx,size=num,\n\ (sunit=value,swidth=value|su=num,sw=num|noalign),\n\ sectlog=n|sectsize=num\n\ -- 2.3.5 From angelo.dureghello@nomovok.com Wed Sep 23 04:15:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 663237F37 for ; Wed, 23 Sep 2015 04:15:40 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 3B7EB304032 for ; Wed, 23 Sep 2015 02:15:36 -0700 (PDT) X-ASG-Debug-ID: 1442999729-04bdf04622950e0001-NocioJ Received: from mail.nomovok.com (mail.nomovok.com [83.150.122.238]) by cuda.sgi.com with ESMTP id 6zbiPlPSAxTJe5Lq (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Sep 2015 02:15:32 -0700 (PDT) X-Barracuda-Envelope-From: angelo.dureghello@nomovok.com X-Barracuda-Apparent-Source-IP: 83.150.122.238 Received: from [192.168.0.111] (host46-236-dynamic.8-87-r.retail.telecomitalia.it [87.8.236.46]) by mail.nomovok.com (Postfix) with ESMTPSA id 65287AE0A7 for ; Wed, 23 Sep 2015 12:15:29 +0300 (EEST) Message-ID: <56026DB0.8070104@nomovok.com> Date: Wed, 23 Sep 2015 11:15:28 +0200 From: Angelo Dureghello User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: xfstests, bad generic tests 009 and 308 References: <55FC3E0E.9060506@nomovok.com> <20150918224412.GE26895@dastard> <55FFE665.7040004@nomovok.com> <20150921225244.GD19114@dastard> <56014C62.1070403@nomovok.com> <20150922212740.GJ19114@dastard> X-ASG-Orig-Subj: Re: xfstests, bad generic tests 009 and 308 In-Reply-To: <20150922212740.GJ19114@dastard> Content-Type: multipart/mixed; boundary="------------060003040901080706060303" X-Barracuda-Connect: mail.nomovok.com[83.150.122.238] X-Barracuda-Start-Time: 1442999731 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-BRTS-Evidence: sysam.it X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22815 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words This is a multi-part message in MIME format. --------------060003040901080706060303 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, many thanks. On 22/09/2015 23:27, Dave Chinner wrote: > Urk, the command should be "fsync", not "sync". Regardless, the > last bmap/fiemap pair shows something interesting: > > bmap-vp: > >> /media/p6/testfile: >> EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS >> 0: [0..127]: 96..223 0 (96..223) 128 00000 >> 1: [128..2047]: hole 1920 >> 2: [2048..2559]: 2144..2655 0 (2144..2655) 512 10000 > fiemap -v: > >> /media/p6/testfile: >> EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS >> 0: [0..127]: 96..223 128 0x0 >> 1: [128..2047]: hole 1920 >> 2: [2048..2175]: 2144..2271 128 0x800 >> 3: [2176..2303]: 2272..2399 128 0x0 >> 4: [2304..2559]: 2400..2655 256 0x801 > Note that they are different - the former shows an unwritten extent > of 256k @ offset 1MB, the later shows that extent split by 64k of > data @ 1088k. > > The bmap -vp output is incorrect - it is supposed to sync data first > and so should look the same as the fiemap output. Can you run this > test again, this time with s/sync/fsync so the files are clean when > bmap/fiemap are run? Can you run it a second time (umount/mkfs > again) but with fiemap run first? i.e '-c "fiemap -v" -c "bmap -vp" \' > instead of the original order? > > Next, can you compile your kernel with CONFIG_XFS_DEBUG=y and rerun > the tests? Does anything interesting appear in dmesg during the test > run? Done, see mkfs_output_2.txt attached > Not actually useful - I need to know what is happening inside the > unlinkat() call. I'm going to need a trace-cmd event dump of that > xfs_io command and the subsequent rm (at least for the first couple > of seconds of the rm). Please put the output file from the trace-cmd > record command on a tmpfs filesystem so it doesn't pollute the xfs > event trace ;) > I set some traces inside fs/namei.c do_unlinkat() root[243] vpc24 (master) /home/angelo/xfstests # ./start_xfs_test.sh QA output created by 308 [ 144.822616] XFS (mmcblk0p5): Mounting V4 Filesystem [ 145.074537] XFS (mmcblk0p5): Starting recovery (logdev: internal) [ 145.107298] XFS (mmcblk0p5): Ending recovery (logdev: internal) Silence is golden [ 145.413606] do_unlinkat(): entering [ 145.417124] do_unlinkat(): retry [ 145.421156] do_unlinkat(): retry_delegate [ 145.425920] do_unlinkat(): vfs_unlink returns 0 [ 145.430950] do_unlinkat(): exit2 At least that function "seems" to complete, but, as from my previous message looks like strace was not showing nothig over it. I captured about 10 seconds of events after the "hang" on 308. Hope they are enough. File is quite long, so you can read it from here: http://sysam.it/~angelo/events.txt bye, -- Best regards, Angelo Dureghello --------------060003040901080706060303 Content-Type: text/plain; charset=UTF-8; name="mkfs_output_2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mkfs_output_2.txt" # # xfs_io -f -c "pwrite 0 64k" -c fsync \ -c "bmap -vp" -c "fiemap -v" \ -c "falloc 1024k 256k" -c fsync \ -c "pwrite 1088k 64k" -c fsync \ -c "bmap -vp" -c "fiemap -v" \ /media/p6/testfile # xfs_io -f -c "pwrite 0 64k" -c fsync \ > -c "bmap -vp" -c "fiemap -v" \ > -c "falloc 1024k 256k" -c fsync \ > -c "pwrite 1088k 64k" -c fsync \ > -c "bmap -vp" -c "fiemap -v" \ > /media/p6/testfile wrote 65536/65536 bytes at offset 0 64 KiB, 16 ops; 0.0000 sec (10.271 MiB/sec and 2629.4166 ops/sec) /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..127]: 96..223 0 (96..223) 128 00000 /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 96..223 128 0x1 wrote 65536/65536 bytes at offset 1114112 64 KiB, 16 ops; 0.0000 sec (11.857 MiB/sec and 3035.4771 ops/sec) /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..127]: 96..223 0 (96..223) 128 00000 1: [128..2047]: hole 1920 2: [2048..2175]: 2144..2271 0 (2144..2271) 128 10000 3: [2176..2303]: 2272..2399 0 (2272..2399) 128 00000 4: [2304..2559]: 2400..2655 0 (2400..2655) 256 10000 /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 96..223 128 0x0 1: [128..2047]: hole 1920 2: [2048..2175]: 2144..2271 128 0x800 3: [2176..2303]: 2272..2399 128 0x0 4: [2304..2559]: 2400..2655 256 0x801 root[251] host ~ # mkfs.xfs -f /dev/mmcblk0p6 meta-data=/dev/mmcblk0p6 isize=256 agcount=4, agsize=551008 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=2204032, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 root[252] host ~ # mount /dev/mmcblk0p6 /media/p6 [ 1000.531021] XFS (mmcblk0p6): Mounting V4 Filesystem [ 1000.813339] XFS (mmcblk0p6): Ending clean mount root[253] host ~ # xfs_io -f -c "pwrite 0 64k" -c fsync \ > -c "bmap -vp" -c "fiemap -v" \ > -c "falloc 1024k 256k" -c fsync \ > -c "pwrite 1088k 64k" -c fsync \ > -c "fiemap -v" -c "bmap -vp" \ > /media/p6/testfile wrote 65536/65536 bytes at offset 0 64 KiB, 16 ops; 0.0000 sec (10.126 MiB/sec and 2592.3526 ops/sec) /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..127]: 96..223 0 (96..223) 128 00000 /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 96..223 128 0x1 wrote 65536/65536 bytes at offset 1114112 64 KiB, 16 ops; 0.0000 sec (11.519 MiB/sec and 2948.7652 ops/sec) /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 96..223 128 0x0 1: [128..2047]: hole 1920 2: [2048..2175]: 2144..2271 128 0x800 3: [2176..2303]: 2272..2399 128 0x0 4: [2304..2559]: 2400..2655 256 0x801 /media/p6/testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..127]: 96..223 0 (96..223) 128 00000 1: [128..2047]: hole 1920 2: [2048..2175]: 2144..2271 0 (2144..2271) 128 10000 3: [2176..2303]: 2272..2399 0 (2272..2399) 128 00000 4: [2304..2559]: 2400..2655 0 (2400..2655) 256 10000 root[254] host ~ --------------060003040901080706060303-- From cmaiolino@redhat.com Wed Sep 23 05:28:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id D3E657F37 for ; Wed, 23 Sep 2015 05:28:43 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 610B8AC005 for ; Wed, 23 Sep 2015 03:28:40 -0700 (PDT) X-ASG-Debug-ID: 1443004118-04cbb033b3a0bf0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id fOrB5jgalz6iBBpr (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 23 Sep 2015 03:28:39 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id E8B688F315; Wed, 23 Sep 2015 10:28:37 +0000 (UTC) Received: from redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8NASYjn018228 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 23 Sep 2015 06:28:37 -0400 Date: Wed, 23 Sep 2015 12:28:34 +0200 From: Carlos Maiolino To: Dave Chinner Cc: Brian Foster , xfs@oss.sgi.com Subject: Re: [PATCH] xfs_io: Implement inodes64 command - bug in XFS_IOC_FSINUMBERS? Message-ID: <20150923102834.GA4490@redhat.com> X-ASG-Orig-Subj: Re: [PATCH] xfs_io: Implement inodes64 command - bug in XFS_IOC_FSINUMBERS? Mail-Followup-To: Dave Chinner , Brian Foster , xfs@oss.sgi.com References: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> <20150921220832.GB19114@dastard> <20150922075432.GC26699@redhat.com> <20150922122238.GA46026@bfoster.bfoster> <20150922220054.GL19114@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150922220054.GL19114@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1443004118 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Howdy folks, I was working in implementing the suggested feature in my patch, about getting the next inode used after one is provided, and I hit something that I'm not really sure if this might be considered a bug, or just a work form. XFS_IOC_FSINUMBERS, is supposed to be called with a zeroed xfs_fsop_bulkreq.lastip, so at each call, kernel will update this number to the last inode returned, and, the next call will return in xfs_inogrp.xi_startino, the next existing inode after .lastip. So, I was expecting that, passing a non-zero .lastip at the first call, I would be able to get the next inode right after the one I passed through .lastip, but, after some tests and reading the code, I noticed that this is not the case. The problem (not sure if I can really say it's a problem), is that, if the inode number passed, happens to be somewhere in the middle of an inode chunk, the whole chunk will not be printed, only the next inode chunk will start to be printed, hiding all information of the previous one. I'm not sure if this is the desired behavior or not, but, I'd say that, if the inode passed in .lastip, is not the first in the chunk, the output should start for its own chunk, instead of the next one, but, I prefer to see you folks POV before starting to fix something that I'm not sure if it's actually broken :-) Cheers -- Carlos From veilletechno-irts@univ-nantes.fr Wed Sep 23 05:45:09 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 1774A7F37 for ; Wed, 23 Sep 2015 05:45:09 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id A6254AC005 for ; Wed, 23 Sep 2015 03:45:08 -0700 (PDT) X-ASG-Debug-ID: 1443005106-04cb6c6b0590380001-NocioJ Received: from smtp-tls.univ-nantes.fr (smtptls2-lmb.cpub.univ-nantes.fr [193.52.103.111]) by cuda.sgi.com with ESMTP id MIfJzReAoeBG0f6S for ; Wed, 23 Sep 2015 03:45:06 -0700 (PDT) X-Barracuda-Envelope-From: veilletechno-irts@univ-nantes.fr X-Barracuda-Apparent-Source-IP: 193.52.103.111 Received: from localhost (localhost [127.0.0.1]) by smtp-tls.univ-nantes.fr (Postfix) with ESMTP id 1AF9240171C for ; Wed, 23 Sep 2015 12:45:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at smtptls1-lmb.cpub.univ-nantes.fr Received: from smtp-tls.univ-nantes.fr ([127.0.0.1]) by localhost (smtptls2-lmb.cpub.univ-nantes.fr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id W-LdVlmiaFyg for ; Wed, 23 Sep 2015 12:45:06 +0200 (CEST) Received: from [172.20.13.174] (unknown [172.20.13.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-tls.univ-nantes.fr (Postfix) with ESMTPSA id F0057401715 for ; Wed, 23 Sep 2015 12:45:05 +0200 (CEST) Subject: Re: xfstests, bad generic tests 009 and 308 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfstests, bad generic tests 009 and 308 References: <55FC3E0E.9060506@nomovok.com> <20150918224412.GE26895@dastard> <55FFE665.7040004@nomovok.com> <20150921225244.GD19114@dastard> From: Yann Dupont - Veille Techno Message-ID: <56028249.7040103@univ-nantes.fr> Date: Wed, 23 Sep 2015 12:43:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: <20150921225244.GD19114@dastard> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Barracuda-Connect: smtptls2-lmb.cpub.univ-nantes.fr[193.52.103.111] X-Barracuda-Start-Time: 1443005106 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22817 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words Le 22/09/2015 00:52, Dave Chinner a écrit : > As it is, I highly recommend that you try a current 4.3 kernel, as > there are several code fixes in the XFS kernel code that work around > compiler issues we know about. AFAIA, the do_div() asm bug that trips > recent gcc optimisations isn't in the upstream kernel yet, but that > can be worked around by setting CONFIG_CC_OPTIMIZE_FOR_SIZE=y in your > build. Hi dave, I can confirm that CONFIG_CC_OPTIMIZE_FOR_SIZE=y is (was ?) the only way for me to have reliable XFS kernel code on different arm platforms (Marvell kirkwood, Allwinner A20, Amlogic S805), no matter what recent gcc version I've been using. I must admit I was cross-compiling from X86-64 too, but I think (not sure) that it was also the case with native gcc. I must also admit that I didn't tried since some months, because CONFIG_CC_OPTIMIZE_FOR_SIZE=y was the silver bullet for arm xfs kernel crashes. This crash was difficult to understand because it occurs quite randomly (I.e it can take several hours to trigger) If there's a patch floating around for gcc (or kernel), I'm interested to test. Cheers, From bfoster@redhat.com Wed Sep 23 07:24:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 72F7E7F37 for ; Wed, 23 Sep 2015 07:24:08 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 31ACA304039 for ; Wed, 23 Sep 2015 05:24:05 -0700 (PDT) X-ASG-Debug-ID: 1443011043-04bdf04622997e0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id bYswj6kxvELN3iW2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 23 Sep 2015 05:24:04 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id AE74CC0A149C; Wed, 23 Sep 2015 12:24:03 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8NCO35M017570; Wed, 23 Sep 2015 08:24:03 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 3AEF41202D2; Wed, 23 Sep 2015 08:24:02 -0400 (EDT) Date: Wed, 23 Sep 2015 08:24:02 -0400 From: Brian Foster To: Dave Chinner , xfs@oss.sgi.com Subject: Re: [PATCH] xfs_io: Implement inodes64 command - bug in XFS_IOC_FSINUMBERS? Message-ID: <20150923122401.GA37210@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH] xfs_io: Implement inodes64 command - bug in XFS_IOC_FSINUMBERS? References: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> <20150921220832.GB19114@dastard> <20150922075432.GC26699@redhat.com> <20150922122238.GA46026@bfoster.bfoster> <20150922220054.GL19114@dastard> <20150923102834.GA4490@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150923102834.GA4490@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443011044 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 23, 2015 at 12:28:34PM +0200, Carlos Maiolino wrote: > Howdy folks, > > I was working in implementing the suggested feature in my patch, about getting > the next inode used after one is provided, and I hit something that I'm not really > sure if this might be considered a bug, or just a work form. > > XFS_IOC_FSINUMBERS, is supposed to be called with a zeroed > xfs_fsop_bulkreq.lastip, so at each call, kernel will update this number to the > last inode returned, and, the next call will return in xfs_inogrp.xi_startino, > the next existing inode after .lastip. > > So, I was expecting that, passing a non-zero .lastip at the first call, I would > be able to get the next inode right after the one I passed through .lastip, but, > after some tests and reading the code, I noticed that this is not the case. > > The problem (not sure if I can really say it's a problem), is that, if the inode > number passed, happens to be somewhere in the middle of an inode chunk, the > whole chunk will not be printed, only the next inode chunk will start to be > printed, hiding all information of the previous one. > > I'm not sure if this is the desired behavior or not, but, I'd say that, if the > inode passed in .lastip, is not the first in the chunk, the output should start > for its own chunk, instead of the next one, but, I prefer to see you folks POV > before starting to fix something that I'm not sure if it's actually broken :-) > On a quick pass through, it seems like this is probably just the nature of the granularity and typical use case of the inumbers interface. For one, I think the lastip parameter is intended to be used as a cookie as opposed to an inode-granularity search key. The return structures also appear to describe inode records so there isn't any natural way to get a partial record that I can see. Note that bulkstat does appear to support an inode granularity starting point (see xfs_bulkstat_grab_ichunk()) as the output format is inode granularity. FWIW, I would probably try to handle something like the above in userspace by working with the interface rather than modifying it. In other words, subtract (at least) XFS_INODES_PER_CHUNK from the inode number in question and use that as a starting point to ensure the output contains the record for the inode if one exists. It seems like you could change the inumbers behavior to return the record that contains lastip + 1 if you really wanted to, we'd just have to take care not to break the lastip behavior itself (e.g., we can't just search for any record that contains lastip). What looks interesting, and might justify doing something in this area, is the behavior presumably caused by doing a greater than or equal to (XFS_LOOKUP_GE) lookup in xfs_inumbers(). If lastino happens to be a record startino, we'll actually return the record that contains that inode (thus technically supporting a mid-record start). If the index in the record is beyond that, we'll skip it and start at the next record. Unless I misinterpret that, it seems like that should be fixed one way or another. Brian > Cheers > > -- > Carlos > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Wed Sep 23 08:18:44 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 676D27F37 for ; Wed, 23 Sep 2015 08:18:44 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id F130BAC005 for ; Wed, 23 Sep 2015 06:18:40 -0700 (PDT) X-ASG-Debug-ID: 1443014313-04bdf046229ac00001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id kcXs9STEyFMJHaqB (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 23 Sep 2015 06:18:33 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 189199247C; Wed, 23 Sep 2015 13:18:33 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8NDIWdM020646; Wed, 23 Sep 2015 09:18:32 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 940C21202D2; Wed, 23 Sep 2015 09:18:31 -0400 (EDT) Date: Wed, 23 Sep 2015 09:18:31 -0400 From: Brian Foster To: Dave Chinner Cc: xfs@oss.sgi.com Subject: Re: [PATCH v2 02/12] libxfs: track largest metadata LSN in use via verifiers Message-ID: <20150923131831.GB37210@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH v2 02/12] libxfs: track largest metadata LSN in use via verifiers References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> <1441997742-37160-3-git-send-email-bfoster@redhat.com> <20150923034406.GR3902@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150923034406.GR3902@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443014313 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 23, 2015 at 01:44:06PM +1000, Dave Chinner wrote: > On Fri, Sep 11, 2015 at 02:55:32PM -0400, Brian Foster wrote: > > The LSN validation helper is called in the I/O verifier codepath for > > metadata that embed a last-modification LSN. While the codepath exists, > > this is not used in userspace as in the kernel because the former > > doesn't have an active log. > > > > xfs_repair does need to check the validity of the LSN metadata with > > respect to the on-disk log, however. Use the LSN validation mechanism to > > track the largest LSN that has been seen. Export the value so repair can > > use it once it has processed the entire filesystem. Note that the helper > > continues to always return true to preserve existing behavior. > > > > Signed-off-by: Brian Foster > .... > > +xfs_lsn_t libxfs_max_lsn = 0; > > +pthread_mutex_t libxfs_max_lsn_lock = PTHREAD_MUTEX_INITIALIZER; > > + > > void > > xfs_detect_invalid_lsn( > > struct xfs_mount *mp, > > xfs_lsn_t lsn) > > { > > + int cycle = CYCLE_LSN(lsn); > > + int block = BLOCK_LSN(lsn); > > + int max_cycle; > > + int max_block; > > + > > + if (lsn == NULLCOMMITLSN) > > + return; > > + > > + pthread_mutex_lock(&libxfs_max_lsn_lock); > > + > > + max_cycle = CYCLE_LSN(libxfs_max_lsn); > > + max_block = BLOCK_LSN(libxfs_max_lsn); > > + > > + if ((cycle > max_cycle) || > > + (cycle == max_cycle && block > max_block)) > > + libxfs_max_lsn = lsn; > > + > > + pthread_mutex_unlock(&libxfs_max_lsn_lock); > > This will have the same lock contention problems that the kernel > code would have had - my repair scalablity tests regularly reach > over 1GB/s of metadata being prefetched through tens of threads, so > this is going have a significant impact on performance in those > tests.... > Hmm, Ok. I initially didn't have locking here (by accident) but reproduced some breakage for which the exact details escape me. I suspect it was a test and set race. I suppose we could try doing something like what we plan to do on the kernel side in terms of a racy check followed by the locked check so the lock contention goes away once we find the max lsn. The context here is different, however, in that we're using a 64-bit LSN rather than independently updated cycle and block fields. It could also take a while to stabilize the max lsn depending on the fs. (There are some details on the kernel side I'd like to get worked out first as well). Perhaps we could try to make this smarter... in the case where either the log has been zeroed or we've identified an LSN beyond the current log state, we only really need to track the max cycle value since a log format is imminent at that point. In the case where the fs is consistent, we could seed the starting value with the current log lsn, or track per-ag max LSNs without locking and compare them at at the end, etc. I'll have to think about this some more and see what's effective. I'd also like to quantify the effect the current locking has on performance if possible. Can you provide a brief description of your typical repair test that you would expect this to hurt? E.g., a large fs, many AGs, populated with fs_mark and repaired with many threads..? Any special storage configuration? Thanks. Brian > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From bfoster@redhat.com Wed Sep 23 08:22:06 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 9BD5F7F37 for ; Wed, 23 Sep 2015 08:22:06 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 6BA9A304032 for ; Wed, 23 Sep 2015 06:22:03 -0700 (PDT) X-ASG-Debug-ID: 1443014522-04bdf046229ae90001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id YfUxqec39ThJdPOw (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 23 Sep 2015 06:22:02 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id EBA2CC0B2B79; Wed, 23 Sep 2015 13:22:01 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8NDM1qe001974; Wed, 23 Sep 2015 09:22:01 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id A4A031202D2; Wed, 23 Sep 2015 09:22:00 -0400 (EDT) Date: Wed, 23 Sep 2015 09:22:00 -0400 From: Brian Foster To: Dave Chinner Cc: xfs@oss.sgi.com Subject: Re: [PATCH v2 03/12] libxfs: don't hardcode cycle 1 into unmount op header Message-ID: <20150923132200.GC37210@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH v2 03/12] libxfs: don't hardcode cycle 1 into unmount op header References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> <1441997742-37160-4-git-send-email-bfoster@redhat.com> <20150923034844.GS3902@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150923034844.GS3902@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443014522 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 23, 2015 at 01:48:44PM +1000, Dave Chinner wrote: > On Fri, Sep 11, 2015 at 02:55:33PM -0400, Brian Foster wrote: > > The libxfs helper to write a log record after zeroing the log fills much > > of the record header and unmount record with dummy data. It also > > hardcodes the cycle number into the transaction oh_tid field as the > > kernel expects to find the cycle stamped at the top of each block and > > the original oh_tid value packed into h_cycle_data of the record header. > > > > The log clearing code requires the ability to format the log to an > > arbitrary cycle number to fix v5 superblock log recovery ordering > > problems. As a result, the unmount record helper must not hardcode a > > cycle of 1. > > > > Fix up libxfs_log_header() to pack the unmount record appropriately, as > > is already done for extra blocks that might exist beyond the record. Use > > h_cycle_data for the original 32-bit word of the log record data block > > and stamp the cycle number in its place. This allows unmount_record() to > > work for arbitrary cycle numbers and libxfs_log_header() to pack a cycle > > value that matches the lsn used in the record header. Note that this > > patch does not change behavior as the lsn is still hardcoded to (1:0). > > > > Signed-off-by: Brian Foster > > --- > > libxfs/rdwr.c | 23 ++++++++++++++++------- > > 1 file changed, 16 insertions(+), 7 deletions(-) > > > > diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c > > index bc77699..ef18749 100644 > > --- a/libxfs/rdwr.c > > +++ b/libxfs/rdwr.c > > @@ -122,7 +122,7 @@ static void unmount_record(void *p) > > } magic = { XLOG_UNMOUNT_TYPE, 0, 0 }; > > > > memset(p, 0, BBSIZE); > > - op->oh_tid = cpu_to_be32(1); > > + op->oh_tid = cpu_to_be32(0xb0c0d0d0); > > op->oh_len = cpu_to_be32(sizeof(magic)); > > op->oh_clientid = XFS_LOG; > > op->oh_flags = XLOG_UNMOUNT_TRANS; > > @@ -188,10 +188,6 @@ libxfs_log_header( > > > > len = ((version == 2) && sunit) ? BTOBB(sunit) : 1; > > > > - /* note that oh_tid actually contains the cycle number > > - * and the tid is stored in h_cycle_data[0] - that's the > > - * way things end up on disk. > > - */ > > This note needs to be hoisted up to the setting of op->oh_tid to > explain the magic number being used... > This requires that I understand what the magic number being used actually means. Any ideas? ;) I just assumed it was a dummy tid value. The comment removed above just explains why that value is being put where it is (cycle value in oh_tid and tid value in h_cycle_data) as the original code implicitly implements the cycle data packing. That is undone by this patch. The packing is now done explicitly (with its own comments) in the caller and thus the original comment is irrelevant. Brian > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Wed Sep 23 12:53:52 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 11D067F37 for ; Wed, 23 Sep 2015 12:53:52 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 0142B8F8052 for ; Wed, 23 Sep 2015 10:53:48 -0700 (PDT) X-ASG-Debug-ID: 1443030826-04cbb033b2abe40001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id ZnznbKesAkWGMiB6 for ; Wed, 23 Sep 2015 10:53:46 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 1CB0761F81DE for ; Wed, 23 Sep 2015 12:53:46 -0500 (CDT) Subject: Re: [PATCH 09/13] xfs_repair: better checking of v5 attributes To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 09/13] xfs_repair: better checking of v5 attributes References: <1441827251-13128-1-git-send-email-sandeen@sandeen.net> <1441827251-13128-10-git-send-email-sandeen@sandeen.net> <20150914194412.GJ34083@bfoster.bfoster> From: Eric Sandeen Message-ID: <5602E729.3010500@sandeen.net> Date: Wed, 23 Sep 2015 12:53:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150914194412.GJ34083@bfoster.bfoster> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1443030826 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22828 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/14/15 2:44 PM, Brian Foster wrote: > On Wed, Sep 09, 2015 at 02:34:07PM -0500, Eric Sandeen wrote: >> The commit: >> >> 0519f66 xfs_repair: better checking of v5 metadata fields >> >> added new corruption checks to dir2.c but missed the similar >> code in attr_repair.c; add that here. >> >> Signed-off-by: Eric Sandeen >> Signed-off-by: Eric Sandeen >> --- >> repair/attr_repair.c | 9 +++++++++ >> 1 files changed, 9 insertions(+), 0 deletions(-) >> >> diff --git a/repair/attr_repair.c b/repair/attr_repair.c >> index 2aafdf6..c8ba484 100644 >> --- a/repair/attr_repair.c >> +++ b/repair/attr_repair.c >> @@ -201,6 +201,15 @@ traverse_int_dablock(xfs_mount_t *mp, >> goto error_out; >> } >> >> + /* corrupt node; rebuild the dir. */ >> + if (bp->b_error == -EFSBADCRC || bp->b_error == -EFSCORRUPTED) { >> + libxfs_putbuf(bp); >> + do_warn( >> +_("corrupt tree block %u for directory inode %" PRIu64 "\n"), >> + bno, da_cursor->ino); >> + goto error_out; >> + } >> + > > Hmm, well this certainly looks similar, but is it the right thing to do > for xattrs? I haven't followed through how exactly directories are > rebuilt, but there does appear to be a recovery path in the dir2 > context. A failure there simply puts the inode on a "bad" list to be > rebuilt later, presumably from data collected from all of the inodes. > > If we fail here, it looks like we just clear the attribute fork. So are > we failing too hard, too soon here if a dablock crc happens to be > incorrect? Brian & I talked about this briefly on IRC. The upshot: attr checking already has many failure points, and if any one fails, the attr may get nuked. dir checking already has many failure points, and if any one fails, the dir can get rebuilt. All this patch does is add another check to several existing checks in the attr code, and if it fails, whatever action was taken before for any other error will also be taken for a bad CRC or a verifier failure. So, this doesn't really introduce any new or more draconian behavior; it simply adds one more check (the CRC, which had previously been ignored) to a host of other verifications in this code, with the same results as before if this new check fails. So I think it's fine as it is. Thanks, -Eric From david@fromorbit.com Wed Sep 23 17:12:45 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 845707F37 for ; Wed, 23 Sep 2015 17:12:45 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 14620AC006 for ; Wed, 23 Sep 2015 15:12:44 -0700 (PDT) X-ASG-Debug-ID: 1443046357-04cbb033b1b1b30001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id DfLOG6IcQwoC0D6g for ; Wed, 23 Sep 2015 15:12:38 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BSBwBFIwNWPOV8LHldgyRUaakhDAECAwaKeYsxhXMEAgKBUE0BAQEBAQEHAQEBAUE/hCUBAQQyASMjEAgDEAgJJQ8FJQMHGhOILQ7LdwEBAQcBAQEBAR0ZhhOFRIJugh8HhCwFlWeFEod0gVSVboNthHYsMwGJawEBAQ Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 24 Sep 2015 07:34:44 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Zes9c-0004EB-52; Thu, 24 Sep 2015 08:04:44 +1000 Date: Thu, 24 Sep 2015 08:04:44 +1000 From: Dave Chinner To: Yann Dupont - Veille Techno Cc: xfs@oss.sgi.com Subject: Re: xfstests, bad generic tests 009 and 308 Message-ID: <20150923220444.GP19114@dastard> X-ASG-Orig-Subj: Re: xfstests, bad generic tests 009 and 308 References: <55FC3E0E.9060506@nomovok.com> <20150918224412.GE26895@dastard> <55FFE665.7040004@nomovok.com> <20150921225244.GD19114@dastard> <56028249.7040103@univ-nantes.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56028249.7040103@univ-nantes.fr> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1443046357 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22837 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words On Wed, Sep 23, 2015 at 12:43:21PM +0200, Yann Dupont - Veille Techno wrote: > Le 22/09/2015 00:52, Dave Chinner a écrit : > >As it is, I highly recommend that you try a current 4.3 kernel, as > >there are several code fixes in the XFS kernel code that work > >around compiler issues we know about. AFAIA, the do_div() asm bug > >that trips recent gcc optimisations isn't in the upstream kernel > >yet, but that can be worked around by setting > >CONFIG_CC_OPTIMIZE_FOR_SIZE=y in your build. > > Hi dave, > > I can confirm that CONFIG_CC_OPTIMIZE_FOR_SIZE=y is (was ?) the only > way for me to have reliable XFS kernel code on different arm > platforms (Marvell kirkwood, Allwinner A20, Amlogic S805), no matter > what recent gcc version I've been using. > > I must admit I was cross-compiling from X86-64 too, but I think (not > sure) that it was also the case with native gcc. > > I must also admit that I didn't tried since some months, because > CONFIG_CC_OPTIMIZE_FOR_SIZE=y was the silver bullet for arm xfs > kernel crashes. This crash was difficult to understand because it > occurs quite randomly (I.e it can take several hours to trigger) > > If there's a patch floating around for gcc (or kernel), I'm > interested to test. See this subthread from august: http://oss.sgi.com/archives/xfs/2015-08/msg00234.html AFAICT, the do_div patch to fix the problem has not yet been picked up - it's not in the 4.3-rc2 kernel... Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Wed Sep 23 17:35:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 685427F37 for ; Wed, 23 Sep 2015 17:35:20 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 4A1AA304048 for ; Wed, 23 Sep 2015 15:35:16 -0700 (PDT) X-ASG-Debug-ID: 1443047709-04cb6c6b06a0e80001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id 7RDZo7ZHyz6PGJN8 for ; Wed, 23 Sep 2015 15:35:09 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BTBwAHKANWPOV8LHldgyRUaYZZokgMAQIDBop5iy2FdwQCAoFOTQEBAQEBAQcBAQEBQT+EJAEBAQMBOhwjBQsIAxgJJQ8FJQMHGhOIJgfMCgEBAQcBAQEBAR0ZhhOFRIUNB4QsBZVnhRKHdIFUhDaROINthHYsM4lsAQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 24 Sep 2015 07:55:15 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZesTT-0004GI-ED; Thu, 24 Sep 2015 08:25:15 +1000 Date: Thu, 24 Sep 2015 08:25:15 +1000 From: Dave Chinner To: Angelo Dureghello Cc: xfs@oss.sgi.com Subject: Re: xfstests, bad generic tests 009 and 308 Message-ID: <20150923222515.GQ19114@dastard> X-ASG-Orig-Subj: Re: xfstests, bad generic tests 009 and 308 References: <55FC3E0E.9060506@nomovok.com> <20150918224412.GE26895@dastard> <55FFE665.7040004@nomovok.com> <20150921225244.GD19114@dastard> <56014C62.1070403@nomovok.com> <20150922212740.GJ19114@dastard> <56026DB0.8070104@nomovok.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56026DB0.8070104@nomovok.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1443047709 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22838 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words On Wed, Sep 23, 2015 at 11:15:28AM +0200, Angelo Dureghello wrote: > Hi Dave, > > many thanks. > > On 22/09/2015 23:27, Dave Chinner wrote: > >Urk, the command should be "fsync", not "sync". Regardless, the > >last bmap/fiemap pair shows something interesting: > > > >bmap-vp: > > > >>/media/p6/testfile: > >> EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS > >> 0: [0..127]: 96..223 0 (96..223) 128 00000 > >> 1: [128..2047]: hole 1920 > >> 2: [2048..2559]: 2144..2655 0 (2144..2655) 512 10000 > >fiemap -v: .... > >and so should look the same as the fiemap output. Can you run this > >test again, this time with s/sync/fsync so the files are clean when Ok, so a preceding fsync results in bmap displaying all data ranges being written. Hmmm - I'll need to look into that, it's likely not a problem but just a longstanding bmap wart that fiemap doesn't have... > >Next, can you compile your kernel with CONFIG_XFS_DEBUG=y and rerun > >the tests? Does anything interesting appear in dmesg during the test > >run? Nothing in dmesg? > >Not actually useful - I need to know what is happening inside the > >unlinkat() call. I'm going to need a trace-cmd event dump of that > >xfs_io command and the subsequent rm (at least for the first couple > >of seconds of the rm). Please put the output file from the trace-cmd > >record command on a tmpfs filesystem so it doesn't pollute the xfs > >event trace ;) > > > I set some traces inside fs/namei.c do_unlinkat() > > root[243] vpc24 (master) /home/angelo/xfstests > # ./start_xfs_test.sh > QA output created by 308 > [ 144.822616] XFS (mmcblk0p5): Mounting V4 Filesystem > [ 145.074537] XFS (mmcblk0p5): Starting recovery (logdev: internal) > [ 145.107298] XFS (mmcblk0p5): Ending recovery (logdev: internal) > Silence is golden > [ 145.413606] do_unlinkat(): entering > [ 145.417124] do_unlinkat(): retry > [ 145.421156] do_unlinkat(): retry_delegate > [ 145.425920] do_unlinkat(): vfs_unlink returns 0 > [ 145.430950] do_unlinkat(): exit2 I think you'll find it's the deferred __fput() run from task_work_run() that does all the work of freeing the extents in the file. task_work_run() is executed before the process returns to userspace.... > At least that function "seems" to complete, but, as from my previous > message > looks like strace was not showing nothig over it. > > I captured about 10 seconds of events after the "hang" on 308. Hope > they are > enough. I need to see the events that lead up to the hang, so you need to start tracing before you run the test script, then stop tracing once the hang has occurred. If the trace doesn't have events from the processes the test runs, then you haven't captured the right events... Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Wed Sep 23 17:45:33 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id CC6197F37 for ; Wed, 23 Sep 2015 17:45:33 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 7F7A2304032 for ; Wed, 23 Sep 2015 15:45:33 -0700 (PDT) X-ASG-Debug-ID: 1443048327-04bdf04627a8f40001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id TKTo5Nt5RPE7RlmF for ; Wed, 23 Sep 2015 15:45:27 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BUBwCKKgNWPOV8LHlVCIMkVGmGWaJIDAECAwaKeYsthXcEAgKBS00BAQEBAQEHAQEBAUE/hCQBAQEDATocIwULCAMOCgklDwUlAwcaE4gmB8wLAQsgGYYThUSENgkFSQeELAWVZ4USh3SBVJVug22EdiwziCWBRwEBAQ Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 24 Sep 2015 08:06:26 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeseH-0004Hi-Nr; Thu, 24 Sep 2015 08:36:25 +1000 Date: Thu, 24 Sep 2015 08:36:25 +1000 From: Dave Chinner To: Brian Foster Cc: xfs@oss.sgi.com Subject: Re: [PATCH v2 02/12] libxfs: track largest metadata LSN in use via verifiers Message-ID: <20150923223625.GR19114@dastard> X-ASG-Orig-Subj: Re: [PATCH v2 02/12] libxfs: track largest metadata LSN in use via verifiers References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> <1441997742-37160-3-git-send-email-bfoster@redhat.com> <20150923034406.GR3902@dastard> <20150923131831.GB37210@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150923131831.GB37210@bfoster.bfoster> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1443048327 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22838 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Wed, Sep 23, 2015 at 09:18:31AM -0400, Brian Foster wrote: > On Wed, Sep 23, 2015 at 01:44:06PM +1000, Dave Chinner wrote: > > On Fri, Sep 11, 2015 at 02:55:32PM -0400, Brian Foster wrote: > > > + > > > + pthread_mutex_lock(&libxfs_max_lsn_lock); > > > + > > > + max_cycle = CYCLE_LSN(libxfs_max_lsn); > > > + max_block = BLOCK_LSN(libxfs_max_lsn); > > > + > > > + if ((cycle > max_cycle) || > > > + (cycle == max_cycle && block > max_block)) > > > + libxfs_max_lsn = lsn; Actually, we have XFS_LSN_CMP(lsn1, lsn2) for this. i.e. if (XFS_LSN_CMP(lsn, libxfs_max_lsn) > 0) libxfs_max_lsn = lsn; > > > + > > > + pthread_mutex_unlock(&libxfs_max_lsn_lock); > > > > This will have the same lock contention problems that the kernel > > code would have had - my repair scalablity tests regularly reach > > over 1GB/s of metadata being prefetched through tens of threads, so > > this is going have a significant impact on performance in those > > tests.... > > > > Hmm, Ok. I initially didn't have locking here (by accident) but > reproduced some breakage for which the exact details escape me. I > suspect it was a test and set race. > > I suppose we could try doing something like what we plan to do on the > kernel side in terms of a racy check followed by the locked check so the > lock contention goes away once we find the max lsn. The context here is > different, however, in that we're using a 64-bit LSN rather than > independently updated cycle and block fields. It could also take a while > to stabilize the max lsn depending on the fs. (There are some details on > the kernel side I'd like to get worked out first as well). It still has to work on 32 bit machines, where 64 bit operations are not atomic.... > Perhaps we could try to make this smarter... in the case where either > the log has been zeroed or we've identified an LSN beyond the current > log state, we only really need to track the max cycle value since a log > format is imminent at that point. In the case where the fs is > consistent, we could seed the starting value with the current log lsn, > or track per-ag max LSNs without locking and compare them at at the end, > etc. Yes, we should seen the initial "max lsn" with whatever we find in the log, regardless of whether the fs is consistent or not... Also, per-ag max lsn tracking would break the lock up - that will bring scope down to the point where contention won't be a problem... > I'll have to think about this some more and see what's effective. I'd > also like to quantify the effect the current locking has on performance > if possible. Can you provide a brief description of your typical repair > test that you would expect this to hurt? E.g., a large fs, many AGs, > populated with fs_mark and repaired with many threads..? Any special > storage configuration? Thanks. Just my usual 500TB fs_mark test... $ cat ~/tests/fsmark-50-test-xfs.sh #!/bin/bash QUOTA= MKFSOPTS= NFILES=100000 DEV=/dev/vdc LOGBSIZE=256k while [ $# -gt 0 ]; do case "$1" in -q) QUOTA="uquota,gquota,pquota" ;; -N) NFILES=$2 ; shift ;; -d) DEV=$2 ; shift ;; -l) LOGBSIZE=$2; shift ;; --) shift ; break ;; esac shift done MKFSOPTS="$MKFSOPTS $*" echo QUOTA=$QUOTA echo MKFSOPTS=$MKFSOPTS echo DEV=$DEV sudo umount /mnt/scratch > /dev/null 2>&1 sudo mkfs.xfs -f $MKFSOPTS $DEV sudo mount -o nobarrier,logbsize=$LOGBSIZE,$QUOTA $DEV /mnt/scratch sudo chmod 777 /mnt/scratch cd /home/dave/src/fs_mark-3.3/ sudo sh -c "echo 1 > /proc/sys/fs/xfs/stats_clear" time ./fs_mark -D 10000 -S0 -n $NFILES -s 0 -L 32 \ -d /mnt/scratch/0 -d /mnt/scratch/1 \ -d /mnt/scratch/2 -d /mnt/scratch/3 \ -d /mnt/scratch/4 -d /mnt/scratch/5 \ -d /mnt/scratch/6 -d /mnt/scratch/7 \ -d /mnt/scratch/8 -d /mnt/scratch/9 \ -d /mnt/scratch/10 -d /mnt/scratch/11 \ -d /mnt/scratch/12 -d /mnt/scratch/13 \ -d /mnt/scratch/14 -d /mnt/scratch/15 \ | tee >(stats --trim-outliers | tail -1 1>&2) sync echo Repair sudo umount /mnt/scratch time sudo xfs_repair -o bhash=100101 -v -v -t 1 $DEV time sudo mount -o nobarrier,logbsize=$LOGBSIZE,$QUOTA $DEV /mnt/scratch echo bulkstat files time ( sudo ~/src/xfstests-dev/src/bstat -q /mnt/scratch 1024 | wc -l ) echo walking files ~/tests/walk-scratch.sh echo removing files for f in /mnt/scratch/* ; do time rm -rf $f & done wait sudo umount /mnt/scratch $ -- Dave Chinner david@fromorbit.com From david@fromorbit.com Wed Sep 23 18:11:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 6084F7F37 for ; Wed, 23 Sep 2015 18:11:08 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id E2573AC006 for ; Wed, 23 Sep 2015 16:11:04 -0700 (PDT) X-ASG-Debug-ID: 1443049861-04cbb033b2b2ed0001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id UIaTNd60UYT7cSSs for ; Wed, 23 Sep 2015 16:11:01 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2A7BwBZMANWPOV8LHldgySBPYZZolQBAgMGinmRJAQCAoFITQEBAQEBAQcBAQEBQT+EJAEBAQMBOhwoCwgDDgoJJQ8FJQMHGgESiCYHzA0MIBmGE4VEhRSELAWVZ40GgVSNM4NsiDyEdiwziWwBAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 24 Sep 2015 08:40:41 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZetBQ-0004Ka-VF; Thu, 24 Sep 2015 09:10:40 +1000 Date: Thu, 24 Sep 2015 09:10:40 +1000 From: Dave Chinner To: Brian Foster , xfs@oss.sgi.com Subject: Re: [PATCH] xfs_io: Implement inodes64 command - bug in XFS_IOC_FSINUMBERS? Message-ID: <20150923231040.GS19114@dastard> X-ASG-Orig-Subj: Re: [PATCH] xfs_io: Implement inodes64 command - bug in XFS_IOC_FSINUMBERS? References: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> <20150921220832.GB19114@dastard> <20150922075432.GC26699@redhat.com> <20150922122238.GA46026@bfoster.bfoster> <20150922220054.GL19114@dastard> <20150923102834.GA4490@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150923102834.GA4490@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1443049861 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22840 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Wed, Sep 23, 2015 at 12:28:34PM +0200, Carlos Maiolino wrote: > Howdy folks, > > I was working in implementing the suggested feature in my patch, about getting > the next inode used after one is provided, and I hit something that I'm not really > sure if this might be considered a bug, or just a work form. > > XFS_IOC_FSINUMBERS, is supposed to be called with a zeroed > xfs_fsop_bulkreq.lastip, so at each call, kernel will update this number to the > last inode returned, and, the next call will return in xfs_inogrp.xi_startino, > the next existing inode after .lastip. > > So, I was expecting that, passing a non-zero .lastip at the first call, I would > be able to get the next inode right after the one I passed through .lastip, but, > after some tests and reading the code, I noticed that this is not the case. XFS_IOC_FSNUMBERS is not a "does this inode exist" query API - you use the bulkstat interface for that. XFS_IOC_FSNUMBERS is for iterating the "inode table", and it's API returns records, not individual inodes. Those records contain information about a chunk of inodes, not individual inodes. The "lastino" cookie it uses always points to the last inode in the last chunk it returns - the next iteration will start at the chunk *after* the one that contains lastino. Hence it is behaving as intended... > I'm not sure if this is the desired behavior or not, but, I'd say that, if the > inode passed in .lastip, is not the first in the chunk, the output should start > for its own chunk, instead of the next one, but, I prefer to see you folks POV > before starting to fix something that I'm not sure if it's actually broken :-) It doesn't matter if it is "desired behaviour" or not, we can't change it. If we change it we risk breaking userspace applications that relies on it working the way it currently does. Most likely that application will be xfsdump, and the breakage will be silent and very hard to detect.... Perhaps reading the recent history fs/xfs/xfs_itable.c would be instructive. ;) Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Wed Sep 23 19:39:57 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 4ABCC7F47 for ; Wed, 23 Sep 2015 19:39:57 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id CBE68AC006 for ; Wed, 23 Sep 2015 17:39:53 -0700 (PDT) X-ASG-Debug-ID: 1443055190-04cb6c6b04a3460001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id zuLSruMmq8DtN17Q for ; Wed, 23 Sep 2015 17:39:51 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CmCgB8RQNWPOV8LHldgySBPYZZolQBAQEBAQEGinmRJAICAQECgUlNAQEBAQEBBwEBAQFBP4QkAQEBAwEnExweBQULCAMOCgklDwUlAwcaE4gmB8t6AQEBBwIBHxmGE4VEhQ0HhCwFlWeNBpsvgnQcgWYsM4gmJYEhAQEB Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 24 Sep 2015 10:07:35 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZeuXX-0004RJ-3Y; Thu, 24 Sep 2015 10:37:35 +1000 Date: Thu, 24 Sep 2015 10:37:35 +1000 From: Dave Chinner To: Brian Foster Cc: xfs@oss.sgi.com Subject: Re: [PATCH v2 03/12] libxfs: don't hardcode cycle 1 into unmount op header Message-ID: <20150924003735.GT19114@dastard> X-ASG-Orig-Subj: Re: [PATCH v2 03/12] libxfs: don't hardcode cycle 1 into unmount op header References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> <1441997742-37160-4-git-send-email-bfoster@redhat.com> <20150923034844.GS3902@dastard> <20150923132200.GC37210@bfoster.bfoster> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150923132200.GC37210@bfoster.bfoster> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1443055190 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22843 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Wed, Sep 23, 2015 at 09:22:00AM -0400, Brian Foster wrote: > On Wed, Sep 23, 2015 at 01:48:44PM +1000, Dave Chinner wrote: > > On Fri, Sep 11, 2015 at 02:55:33PM -0400, Brian Foster wrote: > > > The libxfs helper to write a log record after zeroing the log fills much > > > of the record header and unmount record with dummy data. It also > > > hardcodes the cycle number into the transaction oh_tid field as the > > > kernel expects to find the cycle stamped at the top of each block and > > > the original oh_tid value packed into h_cycle_data of the record header. > > > > > > The log clearing code requires the ability to format the log to an > > > arbitrary cycle number to fix v5 superblock log recovery ordering > > > problems. As a result, the unmount record helper must not hardcode a > > > cycle of 1. > > > > > > Fix up libxfs_log_header() to pack the unmount record appropriately, as > > > is already done for extra blocks that might exist beyond the record. Use > > > h_cycle_data for the original 32-bit word of the log record data block > > > and stamp the cycle number in its place. This allows unmount_record() to > > > work for arbitrary cycle numbers and libxfs_log_header() to pack a cycle > > > value that matches the lsn used in the record header. Note that this > > > patch does not change behavior as the lsn is still hardcoded to (1:0). > > > > > > Signed-off-by: Brian Foster > > > --- > > > libxfs/rdwr.c | 23 ++++++++++++++++------- > > > 1 file changed, 16 insertions(+), 7 deletions(-) > > > > > > diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c > > > index bc77699..ef18749 100644 > > > --- a/libxfs/rdwr.c > > > +++ b/libxfs/rdwr.c > > > @@ -122,7 +122,7 @@ static void unmount_record(void *p) > > > } magic = { XLOG_UNMOUNT_TYPE, 0, 0 }; > > > > > > memset(p, 0, BBSIZE); > > > - op->oh_tid = cpu_to_be32(1); > > > + op->oh_tid = cpu_to_be32(0xb0c0d0d0); > > > op->oh_len = cpu_to_be32(sizeof(magic)); > > > op->oh_clientid = XFS_LOG; > > > op->oh_flags = XLOG_UNMOUNT_TRANS; > > > @@ -188,10 +188,6 @@ libxfs_log_header( > > > > > > len = ((version == 2) && sunit) ? BTOBB(sunit) : 1; > > > > > > - /* note that oh_tid actually contains the cycle number > > > - * and the tid is stored in h_cycle_data[0] - that's the > > > - * way things end up on disk. > > > - */ > > > > This note needs to be hoisted up to the setting of op->oh_tid to > > explain the magic number being used... > > > > This requires that I understand what the magic number being used > actually means. Any ideas? ;) When this gets unpacked by log recovery, the head->h_cycle_data[0] value gets written back over the op->oh_tid of the unmount record, and so we see an unmount record with a transaction ID of 0xb0c0d0d0. On seeing that magic number in an unmount record we know it was written by userspace and whatever was in the log is now ancient history. > I just assumed it was a dummy tid value. It's a canary (sort of). *ding* *ding* *ding* Obscure Magic Number Reference Acheivement Unlocked! [BC: ancient history. Dodo: a dead canary (sort of). ;) ] > The comment removed above just > explains why that value is being put where it is (cycle value in oh_tid > and tid value in h_cycle_data) as the original code implicitly > implements the cycle data packing. That is undone by this patch. The > packing is now done explicitly (with its own comments) in the caller and > thus the original comment is irrelevant. Fair enough - I didn't connect the two bits properly. Hmmm - this code does not CRC the unmount record on disk and we don't validate the unmount record CRC in the kernel as valid in the kernel before we use it, because it never gets to the unpack stage; we just look to see if ophdr->oh_flags contains XLOG_UNMOUNT_TRANS and then we use it... If we are writing a new lsn into it now, should we be CRCing this unmount record? Cheers, Dave. -- Dave Chinner david@fromorbit.com From veilletechno-irts@univ-nantes.fr Thu Sep 24 03:22:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 38B897F37 for ; Thu, 24 Sep 2015 03:22:08 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 187488F804B for ; Thu, 24 Sep 2015 01:22:05 -0700 (PDT) X-ASG-Debug-ID: 1443082917-04bdf04622b4630001-NocioJ Received: from smtp-tls.univ-nantes.fr (smtptls2-lmb.cpub.univ-nantes.fr [193.52.103.111]) by cuda.sgi.com with ESMTP id pJGDEl2StYcIB61m for ; Thu, 24 Sep 2015 01:21:57 -0700 (PDT) X-Barracuda-Envelope-From: veilletechno-irts@univ-nantes.fr X-Barracuda-Apparent-Source-IP: 193.52.103.111 Received: from localhost (localhost [127.0.0.1]) by smtp-tls.univ-nantes.fr (Postfix) with ESMTP id 551EE40177B; Thu, 24 Sep 2015 10:21:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at smtptls1-lmb.cpub.univ-nantes.fr Received: from smtp-tls.univ-nantes.fr ([127.0.0.1]) by localhost (smtptls2-lmb.cpub.univ-nantes.fr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vMXRK8Lw70mg; Thu, 24 Sep 2015 10:21:57 +0200 (CEST) Received: from [172.20.13.174] (unknown [172.20.13.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-tls.univ-nantes.fr (Postfix) with ESMTPSA id 324E640171F; Thu, 24 Sep 2015 10:21:57 +0200 (CEST) Subject: Re: xfstests, bad generic tests 009 and 308 To: Dave Chinner X-ASG-Orig-Subj: Re: xfstests, bad generic tests 009 and 308 References: <55FC3E0E.9060506@nomovok.com> <20150918224412.GE26895@dastard> <55FFE665.7040004@nomovok.com> <20150921225244.GD19114@dastard> <56028249.7040103@univ-nantes.fr> <20150923220444.GP19114@dastard> Cc: xfs@oss.sgi.com From: Yann Dupont - Veille Techno Message-ID: <5603B240.4030609@univ-nantes.fr> Date: Thu, 24 Sep 2015 10:20:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: <20150923220444.GP19114@dastard> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Barracuda-Connect: smtptls2-lmb.cpub.univ-nantes.fr[193.52.103.111] X-Barracuda-Start-Time: 1443082917 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.60 X-Barracuda-Spam-Status: No, SCORE=0.60 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22851 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words Le 24/09/2015 00:04, Dave Chinner a écrit : > On Wed, Sep 23, 2015 at 12:43:21PM +0200, Yann Dupont - Veille Techno wrote: >> Le 22/09/2015 00:52, Dave Chinner a écrit : >>> As it is, I highly recommend that you try a current 4.3 kernel, as >>> there are several code fixes in the XFS kernel code that work >>> around compiler issues we know about. AFAIA, the do_div() asm bug >>> that trips recent gcc optimisations isn't in the upstream kernel >>> yet, but that can be worked around by setting >>> CONFIG_CC_OPTIMIZE_FOR_SIZE=y in your build. >> Hi dave, >> >> I can confirm that CONFIG_CC_OPTIMIZE_FOR_SIZE=y is (was ?) the only >> way for me to have reliable XFS kernel code on different arm >> platforms (Marvell kirkwood, Allwinner A20, Amlogic S805), no matter >> what recent gcc version I've been using. >> >> I must admit I was cross-compiling from X86-64 too, but I think (not >> sure) that it was also the case with native gcc. >> >> I must also admit that I didn't tried since some months, because >> CONFIG_CC_OPTIMIZE_FOR_SIZE=y was the silver bullet for arm xfs >> kernel crashes. This crash was difficult to understand because it >> occurs quite randomly (I.e it can take several hours to trigger) >> >> If there's a patch floating around for gcc (or kernel), I'm >> interested to test. > See this subthread from august: > > http://oss.sgi.com/archives/xfs/2015-08/msg00234.html Oh, missed this thread. Thanks a lot for the pointer, will try this patch ! Cheers, From jtulak@redhat.com Thu Sep 24 03:28:31 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 1C34A7F37 for ; Thu, 24 Sep 2015 03:28:31 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 8C80DAC005 for ; Thu, 24 Sep 2015 01:28:27 -0700 (PDT) X-ASG-Debug-ID: 1443083305-04cb6c6b06acd00001-NocioJ Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) by cuda.sgi.com with ESMTP id vexVV5cGUBWFcpY1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 24 Sep 2015 01:28:25 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-RBL-Trusted-Forwarder: 209.85.223.175 Received: by ioii196 with SMTP id i196so69367968ioi.3 for ; Thu, 24 Sep 2015 01:28:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YSMifWCb4TDsU+1sLEqRL7FQ3FF6IPiozS7ZY/lHu64=; b=gMSzy54gkW8Q7djN7qQ0MNgTdAMfsCwC2tVRqjHv+ZeZrb9haPGr9YHuq+uX6BSuzB vG9LZLWOONRx+m2wn3gvC4FFxM84CApOH5lFXrYi1iEpc/L557GqyYaOW8C3pwoDv+De lTHc/rkbpok43aavx3zOf6vhaF5MAU1O5VbBrna6EXZjOgBit1MMZwBwDkFbUxFZbmIX vwQ09QbIXPBItTQwT4xxb/G6Br5nwOESWBbGxRZ8/hAh4bPuVfn79kTyG/yKDELj5z/I s3bhOxA89ujOPIFUKpuvQ817cR7OvypXO74qetvqfa4E7W7taartjYKBFj7iPKhSqFjq nOWA== X-Gm-Message-State: ALoCoQka/SEh9nOYF0XH6mk9A+lpqQMuafV5Zfn96EOIjpjo05vDJSeLQuNvNWHrIaduPN5Jbf8r X-Received: by 10.107.25.71 with SMTP id 68mr40383225ioz.46.1443083305363; Thu, 24 Sep 2015 01:28:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Thu, 24 Sep 2015 01:28:05 -0700 (PDT) In-Reply-To: <20150923031532.GN3902@dastard> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> <1442311164-12921-5-git-send-email-jtulak@redhat.com> <20150923031532.GN3902@dastard> From: Jan Tulak Date: Thu, 24 Sep 2015 10:28:05 +0200 Message-ID: Subject: Re: [PATCH 04/14] xfsprogs: prefix XATTR_LIST_MAX with XFS_ To: Dave Chinner X-ASG-Orig-Subj: Re: [PATCH 04/14] xfsprogs: prefix XATTR_LIST_MAX with XFS_ Cc: xfs-oss Content-Type: multipart/alternative; boundary=001a113ff20ecc58aa05207a0384 X-Barracuda-Connect: mail-io0-f175.google.com[209.85.223.175] X-Barracuda-Start-Time: 1443083305 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22851 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --001a113ff20ecc58aa05207a0384 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 23, 2015 at 5:15 AM, Dave Chinner wrote: > On Tue, Sep 15, 2015 at 11:59:14AM +0200, Jan Tulak wrote: > > WILL CHANGE THE COMMIT MESSAGE. > > OK? > All right, I make the renaming with define - though I'm not sure > > that with the ifdef for OS X and SIZE_MAX moved to a standalone patch > > we need it - shouldn't be this change rather dropped? > > > > Signed-off-by: Jan Tulak > > --- > > include/xfs.h | 2 ++ > > libhandle/handle.c | 4 ++-- > > libhandle/jdm.c | 4 ++-- > > 3 files changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/include/xfs.h b/include/xfs.h > > index bc94068..8ee0106 100644 > > --- a/include/xfs.h > > +++ b/include/xfs.h > > @@ -53,6 +53,8 @@ > > # define ASSERT(EX) ((void) 0) > > #endif > > > > +#define XFS_XATTR_LIST_MAX XATTR_LIST_MAX > > + > > This does not belong here - it is a limit that applies to the ioctl > API and so must be the same in userspace and the kernel. Such > definitions belong in libxfs/xfs_fs.h, and should respect local OS > limits if defined. e.g. something like: > > #ifdef XATTR_LIST_MAX > #define XFS_XATTR_LIST_MAX XATTR_LIST_MAX > #else > #define XFS_XATTR_LIST_MAX 65536 > #endif > > =E2=80=8BOK, =E2=80=8Bthat makes sense. > Will work on both the kernel and userspace side. This will also need > a kernel side patch... =E2=80=8BNow, this is something where I may need a bit help/confirmation, I= guess.=E2=80=8B What I suppose I should do is: 1) Clone linux-xfs (git:// git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git) 2) Edit linux-xfs/fs/xfs/libxfs/xfs_fs.h and add the same change there 3) Send it to this mailing list as usual, with "[PATCH] xfs: ..." (The same goes for the other patch with the kernel need too.) Is it all right? Correct repository URL? :-) Thanks, Jan --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --001a113ff20ecc58aa05207a0384 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Se= p 23, 2015 at 5:15 AM, Dave Chinner <david@fromorbit.com> wrote:
On Tue, Sep 15, 2015 at 11:59:14A= M +0200, Jan Tulak wrote:
> WILL CHANGE THE COMMIT MESSAGE.

OK?=C2=A0
> All right, I make the renaming with define - though I'm not sure > that with the ifdef for OS X and SIZE_MAX moved to a standalone patch<= br> > we need it - shouldn't be this change rather dropped?
>
> Signed-off-by: Jan Tulak <jtulak@redhat.com>
> ---
>=C2=A0 include/xfs.h=C2=A0 =C2=A0 =C2=A0 | 2 ++
>=C2=A0 libhandle/handle.c | 4 ++--
>=C2=A0 libhandle/jdm.c=C2=A0 =C2=A0 | 4 ++--
>=C2=A0 3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/include/xfs.h b/include/xfs.h
> index bc94068..8ee0106 100644
> --- a/include/xfs.h
> +++ b/include/xfs.h
> @@ -53,6 +53,8 @@
>=C2=A0 # define ASSERT(EX)=C2=A0 ((void) 0)
>=C2=A0 #endif
>
> +#define XFS_XATTR_LIST_MAX XATTR_LIST_MAX
> +

This does not belong here - it is a limit that applies to the ioctl<= br> API and so must be the same in userspace and the kernel. Such
definitions belong in libxfs/xfs_fs.h, and should respect local OS
limits if defined. e.g. something like:

#ifdef XATTR_LIST_MAX
#define XFS_XATTR_LIST_MAX XATTR_LIST_MAX
#else
#define XFS_XATTR_LIST_MAX 65536
#endif


=E2=80=8BOK, =E2=80=8Bthat makes se= nse.

=C2=A0
Will work on both the kernel and userspace side. This will also need
a kernel side patch...

=E2=80=8BNow, this is = something where I may need a bit help/confirmation, I guess.=E2=80=8B
=
What I suppose I should do is:

1) Clone linux-xfs= (git://git.kernel.org/pub/scm/linux/kernel/git/dgc/lin= ux-xfs.git)
2) Edit=C2=A0linux-xfs/fs/xfs/libxfs/xfs_fs.h and a= dd the same change there
3) Send it to this mailing list as usual, = with "[PATCH] xfs: ..."

(The same goes for= the other patch with the kernel need too.)

Is it all = right? Correct repository URL? :-)

Thanks,
Ja= n

--
--001a113ff20ecc58aa05207a0384-- From cmaiolino@redhat.com Thu Sep 24 03:47:16 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id DE83E7F37 for ; Thu, 24 Sep 2015 03:47:16 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id A23378F8035 for ; Thu, 24 Sep 2015 01:47:16 -0700 (PDT) X-ASG-Debug-ID: 1443084435-04bdf04622b4cf0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id VHPILNswt3CtiJGw (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 24 Sep 2015 01:47:15 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 1905CC0AF3D2; Thu, 24 Sep 2015 08:47:15 +0000 (UTC) Received: from redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8O8lB8R000797 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 24 Sep 2015 04:47:14 -0400 Date: Thu, 24 Sep 2015 10:47:11 +0200 From: Carlos Maiolino To: Dave Chinner Cc: Brian Foster , xfs@oss.sgi.com Subject: Re: [PATCH] xfs_io: Implement inodes64 command - bug in XFS_IOC_FSINUMBERS? Message-ID: <20150924084711.GA25260@redhat.com> X-ASG-Orig-Subj: Re: [PATCH] xfs_io: Implement inodes64 command - bug in XFS_IOC_FSINUMBERS? Mail-Followup-To: Dave Chinner , Brian Foster , xfs@oss.sgi.com References: <1442825768-5793-1-git-send-email-cmaiolino@redhat.com> <20150921220832.GB19114@dastard> <20150922075432.GC26699@redhat.com> <20150922122238.GA46026@bfoster.bfoster> <20150922220054.GL19114@dastard> <20150923102834.GA4490@redhat.com> <20150923231040.GS19114@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150923231040.GS19114@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443084435 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Thanks Brian and Eric, I'll rework my patch according to this talk, On Thu, Sep 24, 2015 at 09:10:40AM +1000, Dave Chinner wrote: > On Wed, Sep 23, 2015 at 12:28:34PM +0200, Carlos Maiolino wrote: > > Howdy folks, > > > > I was working in implementing the suggested feature in my patch, about getting > > the next inode used after one is provided, and I hit something that I'm not really > > sure if this might be considered a bug, or just a work form. > > > > XFS_IOC_FSINUMBERS, is supposed to be called with a zeroed > > xfs_fsop_bulkreq.lastip, so at each call, kernel will update this number to the > > last inode returned, and, the next call will return in xfs_inogrp.xi_startino, > > the next existing inode after .lastip. > > > > So, I was expecting that, passing a non-zero .lastip at the first call, I would > > be able to get the next inode right after the one I passed through .lastip, but, > > after some tests and reading the code, I noticed that this is not the case. > > XFS_IOC_FSNUMBERS is not a "does this inode exist" query API - you > use the bulkstat interface for that. XFS_IOC_FSNUMBERS is for > iterating the "inode table", and it's API returns records, not > individual inodes. > > Those records contain information about a chunk of inodes, not > individual inodes. The "lastino" cookie it uses always points to the > last inode in the last chunk it returns - the next iteration will > start at the chunk *after* the one that contains lastino. > > Hence it is behaving as intended... > > > I'm not sure if this is the desired behavior or not, but, I'd say that, if the > > inode passed in .lastip, is not the first in the chunk, the output should start > > for its own chunk, instead of the next one, but, I prefer to see you folks POV > > before starting to fix something that I'm not sure if it's actually broken :-) > > It doesn't matter if it is "desired behaviour" or not, we can't > change it. If we change it we risk breaking userspace applications > that relies on it working the way it currently does. Most likely > that application will be xfsdump, and the breakage will be silent > and very hard to detect.... I thought about this possibility too, but didn't mention in my e-mail, but, it's good to know that. > > Perhaps reading the recent history fs/xfs/xfs_itable.c would be > instructive. ;) > I certainly will :) Cheers. -- Carlos From jtulak@redhat.com Thu Sep 24 04:26:57 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 44ADD7F37 for ; Thu, 24 Sep 2015 04:26:57 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id C379EAC005 for ; Thu, 24 Sep 2015 02:26:56 -0700 (PDT) X-ASG-Debug-ID: 1443086814-04bdf04622b5df0001-NocioJ Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) by cuda.sgi.com with ESMTP id 2OF4NWcdRwuVtu2B (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 24 Sep 2015 02:26:55 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-RBL-Trusted-Forwarder: 209.85.213.172 Received: by igcpb10 with SMTP id pb10so10707889igc.1 for ; Thu, 24 Sep 2015 02:26:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b8h404X2Ifq1Fpaf9tks0PfKUgGIGxm4Qwj1lbonorw=; b=gETqBG3r96/1uHePXMkZf+30amPYm6ZEaTqty7xPNYMkNj4VoQPbnLRMbK9wL7lhgX XGW/RvQqgLzDBjZEsuCdirMOF/kbFdXVMJbUjdxzclv+0LoAjPPwq1FWe3tucYOU565X Hhk4Kv/m64JHEvNthJLsa/RwrHkx1l8AKrGuDh/KKajkRzYxGb5RBdAagIrZl+/HThOB w91uNpl/GTqUujbF//4trS5yVZ6yPHsxjRTy4Meznsof/x070mrKuQmzylsBizr/inYH Eqbx/UgLYQ+TbKngHC6v1mcP/VoL/vCLN/XtWpZIvzqIGpzLZhgjgdP+iAOvUhsTZD8y m7Ew== X-Gm-Message-State: ALoCoQmF4HifSH2OhLav8E9mucT/oTnxNd5peAPMpnY9pckgE5qPTf+6PhCVVQ8Vlv3f5nSEk9nR X-Received: by 10.50.67.179 with SMTP id o19mr26540501igt.63.1443086814413; Thu, 24 Sep 2015 02:26:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Thu, 24 Sep 2015 02:26:34 -0700 (PDT) In-Reply-To: <20150923032550.GO3902@dastard> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> <1442311164-12921-11-git-send-email-jtulak@redhat.com> <20150923032550.GO3902@dastard> From: Jan Tulak Date: Thu, 24 Sep 2015 11:26:34 +0200 Message-ID: Subject: Re: [PATCH 10/14] xfsprogs: Add a timer implementation for OS X To: Dave Chinner X-ASG-Orig-Subj: Re: [PATCH 10/14] xfsprogs: Add a timer implementation for OS X Cc: xfs-oss Content-Type: multipart/alternative; boundary=047d7bdca610f42f5905207ad455 X-Barracuda-Connect: mail-ig0-f172.google.com[209.85.213.172] X-Barracuda-Start-Time: 1443086815 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22852 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --047d7bdca610f42f5905207ad455 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 23, 2015 at 5:25 AM, Dave Chinner wrote: > On Tue, Sep 15, 2015 at 11:59:20AM +0200, Jan Tulak wrote: > > OS X does not have the timer used in xfs_repair. > > Add a simple implementation providing the required > > capabilities. > .... > > #endif /* __XFS_DARWIN_H__ */ > > diff --git a/repair/progress.c b/repair/progress.c > > index 27cbaef..0fee7dc 100644 > > --- a/repair/progress.c > > +++ b/repair/progress.c > > @@ -184,10 +184,22 @@ progress_rpt_thread (void *p) > > */ > > > > timespec.it_value.tv_sec =3D msgp->interval; > > - timespec.it_value.tv_nsec =3D 0; > > timespec.it_interval.tv_sec =3D msgp->interval; > > + /* > > + * On some platforms (like OS X), timers and time things are > slightly > > + * different: itimerspec is replaced with itimerval and timeval > struct > > + * has no tv_nsec, but just tv_usec member. > > + * For compatibility, itimerspec is a macro defined to the existi= ng > > + * itimerval on these platforms, and in such case, use usec inste= ad > > + * of nsec. > > + */ > > +#ifndef itimerspec > > + timespec.it_value.tv_nsec =3D 0; > > timespec.it_interval.tv_nsec =3D 0; > > - > > +#else > > + timespec.it_value.tv_usec =3D 0; > > + timespec.it_interval.tv_usec =3D 0; > > +#endif > > That's pretty nasty. How about this: > > memset(×pec, 0, sizeof(timespec)); > timespec.it_value.tv_sec =3D msgp->interval; > timespec.it_interval.tv_sec =3D msgp->interval; > =E2=80=8BThis is much better and elegant =E2=80=8Bsolution. :-) Cheers, Jan --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --047d7bdca610f42f5905207ad455 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 23, 2015 at 5:25 AM, Dave Chinner <david@fromor= bit.com> wrote:
On Tue, Sep 15, 2015 at 11:59:20AM +0200, Jan Tulak wrote:
> OS X does not have the timer used in xfs_repair.
> Add a simple implementation providing the required
> capabilities.
....
>=C2=A0 #endif=C2=A0 =C2=A0 =C2=A0 =C2=A0/* __XFS= _DARWIN_H__ */
> diff --git a/repair/progress.c b/repair/progress.c
> index 27cbaef..0fee7dc 100644
> --- a/repair/progress.c
> +++ b/repair/progress.c
> @@ -184,10 +184,22 @@ progress_rpt_thread (void *p)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 */
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timespec.it_value.tv_sec =3D msgp->interv= al;
> -=C2=A0 =C2=A0 =C2=A0timespec.it_value.tv_nsec =3D 0;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timespec.it_interval.tv_sec =3D msgp->int= erval;
> +=C2=A0 =C2=A0 =C2=A0/*
> +=C2=A0 =C2=A0 =C2=A0 * On some platforms (like OS X), timers and time= things are slightly
> +=C2=A0 =C2=A0 =C2=A0 * different: itimerspec is replaced with itimerv= al and timeval struct
> +=C2=A0 =C2=A0 =C2=A0 * has no tv_nsec, but just tv_usec member.
> +=C2=A0 =C2=A0 =C2=A0 * For compatibility, itimerspec is a macro defin= ed to the existing
> +=C2=A0 =C2=A0 =C2=A0 * itimerval on these platforms, and in such case= , use usec instead
> +=C2=A0 =C2=A0 =C2=A0 * of nsec.
> +=C2=A0 =C2=A0 =C2=A0 */
> +#ifndef itimerspec
> +=C2=A0 =C2=A0 =C2=A0timespec.it_value.tv_nsec =3D 0;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timespec.it_interval.tv_nsec =3D 0;
> -
> +#else
> +=C2=A0 =C2=A0 =C2=A0timespec.it_value.tv_usec =3D 0;
> +=C2=A0 =C2=A0 =C2=A0timespec.it_interval.tv_usec =3D 0;
> +#endif

That's pretty nasty. How about this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 memset(&timespec, 0, sizeof(timespec));
=C2=A0 =C2=A0 =C2=A0 =C2=A0 timespec.it_value.tv_sec =3D msgp->interval;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 timespec.it_interval.tv_sec =3D msgp->interv= al;

=E2=80=8BThis is= much better and elegant =E2=80=8Bsolution. :-)

Cheers,
Jan


--
=
--047d7bdca610f42f5905207ad455-- From jtulak@redhat.com Thu Sep 24 04:34:21 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id DE0A37F3F for ; Thu, 24 Sep 2015 04:34:21 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id CE15D304043 for ; Thu, 24 Sep 2015 02:34:18 -0700 (PDT) X-ASG-Debug-ID: 1443087257-04cbb033b3c0100001-NocioJ Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by cuda.sgi.com with ESMTP id RkCl1iOA821x66Ex (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 24 Sep 2015 02:34:17 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-RBL-Trusted-Forwarder: 209.85.223.171 Received: by ioiz6 with SMTP id z6so70272038ioi.2 for ; Thu, 24 Sep 2015 02:34:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gGOgpEbIJgG8F4MIdffUyXPuKsq/bxxtDH65Qh0hWdM=; b=E69MJ7vJSPkP2rsJtlwLwcYg6rT93UZzwfaZgKEKPnHlbLXlfe1ynJdPPtktSo8yz+ yAd1me8CsxgtAeWg3uw3P4EAHZ1UnW/tz5SqJoYq5E+lRAsDqq79nur/FhgZVLj33U5W vZALnRi/s5Dl/lH8FdQT1RyFCZPNdLeqERSubC0nu1i1XNrJEeAKcDg3kvpid/1jyknr YiGmAd4pjCWv3kKKdlVTU3SI13679VJZBEyA31j/Vwb+2bS15t6aQd0Xs++b2XqFU5Lm Sl0G06GqoV+BtjOReg+iMc0TzQJEpanMnnZjbGhSKdCz+12aLg8SEfmB7HYs11BcX01Q kuHg== X-Gm-Message-State: ALoCoQm7PZU2QyPrnn3hhAczfrv4sIpI4keVR5iZ4L0R7S/XQhtF4dsW2hsDxC5mqu3SSKrJs6Fr X-Received: by 10.107.133.151 with SMTP id p23mr51839278ioi.71.1443087256982; Thu, 24 Sep 2015 02:34:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Thu, 24 Sep 2015 02:33:57 -0700 (PDT) In-Reply-To: <20150923033218.GP3902@dastard> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> <1442311164-12921-12-git-send-email-jtulak@redhat.com> <20150923033218.GP3902@dastard> From: Jan Tulak Date: Thu, 24 Sep 2015 11:33:57 +0200 Message-ID: Subject: Re: [PATCH 11/14] xfsprogs: Add statvfs64 for osx To: Dave Chinner X-ASG-Orig-Subj: Re: [PATCH 11/14] xfsprogs: Add statvfs64 for osx Cc: xfs-oss Content-Type: multipart/alternative; boundary=001a113ec2ac552d9705207aefe2 X-Barracuda-Connect: mail-io0-f171.google.com[209.85.223.171] X-Barracuda-Start-Time: 1443087257 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22852 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --001a113ec2ac552d9705207aefe2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 23, 2015 at 5:32 AM, Dave Chinner wrote: > On Tue, Sep 15, 2015 at 11:59:21AM +0200, Jan Tulak wrote: > > Simply rename statvfs64 to statfs with a #define. > > OSX version of statvfs is missing some members, so if the renaming > > is in effect (stavfs64 is defined), don't try to use them and go > > directly for the other member value. > > > > Signed-off-by: Jan Tulak > > --- > > fsr/xfs_fsr.c | 14 ++++++++++++++ > > include/builddefs.in | 2 +- > > include/darwin.h | 5 +++++ > > 3 files changed, 20 insertions(+), 1 deletion(-) > > > > diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c > > index e1b7bd6..5f95cdc 100644 > > --- a/fsr/xfs_fsr.c > > +++ b/fsr/xfs_fsr.c > > @@ -36,6 +36,12 @@ > > # include > > #endif > > > > +#ifdef __APPLE__ > > +//# define statvfs64 statfs; > > +# include > > +# include > > +#endif > > Why is this here? We've included libxfs.h in this file, so we've > got access to the platform specific includes already, and later in > the patch you put the commented out define there... > =E2=80=8BMost likely because I messed it in a rebase during some conflict. = I try to check for these things, but apparently this one escaped. Removing it again=E2=80=8B.. Thanks for catching it. Cheers, Jan --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --001a113ec2ac552d9705207aefe2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Se= p 23, 2015 at 5:32 AM, Dave Chinner <david@fromorbit.com> wrote:
On Tue, = Sep 15, 2015 at 11:59:21AM +0200, Jan Tulak wrote:
> Simply rename statvfs64 to statfs with a #define.
> OSX version of statvfs is missing some members, so if the renaming
> is in effect (stavfs64 is defined), don't try to use them and go > directly for the other member value.
>
> Signed-off-by: Jan Tulak <jtul= ak@redhat.com>
> ---
>=C2=A0 fsr/xfs_fsr.c=C2=A0 =C2=A0 =C2=A0 =C2=A0 | 14 ++++++++++++++
>=C2=A0 include/builddefs.in |=C2=A0 2 +-
>=C2=A0 include/darwin.h=C2=A0 =C2=A0 =C2=A0|=C2=A0 5 +++++
>=C2=A0 3 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c
> index e1b7bd6..5f95cdc 100644
> --- a/fsr/xfs_fsr.c
> +++ b/fsr/xfs_fsr.c
> @@ -36,6 +36,12 @@
>=C2=A0 #=C2=A0 include <mntent.h>
>=C2=A0 #endif
>
> +#ifdef __APPLE__
> +//#=C2=A0 define statvfs64 statfs;
> +#=C2=A0 include <sys/param.h>
> +#=C2=A0 include <sys/mount.h>
> +#endif

Why is this here? We've included libxfs.h in this file, so we= 9;ve
got access to the platform specific includes already, and later in
the patch you put the commented out define there...
=E2=80=8BMost likely because I messed it in = a rebase during some conflict. I try to check for these things, but apparen= tly this one escaped. Removing it again=E2=80=8B..

Thanks for catching it.

Cheers,
Jan

--
Jan Tulak
jtulak@redhat.com= =C2=A0/ jan@tulak.me<= /div>
--001a113ec2ac552d9705207aefe2-- From bfoster@redhat.com Thu Sep 24 08:00:42 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 6FC197F37 for ; Thu, 24 Sep 2015 08:00:42 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 50366304048 for ; Thu, 24 Sep 2015 06:00:39 -0700 (PDT) X-ASG-Debug-ID: 1443099637-04cb6c6b04b2e40001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id OVCBvnA36fNJNxXd (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 24 Sep 2015 06:00:37 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 1ABFEC0B1B49; Thu, 24 Sep 2015 13:00:37 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8OD0aK5016868; Thu, 24 Sep 2015 09:00:36 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 6368E1202D2; Thu, 24 Sep 2015 09:00:35 -0400 (EDT) Date: Thu, 24 Sep 2015 09:00:35 -0400 From: Brian Foster To: Dave Chinner Cc: xfs@oss.sgi.com Subject: Re: [PATCH v2 03/12] libxfs: don't hardcode cycle 1 into unmount op header Message-ID: <20150924130034.GB42523@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH v2 03/12] libxfs: don't hardcode cycle 1 into unmount op header References: <1441997742-37160-1-git-send-email-bfoster@redhat.com> <1441997742-37160-4-git-send-email-bfoster@redhat.com> <20150923034844.GS3902@dastard> <20150923132200.GC37210@bfoster.bfoster> <20150924003735.GT19114@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150924003735.GT19114@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) 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: 1443099637 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Thu, Sep 24, 2015 at 10:37:35AM +1000, Dave Chinner wrote: > On Wed, Sep 23, 2015 at 09:22:00AM -0400, Brian Foster wrote: > > On Wed, Sep 23, 2015 at 01:48:44PM +1000, Dave Chinner wrote: > > > On Fri, Sep 11, 2015 at 02:55:33PM -0400, Brian Foster wrote: ... > > > > --- a/libxfs/rdwr.c > > > > +++ b/libxfs/rdwr.c > > > > @@ -122,7 +122,7 @@ static void unmount_record(void *p) > > > > } magic = { XLOG_UNMOUNT_TYPE, 0, 0 }; > > > > > > > > memset(p, 0, BBSIZE); > > > > - op->oh_tid = cpu_to_be32(1); > > > > + op->oh_tid = cpu_to_be32(0xb0c0d0d0); > > > > op->oh_len = cpu_to_be32(sizeof(magic)); > > > > op->oh_clientid = XFS_LOG; > > > > op->oh_flags = XLOG_UNMOUNT_TRANS; > > > > @@ -188,10 +188,6 @@ libxfs_log_header( > > > > > > > > len = ((version == 2) && sunit) ? BTOBB(sunit) : 1; > > > > > > > > - /* note that oh_tid actually contains the cycle number > > > > - * and the tid is stored in h_cycle_data[0] - that's the > > > > - * way things end up on disk. > > > > - */ > > > > > > This note needs to be hoisted up to the setting of op->oh_tid to > > > explain the magic number being used... > > > > > > > This requires that I understand what the magic number being used > > actually means. Any ideas? ;) > > When this gets unpacked by log recovery, the head->h_cycle_data[0] > value gets written back over the op->oh_tid of the unmount record, > and so we see an unmount record with a transaction ID of 0xb0c0d0d0. > On seeing that magic number in an unmount record we know it was > written by userspace and whatever was in the log is now ancient > history. > > > I just assumed it was a dummy tid value. > > It's a canary (sort of). > > *ding* > *ding* > *ding* > > Obscure Magic Number Reference Acheivement Unlocked! > > [BC: ancient history. Dodo: a dead canary (sort of). ;) ] > Hah, I figured it had to be some kind of obscure reference. ;) > > The comment removed above just > > explains why that value is being put where it is (cycle value in oh_tid > > and tid value in h_cycle_data) as the original code implicitly > > implements the cycle data packing. That is undone by this patch. The > > packing is now done explicitly (with its own comments) in the caller and > > thus the original comment is irrelevant. > > Fair enough - I didn't connect the two bits properly. > > Hmmm - this code does not CRC the unmount record on disk and we > don't validate the unmount record CRC in the kernel as valid in the > kernel before we use it, because it never gets to the unpack stage; > we just look to see if ophdr->oh_flags contains XLOG_UNMOUNT_TRANS > and then we use it... > > If we are writing a new lsn into it now, should we be CRCing this > unmount record? > Good question. I'm not so sure it's that important to crc the record in this particular context. We're reformatting the log and clearing any real data, after all. That said, when skimming back through the kernel code I had a faint recollection of why I started all of this log recovery work in the first place. ;) The previous EFI/EFD logging fixes, umount hang fixes and these LSN fixes all spilled out from the inability to effectively test torn log write detection in an effort to support XFS on pmem. Recall our previous discussion here: http://oss.sgi.com/pipermail/xfs/2015-July/042415.html I believe I made progress on that work with respect to the aforementioned discussion, but it was still very much in flux and all of this stuff got in the way of starting to test what I had at the time. The short of it is that due to that work, we'll end up doing crc verification of the head of the log before the real log recovery actually starts. I don't quite recall whether this incorporated crc verification of the unmount record in the clean log case (I suspect not), but I can add that as a TODO item to look into once I get back to that work. If there's a good enough reason to do that in the kernel, we could certainly revisit the userspace log formatting code to set a crc. Brian > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From jtulak@redhat.com Thu Sep 24 09:39:14 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 4F4797F37 for ; Thu, 24 Sep 2015 09:39:14 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3CC238F8052 for ; Thu, 24 Sep 2015 07:39:11 -0700 (PDT) X-ASG-Debug-ID: 1443105548-04cbb033b1c8540001-NocioJ Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) by cuda.sgi.com with ESMTP id NH7WRnUQPWRfPvKg (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 24 Sep 2015 07:39:09 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-RBL-Trusted-Forwarder: 209.85.213.181 Received: by igcpb10 with SMTP id pb10so16409981igc.1 for ; Thu, 24 Sep 2015 07:39:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=x9N45VhANMBXYlKR2Mfj4HN87CawjjIsBoVfkp6OBaI=; b=lZYrwyg4GU5TOeRY7Ghotfby22BfLMeZALheiL/6ZaoYZSseq5SPBGZfOEZxhOw+wp 2KFuNIZygNVF/qbTzyNt9gVUquyQavanEdnDEDXLvW8jwz6o2p4lMWIbtTcjR19yK4Ya QEcJv1uHyrU5VxW0gf2uxCIR3UrQ7IGrTGzsBrMaZsxNfv1CDydtylPdCScQax9yZeFv kkaQXjh7nrufuQCxvRl9+YVRJuBjrMV3vfMF5BL74YYE0i1ij55x7PhwAKBu8CUyX0ny qFBdT7eDUPhH1mJVrehQ4oGK7pC5YcaQ1xsodDoY2Wfc5jL5LNM5eVM/kb3/+aqXt4/S p5Xw== X-Gm-Message-State: ALoCoQmnGiUJi/wkLySV7Mx2fsEgkxAhU+EiUxyF9Ezd4EhtoTWDX4hWyHmMH1wwkQI9VxNUkuWS X-Received: by 10.50.78.69 with SMTP id z5mr861703igw.19.1443105548484; Thu, 24 Sep 2015 07:39:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.75 with HTTP; Thu, 24 Sep 2015 07:38:49 -0700 (PDT) In-Reply-To: <20150923033655.GQ3902@dastard> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> <1442311164-12921-13-git-send-email-jtulak@redhat.com> <20150923033655.GQ3902@dastard> From: Jan Tulak Date: Thu, 24 Sep 2015 16:38:49 +0200 Message-ID: Subject: Re: [PATCH 12/14] xfsprogs: make fsr use mntinfo when there is no mntent To: Dave Chinner X-ASG-Orig-Subj: Re: [PATCH 12/14] xfsprogs: make fsr use mntinfo when there is no mntent Cc: xfs-oss Content-Type: multipart/alternative; boundary=089e01184e649766d205207f3198 X-Barracuda-Connect: mail-ig0-f181.google.com[209.85.213.181] X-Barracuda-Start-Time: 1443105549 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22857 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --089e01184e649766d205207f3198 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 23, 2015 at 5:36 AM, Dave Chinner wrote: > On Tue, Sep 15, 2015 at 11:59:22AM +0200, Jan Tulak wrote: > > @@ -202,6 +205,27 @@ find_mountpoint(char *mtab, char *argname, struct > stat64 *sb) > > } > > > > while ((t =3D getmntent(mtabp))) { > > +#elif defined(HAVE_GETMNTINFO) > > + struct statfs *stats; > > + int error, i, count; > > + // because "t" is a pointer, but we don't need to use > > + // malloc for this usage > > + struct mntent t_tmp; > > + t =3D &t_tmp; > > + > > + > > + error =3D 0; > > + if ((count =3D getmntinfo(&stats, 0)) < 0) { > > + fprintf(stderr, _("%s: getmntinfo() failed: %s\n"), > > + progname, strerror(errno)); > > + return 0; > > + } > > + > > + for (i =3D 0; i < count; i++) { > > + mntinfo2mntent(&stats[i], t); > > +#else > > +# error "How do I extract info about mounted filesystems on this > platform?" > > +#endif > > No, please don't do that. Having a loop iterator split across two > separate defines is unmaintainable. Write two separate functions > with the different loop iterators, then factor the common bit out > of them into a single function. > > I did a little refactoring to solve it. What I would like to ask ab=E2=80= =8Bout is this: When I can put ifdef just inside of a function like fnc(void) { #ifdef... #else ... #endif }, with little to no code outside of the ifdef, is it better to put the ifdef outside, or keep it inside? I suppose the outside placement allows for easier changes for one of the branches when there would be a new function just for a specific branch. But on the other side, it makes it easier to forget the second function in another branch when making some change later. =E2=80=8BCheers, Jan=E2=80=8B -- =E2=80=8B-=E2=80=8B Jan Tulak jtulak@redhat.com / jan@tulak.me --089e01184e649766d205207f3198 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 23, 2015 at 5:36 AM, Dave Chinner <david@fromor= bit.com> wrote:
On Tue, Sep 15, 2015 at 11:59:22AM +0200, Jan= Tulak wrote:
> @@ -202,6 +205,27 @@ find_mountpoint(char *mtab, char *argname, struct= stat64 *sb)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0while ((t =3D getmntent(mtabp))) {
> +#elif defined(HAVE_GETMNTINFO)
> +=C2=A0 =C2=A0 =C2=A0struct statfs=C2=A0 =C2=A0*stats;
> +=C2=A0 =C2=A0 =C2=A0int error, i, count;
> +=C2=A0 =C2=A0 =C2=A0// because "t" is a pointer, but we don= 't need to use
> +=C2=A0 =C2=A0 =C2=A0// malloc for this usage
> +=C2=A0 =C2=A0 =C2=A0struct mntent t_tmp;
> +=C2=A0 =C2=A0 =C2=A0t =3D &t_tmp;
> +
> +
> +=C2=A0 =C2=A0 =C2=A0error =3D 0;
> +=C2=A0 =C2=A0 =C2=A0if ((count =3D getmntinfo(&stats, 0)) < 0)= {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fprintf(stderr, _(&qu= ot;%s: getmntinfo() failed: %s\n"),
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0progname, strerror(errno));
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 0;
> +=C2=A0 =C2=A0 =C2=A0}
> +
> +=C2=A0 =C2=A0 =C2=A0for (i =3D 0; i < count; i++) {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mntinfo2mntent(&s= tats[i], t);
> +#else
> +# error "How do I extract info about mounted filesystems on this= platform?"
> +#endif

No, please don't do that. Having a loop iterator split acro= ss two
separate defines is unmaintainable. Write two separate functions
with the different loop iterators, then factor the common bit out
of them into a single function.


I did a little refactoring to solve it. What I would like to= ask ab=E2=80=8Bout is this:
When I can p= ut ifdef just inside of a function like fnc(void) { #ifdef... #else ... #en= dif }, with little to no code outside of the ifdef, is it better to put the= ifdef outside, or keep it inside?=C2=A0
=
I suppose the outside placement allo= ws for easier changes for one of the branches when there would be a new fun= ction just for a specific branch. But on the other side, it makes it easier= to forget the second function in another branch when making some change la= ter.

=E2=80=8BChee= rs,
Jan=E2=80=8B

--
=E2=80=8B-= =E2=80=8B

--089e01184e649766d205207f3198-- From billodo@redhat.com Thu Sep 24 16:27:07 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id D74C27F37 for ; Thu, 24 Sep 2015 16:27:06 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 739A1AC005 for ; Thu, 24 Sep 2015 14:27:06 -0700 (PDT) X-ASG-Debug-ID: 1443130022-04bdf04622c9240001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id cQc94SgefY9QWQ6L (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 24 Sep 2015 14:27:02 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 649F9A444A; Thu, 24 Sep 2015 21:27:01 +0000 (UTC) Received: from redhat.com (vpn-53-197.rdu2.redhat.com [10.10.53.197]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8OLQwNM031670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Sep 2015 17:27:00 -0400 Date: Thu, 24 Sep 2015 16:26:58 -0500 From: "Bill O'Donnell" To: Dave Chinner Cc: Eric Sandeen , xfs@oss.sgi.com Subject: Re: [PATCH 5/5] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. Message-ID: <20150924212658.GA21293@redhat.com> X-ASG-Orig-Subj: Re: [PATCH 5/5] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. References: <1442923671-14125-1-git-send-email-billodo@redhat.com> <1442923671-14125-6-git-send-email-billodo@redhat.com> <56016A1E.8080103@sandeen.net> <20150922151605.GA29067@redhat.com> <20150922222636.GM19114@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150922222636.GM19114@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443130022 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 23, 2015 at 08:26:36AM +1000, Dave Chinner wrote: > On Tue, Sep 22, 2015 at 10:16:05AM -0500, Bill O'Donnell wrote: > > > > goto out; > > > > > > > > if (!proc_symlink("fs/xfs/stat", NULL, > > > > - "/sys/fs/xfs/stats/stats")) > > > > + "/sys/fs/xfs/stats/stats")) > > > > > > intentional whitespace changes? > > > > > > > goto out_remove_xfs_dir; > > > > > > > > #ifdef CONFIG_XFS_QUOTA > > > > if (!proc_create("fs/xfs/xqmstat", 0, NULL, > > > > - &xqmstat_proc_fops)) > > > > + &xqmstat_proc_fops)) > > > > goto out_remove_stat_file; > > > > if (!proc_create("fs/xfs/xqm", 0, NULL, > > > > - &xqm_proc_fops)) > > > > + &xqm_proc_fops)) > > > > > > Same question. (did checkpatch complain or something?) > > > > Yes. Checkpatch didn't like any spaces, so I turned em into tabs. > > Checkpatch should be considered harmful. > > It's a good starting point, but it ends up doing more harm than good > because it doesn't understand the subtle differences in code across > different subsystems. > > In this case, the standard we use for XFS is that multi-line > parameters should be lined up with the first parameter, unless the > new parameters don't fit on a single line, and then we back up the > indent by a tab at a time. i.e. This is correct: > > if (!proc_create("fs/xfs/xqm", 0, NULL, > &xqm_proc_fops)) > > regardless of what checkpatch says. Indeed, if checkpatch had any > brains, it would have noticed that a line break is not necessary > as this: > > if (!proc_create("fs/xfs/xqm", 0, NULL, &xqm_proc_fops)) > > fits in 80 columns just fine. > > Remember that Documentation/CodingStyle is a set of guidelines, not > a strict, enforcable set of rules. The basic guidelines canbe > summarised as: > > 1. Use the same style as the existing code in the file, > unless reviewers/maintainers ask otherwise. > 2. new files should follow the format used in other files in > the subsystem, unless reviewers/maintainer asks otherwise. > 3. Do not reformat code that you don't need to directly > modify in the patch. > 4. modify your editor to highlight common style things that > you need reminders to get right > 5. Immolate checkpatch before the plague spreads further > > As to #4, there's plenty of simple things you can do. e.g to > identify stray whitespace in files, add this to your .vimrc file > (you can do similar with emacs, google it): > > " highlight whitespace damage > highlight RedundantSpaces ctermbg=red guibg=red > match RedundantSpaces /\s\+$\| \+\ze\t/ > > This will catch things like "tab-space-tab" and it will also find > trailing whitespace at the end of lines. They will appear in red. > > > > > -#define XFS_STATS_INC(v) (per_cpu(xfsstats, current_cpu()).v++) > > > > -#define XFS_STATS_DEC(v) (per_cpu(xfsstats, current_cpu()).v--) > > > > -#define XFS_STATS_ADD(v, inc) (per_cpu(xfsstats, current_cpu()).v += (inc)) > > > > +#define XFS_STATS_INC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v++) > > > > +#define XFS_STATS_DEC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v--) > > > > +#define XFS_STATS_ADD(v, inc) (per_cpu(*xfsstats.xs_stats, current_cpu()).v += (inc)) > > > > > > Line > 80 chars > > > > I'll fix it. > > Checkpatch got changed not to warn about that, because too many > people complained about it when modifying files with >80 column > formatting. > > To that end, I also use custom column width highlights based on file > names so that line wrapping occurs automatically at the correct > spot, and when looking at code I can clearly see long lines: > > " set the textwidth to 80 characters by default > set tw=80 > > " set the textwidth to 68 characters for guilt commit messages > au BufNewFile,BufRead guilt.msg.*,.gitsendemail*,.git* set tw=68 > > " set the textwidth to 68 characters for replies (email&usenet) > au BufNewFile,BufRead .letter,mutt*,nn.*,snd.* set tw=68 > > " highlight textwidth > set cc=+1 > > If you do little things like this, the need for checkpatch goes > away. With a default tw=80 and a highlight, I only have to glance > at a patch to know it has lines longer than 80 columns in it. > > As such, I haven't used checkpatch for years, and I recommend that > you develop the right habits and automation such that you don't need > to use it after a couple of months, either... All points well taken. I'm fixing it all up in the next patch! Thanks! Bill > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com From david@fromorbit.com Thu Sep 24 17:41:45 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 864537F37 for ; Thu, 24 Sep 2015 17:41:45 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 13A02AC002 for ; Thu, 24 Sep 2015 15:41:41 -0700 (PDT) X-ASG-Debug-ID: 1443134498-04cbb033b2d6790001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id xmbfoDGvlvuN6u1E for ; Thu, 24 Sep 2015 15:41:39 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BzCwBPewRWPOV8LHldgyRUaYMqgy+iMAwBAQEBAQEGinmLKYV7AgIBAQKBRU0BAQEBAQEHAQEBAUE/hCQBAQEDASMPASMYCwULCAMOCgICBSECAg8FJQMHGhOIJge3dJQlAQsgGYEJhQqFRIUNB4JpgUMBBJVnhRKHdI8HjCiEdiwziWwBAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 25 Sep 2015 08:11:37 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZfFCq-0006kz-PU; Fri, 25 Sep 2015 08:41:36 +1000 Date: Fri, 25 Sep 2015 08:41:36 +1000 From: Dave Chinner To: Jan Tulak Cc: xfs-oss Subject: Re: [PATCH 04/14] xfsprogs: prefix XATTR_LIST_MAX with XFS_ Message-ID: <20150924224136.GU19114@dastard> X-ASG-Orig-Subj: Re: [PATCH 04/14] xfsprogs: prefix XATTR_LIST_MAX with XFS_ References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> <1442311164-12921-5-git-send-email-jtulak@redhat.com> <20150923031532.GN3902@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1443134498 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22873 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Thu, Sep 24, 2015 at 10:28:05AM +0200, Jan Tulak wrote: > On Wed, Sep 23, 2015 at 5:15 AM, Dave Chinner wrote: > > Will work on both the kernel and userspace side. This will also need > > a kernel side patch... > > > ​Now, this is something where I may need a bit help/confirmation, I guess.​ > What I suppose I should do is: > > 1) Clone linux-xfs (git:// > git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git) > 2) Edit linux-xfs/fs/xfs/libxfs/xfs_fs.h and add the same change there and to the files in fs/xfs that directly use XATTR_LIST_MAX. 2.5) compile, install kernel, run xfstests. > 3) Send it to this mailing list as usual, with "[PATCH] xfs: ..." > > (The same goes for the other patch with the kernel need too.) > > Is it all right? Correct repository URL? :-) Yup. Cheers, Dave. -- Dave Chinner david@fromorbit.com From david@fromorbit.com Thu Sep 24 17:53:45 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id A9DFF7F37 for ; Thu, 24 Sep 2015 17:53:45 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 98EA4304067 for ; Thu, 24 Sep 2015 15:53:42 -0700 (PDT) X-ASG-Debug-ID: 1443135219-04cbb033b0d6af0001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id HvWRWfXTXKapgmsr for ; Thu, 24 Sep 2015 15:53:39 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2A7CwCtfQRWPOV8LHldgySBPYMqgy+iPAEBAQEBAQaKeZEkAgIBAQKBRU0BAQEBAQEHAQEBAUE/hCUBAQQjDwEjIxAIAw4KAgIFIQICDwUlAwcaE4gtt3KUJQEBCAIBHxmBCYUKhD6BBoUNB4JpgUMFhzGGfIc6jQaBVIQ2lSWCdByBZiwziWwBAQE Received: from ppp121-44-124-229.lns20.syd4.internode.on.net (HELO dastard) ([121.44.124.229]) by ipmail05.adl6.internode.on.net with ESMTP; 25 Sep 2015 08:23:38 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ZfFOU-0006ln-9s; Fri, 25 Sep 2015 08:53:38 +1000 Date: Fri, 25 Sep 2015 08:53:38 +1000 From: Dave Chinner To: Jan Tulak Cc: xfs-oss Subject: Re: [PATCH 12/14] xfsprogs: make fsr use mntinfo when there is no mntent Message-ID: <20150924225338.GV19114@dastard> X-ASG-Orig-Subj: Re: [PATCH 12/14] xfsprogs: make fsr use mntinfo when there is no mntent References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> <1442311164-12921-13-git-send-email-jtulak@redhat.com> <20150923033655.GQ3902@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1443135219 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22873 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Thu, Sep 24, 2015 at 04:38:49PM +0200, Jan Tulak wrote: > On Wed, Sep 23, 2015 at 5:36 AM, Dave Chinner wrote: > > > On Tue, Sep 15, 2015 at 11:59:22AM +0200, Jan Tulak wrote: > > > @@ -202,6 +205,27 @@ find_mountpoint(char *mtab, char *argname, struct > > stat64 *sb) > > > } > > > > > > while ((t = getmntent(mtabp))) { > > > +#elif defined(HAVE_GETMNTINFO) > > > + struct statfs *stats; > > > + int error, i, count; > > > + // because "t" is a pointer, but we don't need to use > > > + // malloc for this usage > > > + struct mntent t_tmp; > > > + t = &t_tmp; > > > + > > > + > > > + error = 0; > > > + if ((count = getmntinfo(&stats, 0)) < 0) { > > > + fprintf(stderr, _("%s: getmntinfo() failed: %s\n"), > > > + progname, strerror(errno)); > > > + return 0; > > > + } > > > + > > > + for (i = 0; i < count; i++) { > > > + mntinfo2mntent(&stats[i], t); > > > +#else > > > +# error "How do I extract info about mounted filesystems on this > > platform?" > > > +#endif > > > > No, please don't do that. Having a loop iterator split across two > > separate defines is unmaintainable. Write two separate functions > > with the different loop iterators, then factor the common bit out > > of them into a single function. > > > > > I did a little refactoring to solve it. What I would like to ask ab​out is > this: > When I can put ifdef just inside of a function like fnc(void) { #ifdef... > #else ... #endif }, with little to no code outside of the ifdef, is it > better to put the ifdef outside, or keep it inside? The idea is that the "little differences" are put in functions that end up in include/.h or libxfs/.c, so there are no ifdefs in any of the application or library code. The build will automatically include the correct function on the given platform, and so the application code does not need such ifdefs at all. e.g. you could implement these functions to abstract the differences away from xfs_fsr and any other code that iterates the mount table: struct mntent_cursor { /* variables needed to track iteration of the mtab */ }; platform_first_mntent() platform_next_mntent() platform_end_mntent() and so the code would look like: struct mntent_cursor cursor; mntent = platform_first_mntent(&cursor) do { /* process mntent */ } while (mntent = platform_next_mntent(&cursor, mntent)); platform_end_mntent(&cursor); This completely abstracts the differences related to the the mount table traversal, and allows the aplication level code to be written in a clean, easily maintainable fashion... Cheers, Dave. -- Dave Chinner david@fromorbit.com From nscott@redhat.com Thu Sep 24 18:17:50 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6A45B7F37 for ; Thu, 24 Sep 2015 18:17:50 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 48BD18F8054 for ; Thu, 24 Sep 2015 16:17:50 -0700 (PDT) X-ASG-Debug-ID: 1443136664-04cb6c6b07c2670001-NocioJ Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id 20mNZd7XnnwwBJ7t (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Sep 2015 16:17:45 -0700 (PDT) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t8ONHiHP008867 for ; Thu, 24 Sep 2015 19:17:44 -0400 Date: Thu, 24 Sep 2015 19:17:44 -0400 (EDT) From: Nathan Scott Reply-To: Nathan Scott To: xfs@oss.sgi.com Message-ID: <1482498135.42591149.1443136664561.JavaMail.zimbra@redhat.com> In-Reply-To: <1054663595.42590503.1443136351475.JavaMail.zimbra@redhat.com> Subject: Remove use of __psint_t in xfsdump as well MIME-Version: 1.0 X-ASG-Orig-Subj: Remove use of __psint_t in xfsdump as well Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.64.48.80] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: Remove use of __psint_t in xfsdump as well Thread-Index: bBho1eZlnlTq74+rJi7XHl8YrRRj2g== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1443136665 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22874 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/nathans/xfsdump.git master Nathan Scott (1): xfsdump: remove use of __psint_t, it is no longer available common/drive_minrmt.c | 4 ++-- common/drive_scsitape.c | 4 ++-- common/drive_simple.c | 4 ++-- common/util.h | 4 ++-- debian/changelog | 6 ++++++ 5 files changed, 14 insertions(+), 8 deletions(-) commit 8a468340b2b0592daa553d722b4eff5997e18fc1 Author: Nathan Scott Date: Fri Sep 25 09:11:31 2015 +1000 xfsdump: remove use of __psint_t, it is no longer available Commit ee6cd73ed1e in xfsprogs switched __psint_t to the standards conforming intptr_t type - we need to make the same change here in xfsdump for builds using the latest xfsprogs headers. Signed-off-by: Nathan Scott From nscott@redhat.com Thu Sep 24 18:18:50 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id C001A7F37 for ; Thu, 24 Sep 2015 18:18:50 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id ADD44304043 for ; Thu, 24 Sep 2015 16:18:47 -0700 (PDT) X-ASG-Debug-ID: 1443136725-04cb6c6b05c2690001-NocioJ Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id UvgqwMe4G9ZVnBkm (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Sep 2015 16:18:46 -0700 (PDT) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t8ONIjfE008953 for ; Thu, 24 Sep 2015 19:18:45 -0400 Date: Thu, 24 Sep 2015 19:18:45 -0400 (EDT) From: Nathan Scott Reply-To: Nathan Scott To: xfs@oss.sgi.com Message-ID: <1112215787.42591167.1443136725773.JavaMail.zimbra@redhat.com> In-Reply-To: <1303550487.42590968.1443136538184.JavaMail.zimbra@redhat.com> Subject: Fix trivial libdm compile errors MIME-Version: 1.0 X-ASG-Orig-Subj: Fix trivial libdm compile errors Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.64.48.80] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: Fix trivial libdm compile errors Thread-Index: 8V5/o7HyF8SNmxHHFl1WmNyjvidptQ== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1443136726 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22874 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... (not released/tagged, I'll leave that for those who know the process; I'll await a proper release before updating Debian unstable - cheers) Changes committed to git://oss.sgi.com/nathans/dmapi.git master Mathieu Malaterre (1): dmapi: fix handle2path compilation by adding missing #include lines Nathan Scott (1): dmapi: bump version for releasing a small libdm compilation fix VERSION | 2 +- debian/changelog | 6 ++++++ doc/CHANGES | 4 ++++ libdm/dm_handle2path.c | 5 +++++ 4 files changed, 16 insertions(+), 1 deletion(-) commit e6ee9eaf62e85bbd502112f8e2e3a65a348b7309 Author: Nathan Scott Date: Fri Sep 25 08:31:55 2015 +1000 dmapi: bump version for releasing a small libdm compilation fix Signed-off-by: Nathan Scott commit 5c22e17d842b6b6e52e9432159a562beb372b35a Author: Mathieu Malaterre Date: Fri Sep 25 08:27:51 2015 +1000 dmapi: fix handle2path compilation by adding missing #include lines Reviewed-by: Nathan Scott Signed-off-by: Nathan Scott From skqld@fglw.com Thu Sep 24 22:53:42 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id AA6357F37 for ; Thu, 24 Sep 2015 22:53:42 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 275EEAC002 for ; Thu, 24 Sep 2015 20:53:38 -0700 (PDT) X-ASG-Debug-ID: 1443153214-04cb6c6b04c7d30001-NocioJ Received: from fglw.com (66.90.73.124.broad.dynamic.hf.ah.cndata.com [124.73.90.66]) by cuda.sgi.com with ESMTP id QiGiBLnuUXB6C2zj for ; Thu, 24 Sep 2015 20:53:36 -0700 (PDT) X-Barracuda-Envelope-From: skqld@fglw.com X-Barracuda-Apparent-Source-IP: 124.73.90.66 Received: from SKY-20150201SFT ([127.0.0.1]) by localhost via TCP with ESMTPA; Fri, 25 Sep 2015 11:53:23 +0800 MIME-Version: 1.0 From: Henry Sender: Henry To: xfs@oss.sgi.com Reply-To: Henry Date: 25 Sep 2015 11:53:23 +0800 Subject: =?utf-8?B?bWFudWZhY3R1cmluZyBtZWNoYW5pY2FsIHBhcnRz?= Content-Type: text/html; charset=utf-8 X-ASG-Orig-Subj: =?utf-8?B?bWFudWZhY3R1cmluZyBtZWNoYW5pY2FsIHBhcnRz?= Content-Transfer-Encoding: base64 X-Barracuda-Connect: 66.90.73.124.broad.dynamic.hf.ah.cndata.com[124.73.90.66] X-Barracuda-Start-Time: 1443153214 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.74 X-Barracuda-Spam-Status: No, SCORE=0.74 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC5_MJ1963, HTML_MESSAGE, MIME_HTML_ONLY, MISSING_MID, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22879 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 MISSING_MID Missing Message-Id: header 0.00 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 Message-Id: <20150925035338.A15391296086@cuda.sgi.com> PGh0bWw+PGJvZHk+PERJViBzdHlsZT0iVEVYVC1UUkFOU0ZPUk06IG5vbmU7IEJBQ0tHUk9V TkQtQ09MT1I6IHJnYigyNTUsMjU1LDI1NSk7IFRFWFQtSU5ERU5UOiAwcHg7IEZPTlQ6IDE0 cHgvMjFweCDlvq7ova/pm4Xpu5E7IFdISVRFLVNQQUNFOiBub3JtYWw7IExFVFRFUi1TUEFD SU5HOiBub3JtYWw7IENPTE9SOiByZ2IoMCwwLDApOyBXT1JELVNQQUNJTkc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4Ij5IZWxsbyw8L0RJVj4NCjxESVYgc3R5bGU9 IlRFWFQtVFJBTlNGT1JNOiBub25lOyBCQUNLR1JPVU5ELUNPTE9SOiByZ2IoMjU1LDI1NSwy NTUpOyBURVhULUlOREVOVDogMHB4OyBGT05UOiAxNHB4LzIxcHgg5b6u6L2v6ZuF6buROyBX SElURS1TUEFDRTogbm9ybWFsOyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjogcmdi KDAsMCwwKTsgV09SRC1TUEFDSU5HOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweCI+PC9ESVY+DQo8RElWIHN0eWxlPSJURVhULVRSQU5TRk9STTogbm9uZTsgQkFDS0dS T1VORC1DT0xPUjogcmdiKDI1NSwyNTUsMjU1KTsgVEVYVC1JTkRFTlQ6IDBweDsgRk9OVDog MTRweC8yMXB4IOW+rui9r+mbhem7kTsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgTEVUVEVSLVNQ QUNJTkc6IG5vcm1hbDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQtU1BBQ0lORzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHgiPldlIHNwZWNpYWxpemUgaW4gdmFyaW91 cyBoaWdoIHByZWNpc2UgbWVjaGFuaWNhbCBwYXJ0cyxsaWtlIG1hY2hpbmluZzwvRElWPg0K PERJViBzdHlsZT0iVEVYVC1UUkFOU0ZPUk06IG5vbmU7IEJBQ0tHUk9VTkQtQ09MT1I6IHJn YigyNTUsMjU1LDI1NSk7IFRFWFQtSU5ERU5UOiAwcHg7IEZPTlQ6IDE0cHgvMjFweCDlvq7o va/pm4Xpu5E7IFdISVRFLVNQQUNFOiBub3JtYWw7IExFVFRFUi1TUEFDSU5HOiBub3JtYWw7 IENPTE9SOiByZ2IoMCwwLDApOyBXT1JELVNQQUNJTkc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4Ij5wYXJ0cyxzdGFtcGluZyBwYXJ0cyBhbmQgc28gb24uPC9ESVY+ DQo8RElWIHN0eWxlPSJURVhULVRSQU5TRk9STTogbm9uZTsgQkFDS0dST1VORC1DT0xPUjog cmdiKDI1NSwyNTUsMjU1KTsgVEVYVC1JTkRFTlQ6IDBweDsgRk9OVDogMTRweC8yMXB4IOW+ rui9r+mbhem7kTsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgTEVUVEVSLVNQQUNJTkc6IG5vcm1h bDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQtU1BBQ0lORzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHgiPiZuYnNwOzwvRElWPg0KPERJViBzdHlsZT0iVEVYVC1UUkFO U0ZPUk06IG5vbmU7IEJBQ0tHUk9VTkQtQ09MT1I6IHJnYigyNTUsMjU1LDI1NSk7IFRFWFQt SU5ERU5UOiAwcHg7IEZPTlQ6IDE0cHgvMjFweCDlvq7ova/pm4Xpu5E7IFdISVRFLVNQQUNF OiBub3JtYWw7IExFVFRFUi1TUEFDSU5HOiBub3JtYWw7IENPTE9SOiByZ2IoMCwwLDApOyBX T1JELVNQQUNJTkc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4Ij5XZSBj b3VsZCBxdW90ZSBiYXNlZCBvbiBkcmF3aW5ncyBvciBzYW1wbGVzLjwvRElWPg0KPERJViBz dHlsZT0iVEVYVC1UUkFOU0ZPUk06IG5vbmU7IEJBQ0tHUk9VTkQtQ09MT1I6IHJnYigyNTUs MjU1LDI1NSk7IFRFWFQtSU5ERU5UOiAwcHg7IEZPTlQ6IDE0cHgvMjFweCDlvq7ova/pm4Xp u5E7IFdISVRFLVNQQUNFOiBub3JtYWw7IExFVFRFUi1TUEFDSU5HOiBub3JtYWw7IENPTE9S OiByZ2IoMCwwLDApOyBXT1JELVNQQUNJTkc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4Ij4mbmJzcDs8L0RJVj4NCjxESVYgc3R5bGU9IlRFWFQtVFJBTlNGT1JNOiBu b25lOyBCQUNLR1JPVU5ELUNPTE9SOiByZ2IoMjU1LDI1NSwyNTUpOyBURVhULUlOREVOVDog MHB4OyBGT05UOiAxNHB4LzIxcHgg5b6u6L2v6ZuF6buROyBXSElURS1TUEFDRTogbm9ybWFs OyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsgV09SRC1TUEFD SU5HOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCI+SWYgeW91IG5lZWQg b3VyIHNlcnZpY2VzLCBwbGVhc2UgZmVlbCBmcmVlIHRvIGNvbnRhY3QgbWUuPC9ESVY+DQo8 RElWIHN0eWxlPSJURVhULVRSQU5TRk9STTogbm9uZTsgQkFDS0dST1VORC1DT0xPUjogcmdi KDI1NSwyNTUsMjU1KTsgVEVYVC1JTkRFTlQ6IDBweDsgRk9OVDogMTRweC8yMXB4IOW+rui9 r+mbhem7kTsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgTEVUVEVSLVNQQUNJTkc6IG5vcm1hbDsg Q09MT1I6IHJnYigwLDAsMCk7IFdPUkQtU1BBQ0lORzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHgiPjwvRElWPg0KPERJViBzdHlsZT0iVEVYVC1UUkFOU0ZPUk06IG5v bmU7IEJBQ0tHUk9VTkQtQ09MT1I6IHJnYigyNTUsMjU1LDI1NSk7IFRFWFQtSU5ERU5UOiAw cHg7IEZPTlQ6IDE0cHgvMjFweCDlvq7ova/pm4Xpu5E7IFdISVRFLVNQQUNFOiBub3JtYWw7 IExFVFRFUi1TUEFDSU5HOiBub3JtYWw7IENPTE9SOiByZ2IoMCwwLDApOyBXT1JELVNQQUNJ Tkc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4Ij5UaGFua3MgJmFtcDsg QmVzdCByZWdhcmRzLDwvRElWPg0KPERJViBzdHlsZT0iVEVYVC1UUkFOU0ZPUk06IG5vbmU7 IEJBQ0tHUk9VTkQtQ09MT1I6IHJnYigyNTUsMjU1LDI1NSk7IFRFWFQtSU5ERU5UOiAwcHg7 IEZPTlQ6IDE0cHgvMjFweCDlvq7ova/pm4Xpu5E7IFdISVRFLVNQQUNFOiBub3JtYWw7IExF VFRFUi1TUEFDSU5HOiBub3JtYWw7IENPTE9SOiByZ2IoMCwwLDApOyBXT1JELVNQQUNJTkc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4Ij5IZW5yeTwvRElWPg0KPERJ ViBzdHlsZT0iVEVYVC1UUkFOU0ZPUk06IG5vbmU7IEJBQ0tHUk9VTkQtQ09MT1I6IHJnYigy NTUsMjU1LDI1NSk7IFRFWFQtSU5ERU5UOiAwcHg7IEZPTlQ6IDE0cHgvMjFweCDlvq7ova/p m4Xpu5E7IFdISVRFLVNQQUNFOiBub3JtYWw7IExFVFRFUi1TUEFDSU5HOiBub3JtYWw7IENP TE9SOiByZ2IoMCwwLDApOyBXT1JELVNQQUNJTkc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4Ij48L0RJVj4NCjxESVYgc3R5bGU9IlRFWFQtVFJBTlNGT1JNOiBub25l OyBCQUNLR1JPVU5ELUNPTE9SOiByZ2IoMjU1LDI1NSwyNTUpOyBURVhULUlOREVOVDogMHB4 OyBGT05UOiAxNHB4LzIxcHgg5b6u6L2v6ZuF6buROyBXSElURS1TUEFDRTogbm9ybWFsOyBM RVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsgV09SRC1TUEFDSU5H OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCI+Tm8uQiBSb29tIDYwNCBD ZW50dXJ5IFdpbm5lciBCdWlsZGluZyxObyA2IE5pYW5qaXUgTGFuZSBIYWlzaHU8L0RJVj4N CjxESVYgc3R5bGU9IlRFWFQtVFJBTlNGT1JNOiBub25lOyBCQUNLR1JPVU5ELUNPTE9SOiBy Z2IoMjU1LDI1NSwyNTUpOyBURVhULUlOREVOVDogMHB4OyBGT05UOiAxNHB4LzIxcHgg5b6u 6L2v6ZuF6buROyBXSElURS1TUEFDRTogbm9ybWFsOyBMRVRURVItU1BBQ0lORzogbm9ybWFs OyBDT0xPUjogcmdiKDAsMCwwKTsgV09SRC1TUEFDSU5HOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweCI+VGVsOiA4NiA1NzQgNTUyMjQ5ODg8L0RJVj4NCjxESVYgc3R5 bGU9IlRFWFQtVFJBTlNGT1JNOiBub25lOyBCQUNLR1JPVU5ELUNPTE9SOiByZ2IoMjU1LDI1 NSwyNTUpOyBURVhULUlOREVOVDogMHB4OyBGT05UOiAxNHB4LzIxcHgg5b6u6L2v6ZuF6buR OyBXSElURS1TUEFDRTogbm9ybWFsOyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjog cmdiKDAsMCwwKTsgV09SRC1TUEFDSU5HOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweCI+RmF4OiA4NiA1NzQgODcxNjkwNzY8L0RJVj4NCjxESVYgc3R5bGU9IlRFWFQt VFJBTlNGT1JNOiBub25lOyBCQUNLR1JPVU5ELUNPTE9SOiByZ2IoMjU1LDI1NSwyNTUpOyBU RVhULUlOREVOVDogMHB4OyBGT05UOiAxNHB4LzIxcHgg5b6u6L2v6ZuF6buROyBXSElURS1T UEFDRTogbm9ybWFsOyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCww KTsgV09SRC1TUEFDSU5HOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCI+ Jm5ic3A7PC9ESVY+PC9ib2R5PjwvaHRtbD4= From bfoster@redhat.com Fri Sep 25 07:24:36 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id DE1647F37 for ; Fri, 25 Sep 2015 07:24:36 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 824448F8064 for ; Fri, 25 Sep 2015 05:24:33 -0700 (PDT) X-ASG-Debug-ID: 1443183870-04bdf04627dc830001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id tF1p02S9wjBCSS2e (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 05:24:31 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 8762319F21C for ; Fri, 25 Sep 2015 12:24:30 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PCOUPm019980 for ; Fri, 25 Sep 2015 08:24:30 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 1E7411202D2; Fri, 25 Sep 2015 08:24:29 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH] xfs: validate metadata LSNs against log on v5 superblocks Date: Fri, 25 Sep 2015 08:24:29 -0400 X-ASG-Orig-Subj: [PATCH] xfs: validate metadata LSNs against log on v5 superblocks Message-Id: <1443183869-16487-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443183871 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at sgi.com Since the onset of v5 superblocks, the LSN of the last modification has been included in a variety of on-disk data structures. This LSN is used to provide log recovery ordering guarantees (e.g., to ensure an older log recovery item is not replayed over a newer target data structure). While this works correctly from the point a filesystem is formatted and mounted, userspace tools have some problematic behaviors that defeat this mechanism. For example, xfs_repair historically zeroes out the log unconditionally (regardless of whether corruption is detected). If this occurs, the LSN of the filesystem is reset and the log is now in a problematic state with respect to on-disk metadata structures that might have a larger LSN. Until either the log catches up to the highest previously used metadata LSN or each affected data structure is modified and written out without incident (which resets the metadata LSN), log recovery is susceptible to filesystem corruption. This problem is ultimately addressed and repaired in the associated userspace tools. The kernel is still responsible to detect the problem and notify the user that something is wrong. Check the superblock LSN at mount time and fail the mount if it is invalid. From that point on, trigger verifier failure on any metadata I/O where an invalid LSN is detected. This results in a filesystem shutdown and guarantees that we do not log metadata changes with invalid LSNs on disk. Since this is a known issue with a known recovery path, present a warning to instruct the user how to recover. Signed-off-by: Brian Foster --- Here's a first non-rfc version of v5 sb metadata LSN verification. The biggest difference with this version is the attempt to mitigate lock contention in the LSN helper and corresponding tweak to how the log fields are updated when the head wraps around the end of the log. The idea is to do a racy check and only acquire the lock when there appears to be risk of an invalid LSN. AFAICS, this is not safe with the current code as the current LSN can be sampled in a state that transiently pushes the LSN forward to the end of the next cycle (if the cycle is updated, both cycle/block are sampled, and then the block is updated). This means that a false negative can occur if an invalid LSN happens to exist but is within the bounds of the next full log cycle. Therefore, this patch also tweaks the current LSN update and sample code to rewind the current block before the cycle is updated and uses a memory barrier to guarantee that the sample code always sees the rewound current block if it sees the updated cycle. Note that it is still possible to see the rewound block before the cycle update (a transient backwards LSN), but this is safe because such false positives are explicitly reverified with the lock held before failure is triggered. Otherwise, this refactors/relocates the helpers and converts back to the more simple behavior of verifier failure on detection of invalid metadata LSN. Thoughts, reviews, flames appreciated. Brian v1: - Converted back to verifier failure (fs shutdown) behavior. - Relocated and renamed support functions. - Perform racy LSN check before locked check to minimize lock contention. - Updated log cycle wrap code to support racy check. - Handle NULLCOMMITLSN metadata LSN in verifiers. rfcv2: http://oss.sgi.com/pipermail/xfs/2015-September/043627.html - Refactored lsn validation and warning code into separate helpers. - Updated warning mechanism to warn at least once per fs (ratelimited thereafter). - No longer shutdown the fs on invalid metadata lsn detection. rfcv1: http://oss.sgi.com/pipermail/xfs/2015-August/043396.html fs/xfs/libxfs/xfs_alloc.c | 12 ++++++--- fs/xfs/libxfs/xfs_attr_leaf.c | 3 +++ fs/xfs/libxfs/xfs_btree.c | 17 ++++++++++-- fs/xfs/libxfs/xfs_da_btree.c | 4 +++ fs/xfs/libxfs/xfs_dir2_block.c | 3 +++ fs/xfs/libxfs/xfs_dir2_data.c | 3 +++ fs/xfs/libxfs/xfs_dir2_leaf.c | 3 +++ fs/xfs/libxfs/xfs_dir2_node.c | 3 +++ fs/xfs/libxfs/xfs_ialloc.c | 10 +++++-- fs/xfs/libxfs/xfs_sb.c | 10 +++++++ fs/xfs/libxfs/xfs_symlink_remote.c | 4 +++ fs/xfs/xfs_log.c | 54 ++++++++++++++++++++++++++++++++++++-- fs/xfs/xfs_log.h | 1 + fs/xfs/xfs_log_priv.h | 51 +++++++++++++++++++++++++++++++++++ fs/xfs/xfs_log_recover.c | 12 ++++++++- 15 files changed, 180 insertions(+), 10 deletions(-) diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c index ffad7f2..d39e6d8 100644 --- a/fs/xfs/libxfs/xfs_alloc.c +++ b/fs/xfs/libxfs/xfs_alloc.c @@ -482,7 +482,9 @@ xfs_agfl_verify( be32_to_cpu(agfl->agfl_bno[i]) >= mp->m_sb.sb_agblocks) return false; } - return true; + + return xfs_log_check_lsn(mp, + be64_to_cpu(XFS_BUF_TO_AGFL(bp)->agfl_lsn)); } static void @@ -2259,9 +2261,13 @@ xfs_agf_verify( { struct xfs_agf *agf = XFS_BUF_TO_AGF(bp); - if (xfs_sb_version_hascrc(&mp->m_sb) && - !uuid_equal(&agf->agf_uuid, &mp->m_sb.sb_meta_uuid)) + if (xfs_sb_version_hascrc(&mp->m_sb)) { + if (!uuid_equal(&agf->agf_uuid, &mp->m_sb.sb_meta_uuid)) return false; + if (!xfs_log_check_lsn(mp, + be64_to_cpu(XFS_BUF_TO_AGF(bp)->agf_lsn))) + return false; + } if (!(agf->agf_magicnum == cpu_to_be32(XFS_AGF_MAGIC) && XFS_AGF_GOOD_VERSION(be32_to_cpu(agf->agf_versionnum)) && diff --git a/fs/xfs/libxfs/xfs_attr_leaf.c b/fs/xfs/libxfs/xfs_attr_leaf.c index 33df52d..aa187f7 100644 --- a/fs/xfs/libxfs/xfs_attr_leaf.c +++ b/fs/xfs/libxfs/xfs_attr_leaf.c @@ -41,6 +41,7 @@ #include "xfs_buf_item.h" #include "xfs_cksum.h" #include "xfs_dir2.h" +#include "xfs_log.h" /* @@ -266,6 +267,8 @@ xfs_attr3_leaf_verify( return false; if (be64_to_cpu(hdr3->info.blkno) != bp->b_bn) return false; + if (!xfs_log_check_lsn(mp, be64_to_cpu(hdr3->info.lsn))) + return false; } else { if (ichdr.magic != XFS_ATTR_LEAF_MAGIC) return false; diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c index f7d7ee7..b16a8ba 100644 --- a/fs/xfs/libxfs/xfs_btree.c +++ b/fs/xfs/libxfs/xfs_btree.c @@ -32,6 +32,7 @@ #include "xfs_trace.h" #include "xfs_cksum.h" #include "xfs_alloc.h" +#include "xfs_log.h" /* * Cursor allocation zone. @@ -243,8 +244,14 @@ bool xfs_btree_lblock_verify_crc( struct xfs_buf *bp) { - if (xfs_sb_version_hascrc(&bp->b_target->bt_mount->m_sb)) + struct xfs_btree_block *block = XFS_BUF_TO_BLOCK(bp); + struct xfs_mount *mp = bp->b_target->bt_mount; + + if (xfs_sb_version_hascrc(&bp->b_target->bt_mount->m_sb)) { + if (!xfs_log_check_lsn(mp, be64_to_cpu(block->bb_u.l.bb_lsn))) + return false; return xfs_buf_verify_cksum(bp, XFS_BTREE_LBLOCK_CRC_OFF); + } return true; } @@ -275,8 +282,14 @@ bool xfs_btree_sblock_verify_crc( struct xfs_buf *bp) { - if (xfs_sb_version_hascrc(&bp->b_target->bt_mount->m_sb)) + struct xfs_btree_block *block = XFS_BUF_TO_BLOCK(bp); + struct xfs_mount *mp = bp->b_target->bt_mount; + + if (xfs_sb_version_hascrc(&bp->b_target->bt_mount->m_sb)) { + if (!xfs_log_check_lsn(mp, be64_to_cpu(block->bb_u.s.bb_lsn))) + return false; return xfs_buf_verify_cksum(bp, XFS_BTREE_SBLOCK_CRC_OFF); + } return true; } diff --git a/fs/xfs/libxfs/xfs_da_btree.c b/fs/xfs/libxfs/xfs_da_btree.c index be43248..e89a0f8 100644 --- a/fs/xfs/libxfs/xfs_da_btree.c +++ b/fs/xfs/libxfs/xfs_da_btree.c @@ -39,6 +39,7 @@ #include "xfs_trace.h" #include "xfs_cksum.h" #include "xfs_buf_item.h" +#include "xfs_log.h" /* * xfs_da_btree.c @@ -150,6 +151,8 @@ xfs_da3_node_verify( return false; if (be64_to_cpu(hdr3->info.blkno) != bp->b_bn) return false; + if (!xfs_log_check_lsn(mp, be64_to_cpu(hdr3->info.lsn))) + return false; } else { if (ichdr.magic != XFS_DA_NODE_MAGIC) return false; @@ -322,6 +325,7 @@ xfs_da3_node_create( if (xfs_sb_version_hascrc(&mp->m_sb)) { struct xfs_da3_node_hdr *hdr3 = bp->b_addr; + memset(hdr3, 0, sizeof(struct xfs_da3_node_hdr)); ichdr.magic = XFS_DA3_NODE_MAGIC; hdr3->info.blkno = cpu_to_be64(bp->b_bn); hdr3->info.owner = cpu_to_be64(args->dp->i_ino); diff --git a/fs/xfs/libxfs/xfs_dir2_block.c b/fs/xfs/libxfs/xfs_dir2_block.c index 4778d1d..9c10e2b 100644 --- a/fs/xfs/libxfs/xfs_dir2_block.c +++ b/fs/xfs/libxfs/xfs_dir2_block.c @@ -34,6 +34,7 @@ #include "xfs_error.h" #include "xfs_trace.h" #include "xfs_cksum.h" +#include "xfs_log.h" /* * Local function prototypes. @@ -71,6 +72,8 @@ xfs_dir3_block_verify( return false; if (be64_to_cpu(hdr3->blkno) != bp->b_bn) return false; + if (!xfs_log_check_lsn(mp, be64_to_cpu(hdr3->lsn))) + return false; } else { if (hdr3->magic != cpu_to_be32(XFS_DIR2_BLOCK_MAGIC)) return false; diff --git a/fs/xfs/libxfs/xfs_dir2_data.c b/fs/xfs/libxfs/xfs_dir2_data.c index 824131e..af71a84 100644 --- a/fs/xfs/libxfs/xfs_dir2_data.c +++ b/fs/xfs/libxfs/xfs_dir2_data.c @@ -31,6 +31,7 @@ #include "xfs_trans.h" #include "xfs_buf_item.h" #include "xfs_cksum.h" +#include "xfs_log.h" /* * Check the consistency of the data block. @@ -224,6 +225,8 @@ xfs_dir3_data_verify( return false; if (be64_to_cpu(hdr3->blkno) != bp->b_bn) return false; + if (!xfs_log_check_lsn(mp, be64_to_cpu(hdr3->lsn))) + return false; } else { if (hdr3->magic != cpu_to_be32(XFS_DIR2_DATA_MAGIC)) return false; diff --git a/fs/xfs/libxfs/xfs_dir2_leaf.c b/fs/xfs/libxfs/xfs_dir2_leaf.c index f300240..3923e1f 100644 --- a/fs/xfs/libxfs/xfs_dir2_leaf.c +++ b/fs/xfs/libxfs/xfs_dir2_leaf.c @@ -33,6 +33,7 @@ #include "xfs_trans.h" #include "xfs_buf_item.h" #include "xfs_cksum.h" +#include "xfs_log.h" /* * Local function declarations. @@ -164,6 +165,8 @@ xfs_dir3_leaf_verify( return false; if (be64_to_cpu(leaf3->info.blkno) != bp->b_bn) return false; + if (!xfs_log_check_lsn(mp, be64_to_cpu(leaf3->info.lsn))) + return false; } else { if (leaf->hdr.info.magic != cpu_to_be16(magic)) return false; diff --git a/fs/xfs/libxfs/xfs_dir2_node.c b/fs/xfs/libxfs/xfs_dir2_node.c index cc28e92..70b0cb2 100644 --- a/fs/xfs/libxfs/xfs_dir2_node.c +++ b/fs/xfs/libxfs/xfs_dir2_node.c @@ -33,6 +33,7 @@ #include "xfs_trans.h" #include "xfs_buf_item.h" #include "xfs_cksum.h" +#include "xfs_log.h" /* * Function declarations. @@ -97,6 +98,8 @@ xfs_dir3_free_verify( return false; if (be64_to_cpu(hdr3->blkno) != bp->b_bn) return false; + if (!xfs_log_check_lsn(mp, be64_to_cpu(hdr3->lsn))) + return false; } else { if (hdr->magic != cpu_to_be32(XFS_DIR2_FREE_MAGIC)) return false; diff --git a/fs/xfs/libxfs/xfs_ialloc.c b/fs/xfs/libxfs/xfs_ialloc.c index 54deb2d..70c1db9 100644 --- a/fs/xfs/libxfs/xfs_ialloc.c +++ b/fs/xfs/libxfs/xfs_ialloc.c @@ -38,6 +38,7 @@ #include "xfs_icreate_item.h" #include "xfs_icache.h" #include "xfs_trace.h" +#include "xfs_log.h" /* @@ -2500,9 +2501,14 @@ xfs_agi_verify( struct xfs_mount *mp = bp->b_target->bt_mount; struct xfs_agi *agi = XFS_BUF_TO_AGI(bp); - if (xfs_sb_version_hascrc(&mp->m_sb) && - !uuid_equal(&agi->agi_uuid, &mp->m_sb.sb_meta_uuid)) + if (xfs_sb_version_hascrc(&mp->m_sb)) { + if (!uuid_equal(&agi->agi_uuid, &mp->m_sb.sb_meta_uuid)) + return false; + if (!xfs_log_check_lsn(mp, + be64_to_cpu(XFS_BUF_TO_AGI(bp)->agi_lsn))) return false; + } + /* * Validate the magic number of the agi block. */ diff --git a/fs/xfs/libxfs/xfs_sb.c b/fs/xfs/libxfs/xfs_sb.c index 4742514..a0b071d 100644 --- a/fs/xfs/libxfs/xfs_sb.c +++ b/fs/xfs/libxfs/xfs_sb.c @@ -35,6 +35,7 @@ #include "xfs_bmap_btree.h" #include "xfs_alloc_btree.h" #include "xfs_ialloc_btree.h" +#include "xfs_log.h" /* * Physical superblock buffer manipulations. Shared with libxfs in userspace. @@ -163,6 +164,15 @@ xfs_mount_validate_sb( "Filesystem can not be safely mounted by this kernel."); return -EINVAL; } + } else if (xfs_sb_version_hascrc(sbp)) { + /* + * We can't read verify the sb LSN because the read verifier is + * called before the log is allocated and processed. We know the + * log is set up before write verifier (!check_version) calls, + * so just check it here. + */ + if (!xfs_log_check_lsn(mp, sbp->sb_lsn)) + return -EFSCORRUPTED; } if (xfs_sb_version_has_pquotino(sbp)) { diff --git a/fs/xfs/libxfs/xfs_symlink_remote.c b/fs/xfs/libxfs/xfs_symlink_remote.c index 8f8af05..60eed7a 100644 --- a/fs/xfs/libxfs/xfs_symlink_remote.c +++ b/fs/xfs/libxfs/xfs_symlink_remote.c @@ -31,6 +31,7 @@ #include "xfs_cksum.h" #include "xfs_trans.h" #include "xfs_buf_item.h" +#include "xfs_log.h" /* @@ -60,6 +61,7 @@ xfs_symlink_hdr_set( if (!xfs_sb_version_hascrc(&mp->m_sb)) return 0; + memset(dsl, 0, sizeof(struct xfs_dsymlink_hdr)); dsl->sl_magic = cpu_to_be32(XFS_SYMLINK_MAGIC); dsl->sl_offset = cpu_to_be32(offset); dsl->sl_bytes = cpu_to_be32(size); @@ -116,6 +118,8 @@ xfs_symlink_verify( return false; if (dsl->sl_owner == 0) return false; + if (!xfs_log_check_lsn(mp, be64_to_cpu(dsl->sl_lsn))) + return false; return true; } diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index aaadee0..0c8ef76 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -3165,11 +3165,19 @@ xlog_state_switch_iclogs( } if (log->l_curr_block >= log->l_logBBsize) { + /* + * Rewind the current block before the cycle is bumped to make + * sure that the combined LSN never transiently moves forward + * when the log wraps to the next cycle. This is to support the + * unlocked sample of these fields from xlog_valid_lsn(). Most + * other cases should acquire l_icloglock. + */ + log->l_curr_block -= log->l_logBBsize; + ASSERT(log->l_curr_block >= 0); + smp_wmb(); log->l_curr_cycle++; if (log->l_curr_cycle == XLOG_HEADER_MAGIC_NUM) log->l_curr_cycle++; - log->l_curr_block -= log->l_logBBsize; - ASSERT(log->l_curr_block >= 0); } ASSERT(iclog == log->l_iclog); log->l_iclog = iclog->ic_next; @@ -4023,3 +4031,45 @@ xlog_iclogs_empty( return 1; } +/* + * Verify that an LSN stamped into a piece of metadata is valid. This is + * intended for use in read verifiers on v5 superblocks. + */ +bool +xfs_log_check_lsn( + struct xfs_mount *mp, + xfs_lsn_t lsn) +{ + struct xlog *log = mp->m_log; + bool valid; + + /* + * norecovery mode skips mount-time log processing and unconditionally + * resets the in-core LSN. We can't validate in this mode, but + * modifications are not allowed anyways so just return true. + */ + if (mp->m_flags & XFS_MOUNT_NORECOVERY) + return true; + + /* + * Some metadata LSNs are initialized to NULL (e.g., the agfl). This is + * handled by recovery and thus safe to ignore here. + */ + if (lsn == NULLCOMMITLSN) + return true; + + valid = xlog_valid_lsn(mp->m_log, lsn); + + /* warn the user about what's gone wrong before verifier failure */ + if (!valid) { + spin_lock(&log->l_icloglock); + xfs_warn(mp, +"Corruption warning: Metadata has LSN (%d:%d) ahead of current LSN (%d:%d). " +"Please unmount and run xfs_repair (>= v4.3) to resolve.", + CYCLE_LSN(lsn), BLOCK_LSN(lsn), + log->l_curr_cycle, log->l_curr_block); + spin_unlock(&log->l_icloglock); + } + + return valid; +} diff --git a/fs/xfs/xfs_log.h b/fs/xfs/xfs_log.h index 09d91d3..aa533a7 100644 --- a/fs/xfs/xfs_log.h +++ b/fs/xfs/xfs_log.h @@ -181,5 +181,6 @@ bool xfs_log_item_in_current_chkpt(struct xfs_log_item *lip); void xfs_log_work_queue(struct xfs_mount *mp); void xfs_log_worker(struct work_struct *work); void xfs_log_quiesce(struct xfs_mount *mp); +bool xfs_log_check_lsn(struct xfs_mount *, xfs_lsn_t); #endif /* __XFS_LOG_H__ */ diff --git a/fs/xfs/xfs_log_priv.h b/fs/xfs/xfs_log_priv.h index 950f3f9..8daba74 100644 --- a/fs/xfs/xfs_log_priv.h +++ b/fs/xfs/xfs_log_priv.h @@ -560,4 +560,55 @@ static inline void xlog_wait(wait_queue_head_t *wq, spinlock_t *lock) remove_wait_queue(wq, &wait); } +/* + * The LSN is valid so long as it is behind the current LSN. If it isn't, this + * means that the next log record that includes this metadata could have a + * smaller LSN. In turn, this means that the modification in the log would not + * replay. + */ +static inline bool +xlog_valid_lsn( + struct xlog *log, + xfs_lsn_t lsn) +{ + int cur_cycle; + int cur_block; + bool valid = true; + + /* + * First, sample the current lsn without locking to avoid added + * contention from metadata I/O. The current cycle and block are updated + * (in xlog_state_switch_iclogs()) and read here in a particular order + * to avoid false negatives (e.g., thinking the metadata LSN is valid + * when it is not). + * + * The current block is always rewound before the cycle is bumped in + * xlog_state_switch_iclogs() to ensure the current LSN is never seen in + * a transiently forward state. Instead, we can see the LSN in a + * transiently behind state if we happen to race with a cycle wrap. + */ + cur_cycle = ACCESS_ONCE(log->l_curr_cycle); + smp_rmb(); + cur_block = ACCESS_ONCE(log->l_curr_block); + + if ((CYCLE_LSN(lsn) > cur_cycle) || + (CYCLE_LSN(lsn) == cur_cycle && BLOCK_LSN(lsn) > cur_block)) { + /* + * If the metadata LSN appears invalid, it's possible the check + * above raced with a wrap to the next log cycle. Grab the lock + * to check for sure. + */ + spin_lock(&log->l_icloglock); + cur_cycle = log->l_curr_cycle; + cur_block = log->l_curr_block; + spin_unlock(&log->l_icloglock); + + if ((CYCLE_LSN(lsn) > cur_cycle) || + (CYCLE_LSN(lsn) == cur_cycle && BLOCK_LSN(lsn) > cur_block)) + valid = false; + } + + return valid; +} + #endif /* __XFS_LOG_PRIV_H__ */ diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c index 512a094..f8f1363 100644 --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -4609,9 +4609,19 @@ xlog_recover( int error; /* find the tail of the log */ - if ((error = xlog_find_tail(log, &head_blk, &tail_blk))) + error = xlog_find_tail(log, &head_blk, &tail_blk); + if (error) return error; + /* + * The superblock was read before the log was available and thus the LSN + * could not be verified. Check the superblock LSN against the current + * LSN now that it's known. + */ + if (xfs_sb_version_hascrc(&log->l_mp->m_sb) && + !xfs_log_check_lsn(log->l_mp, log->l_mp->m_sb.sb_lsn)) + return -EINVAL; + if (tail_blk != head_blk) { /* There used to be a comment here: * -- 2.1.0 From cmaiolino@redhat.com Fri Sep 25 08:07:57 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E2FC07F37 for ; Fri, 25 Sep 2015 08:07:57 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 7D983AC004 for ; Fri, 25 Sep 2015 06:07:54 -0700 (PDT) X-ASG-Debug-ID: 1443186472-04cb6c6b05d9fb0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id chD7tUEL6WgCCuEr (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 06:07:53 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id BF799C0B1B3C for ; Fri, 25 Sep 2015 13:07:52 +0000 (UTC) Received: from zion.usersys.redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PD7paZ000474 for ; Fri, 25 Sep 2015 09:07:52 -0400 From: Carlos Maiolino To: xfs@oss.sgi.com Subject: [PATCH 0/3 V2] xfs_io: implement 'inode' command Date: Fri, 25 Sep 2015 15:07:44 +0200 X-ASG-Orig-Subj: [PATCH 0/3 V2] xfs_io: implement 'inode' command Message-Id: <1443186467-20110-1-git-send-email-cmaiolino@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443186473 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Implements a new xfs_io cmmand, named 'inode', which is supposed to be used to query information about inode's existence and its physical size in the filesystem. Currently supporting three arguments: -s -- return physical size of the largest inode -l -- return the largest inode number allocated and used -n [num] -- Return the next existing inode after [num], even if [num] is not allocated/used [num] -- Return if the inode exists or not. I decided to split the implementation in three patches because I thought this would be easier for review and understand the logic of each argument, mainly regarding the '-n [num] / [num]' implementation where I'm not sure if I handled it in a good way. I also didn't send the man page patch because I'm sure I'll get some points to improve, and I'll write the manpage for the next revision. Carlos Maiolino (3): xfs_io: Add inode '-s' command to query physical size of largest inode xfs_io: add inode -l argument to return largest inode number xfs_io: implement inode '-n' and [num] argument io/open.c | 153 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+) -- 2.4.3 From cmaiolino@redhat.com Fri Sep 25 08:08:00 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id DE3E47F50 for ; Fri, 25 Sep 2015 08:08:00 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 82662AC004 for ; Fri, 25 Sep 2015 06:08:00 -0700 (PDT) X-ASG-Debug-ID: 1443186478-04bdf04626dd9a0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id rEPpD1gmxjIjGbjh (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 06:07:58 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id ACD3C2589E for ; Fri, 25 Sep 2015 13:07:58 +0000 (UTC) Received: from zion.usersys.redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PD7pab000474 for ; Fri, 25 Sep 2015 09:07:58 -0400 From: Carlos Maiolino To: xfs@oss.sgi.com Subject: [PATCH 2/3] xfs_io: add inode -l argument to return largest inode number Date: Fri, 25 Sep 2015 15:07:46 +0200 X-ASG-Orig-Subj: [PATCH 2/3] xfs_io: add inode -l argument to return largest inode number Message-Id: <1443186467-20110-3-git-send-email-cmaiolino@redhat.com> In-Reply-To: <1443186467-20110-1-git-send-email-cmaiolino@redhat.com> References: <1443186467-20110-1-git-send-email-cmaiolino@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443186478 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Implements '-l' argument in inode command, returning to the user, the largest inode allocated and used in the filesystem. Signed-off-by: Carlos Maiolino --- io/open.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/io/open.c b/io/open.c index 6a794ba..57ff0bf 100644 --- a/io/open.c +++ b/io/open.c @@ -759,6 +759,7 @@ inode_help(void) "\n" "Query physical information about the inode" "\n" +" -l -- Returns the largest inode number in the filesystem\n" " -s -- Returns the physical size (in bits) of the\n" " largest inode number in the filesystem\n" "\n")); @@ -777,23 +778,27 @@ inode_f( struct xfs_fsop_bulkreq bulkreq; int c; int ret_lsize = 0; + int ret_largest = 0; bulkreq.lastip = &last; bulkreq.icount = 1024; /* maybe an user-defined value!? */ bulkreq.ubuffer = &igroup; bulkreq.ocount = &count; - while ((c = getopt(argc, argv, "s")) != EOF) { + while ((c = getopt(argc, argv, "sl")) != EOF) { switch (c) { case 's': ret_lsize = 1; break; + case 'l': + ret_largest = 1; + break; default: return command_usage(&inode_cmd); } } - if (ret_lsize) { + if (ret_lsize || ret_largest) { for (;;) { if (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { @@ -811,8 +816,11 @@ inode_f( lastino = igroup[lastgrp].xi_startino + xfs_highbit64(igroup[lastgrp].xi_allocmask); - printf (_("Largest inode size: %d\n"), - lastino > XFS_MAXINUMBER_32 ? 64 : 32); + if (ret_lsize) + printf (_("Largest inode size: %d\n"), + lastino > XFS_MAXINUMBER_32 ? 64 : 32); + else + printf(_("Largest inode: %llu\n"), lastino); } @@ -887,7 +895,7 @@ open_init(void) inode_cmd.name = "inode"; inode_cmd.cfunc = inode_f; - inode_cmd.args = _("[-s]"); + inode_cmd.args = _("[-s | -l]"); inode_cmd.argmin = 1; inode_cmd.argmax = 1; inode_cmd.flags = CMD_NOMAP_OK; -- 2.4.3 From cmaiolino@redhat.com Fri Sep 25 08:08:03 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 3FE4C7F56 for ; Fri, 25 Sep 2015 08:08:03 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id EF90230404E for ; Fri, 25 Sep 2015 06:07:59 -0700 (PDT) X-ASG-Debug-ID: 1443186476-04bdf04627dd9a0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id ofi5nQMZq9bdal6t (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 06:07:56 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 1F2ED19F20B for ; Fri, 25 Sep 2015 13:07:56 +0000 (UTC) Received: from zion.usersys.redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PD7paa000474 for ; Fri, 25 Sep 2015 09:07:55 -0400 From: Carlos Maiolino To: xfs@oss.sgi.com Subject: [PATCH 1/3] xfs_io: Add inode '-s' command to query physical size of largest inode Date: Fri, 25 Sep 2015 15:07:45 +0200 X-ASG-Orig-Subj: [PATCH 1/3] xfs_io: Add inode '-s' command to query physical size of largest inode Message-Id: <1443186467-20110-2-git-send-email-cmaiolino@redhat.com> In-Reply-To: <1443186467-20110-1-git-send-email-cmaiolino@redhat.com> References: <1443186467-20110-1-git-send-email-cmaiolino@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443186476 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Add a new inode command to xfs_io, which aims to implement a tool for query information about inode usage of the filesystem. This patch implements '-s' inode option, which query the filesystem for the physical size of the largest filesystem inode Signed-off-by: Carlos Maiolino --- io/open.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) diff --git a/io/open.c b/io/open.c index ac5a5e0..6a794ba 100644 --- a/io/open.c +++ b/io/open.c @@ -20,6 +20,7 @@ #include "input.h" #include "init.h" #include "io.h" +#include "libxfs.h" #ifndef __O_TMPFILE #if defined __alpha__ @@ -44,6 +45,7 @@ static cmdinfo_t statfs_cmd; static cmdinfo_t chproj_cmd; static cmdinfo_t lsproj_cmd; static cmdinfo_t extsize_cmd; +static cmdinfo_t inode_cmd; static prid_t prid; static long extsize; @@ -750,6 +752,74 @@ statfs_f( return 0; } +static void +inode_help(void) +{ + printf(_( +"\n" +"Query physical information about the inode" +"\n" +" -s -- Returns the physical size (in bits) of the\n" +" largest inode number in the filesystem\n" +"\n")); +} + +static int +inode_f( + int argc, + char **argv) +{ + __s32 count = 0; + __s32 lastgrp = 0; + __u64 last = 0; + __u64 lastino = 0; + struct xfs_inogrp igroup[1024]; + struct xfs_fsop_bulkreq bulkreq; + int c; + int ret_lsize = 0; + + bulkreq.lastip = &last; + bulkreq.icount = 1024; /* maybe an user-defined value!? */ + bulkreq.ubuffer = &igroup; + bulkreq.ocount = &count; + + while ((c = getopt(argc, argv, "s")) != EOF) { + switch (c) { + case 's': + ret_lsize = 1; + break; + default: + return command_usage(&inode_cmd); + } + } + + if (ret_lsize) { + for (;;) { + if (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, + &bulkreq)) { + perror("XFS_IOC_FSINUMBERS"); + exitcode = 1; + return 0; + } + if (count < XFS_INODES_PER_CHUNK && count > 0) + lastgrp = count; + if (!count) + break; + } + + lastgrp--; + lastino = igroup[lastgrp].xi_startino + + xfs_highbit64(igroup[lastgrp].xi_allocmask); + + printf (_("Largest inode size: %d\n"), + lastino > XFS_MAXINUMBER_32 ? 64 : 32); + + } + + + return 0; +} + void open_init(void) { @@ -815,6 +885,16 @@ open_init(void) _("get/set preferred extent size (in bytes) for the open file"); extsize_cmd.help = extsize_help; + inode_cmd.name = "inode"; + inode_cmd.cfunc = inode_f; + inode_cmd.args = _("[-s]"); + inode_cmd.argmin = 1; + inode_cmd.argmax = 1; + inode_cmd.flags = CMD_NOMAP_OK; + inode_cmd.oneline = + _("Query inode number usage in the filesystem"); + inode_cmd.help = inode_help; + add_command(&open_cmd); add_command(&stat_cmd); add_command(&close_cmd); @@ -822,4 +902,5 @@ open_init(void) add_command(&chproj_cmd); add_command(&lsproj_cmd); add_command(&extsize_cmd); + add_command(&inode_cmd); } -- 2.4.3 From cmaiolino@redhat.com Fri Sep 25 08:08:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id D3D007F61 for ; Fri, 25 Sep 2015 08:08:05 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id B41B28F8065 for ; Fri, 25 Sep 2015 06:08:02 -0700 (PDT) X-ASG-Debug-ID: 1443186481-04cb6c6b05d9fd0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Jz3gNSFL6RcNWR4E (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 06:08:01 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 00EE4C0B91AE for ; Fri, 25 Sep 2015 13:08:00 +0000 (UTC) Received: from zion.usersys.redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PD7pac000474 for ; Fri, 25 Sep 2015 09:08:00 -0400 From: Carlos Maiolino To: xfs@oss.sgi.com Subject: [PATCH 3/3] xfs_io: implement inode '-n' and [num] argument Date: Fri, 25 Sep 2015 15:07:47 +0200 X-ASG-Orig-Subj: [PATCH 3/3] xfs_io: implement inode '-n' and [num] argument Message-Id: <1443186467-20110-4-git-send-email-cmaiolino@redhat.com> In-Reply-To: <1443186467-20110-1-git-send-email-cmaiolino@redhat.com> References: <1443186467-20110-1-git-send-email-cmaiolino@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443186481 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 "-n [num]" argument, will return to the user the next inode valid on the filesystem after [num]. Using [num] exclusive, will test if the inode [num] is a valid inode in the filesystem or not. Signed-off-by: Carlos Maiolino --- io/open.c | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 74 insertions(+), 10 deletions(-) diff --git a/io/open.c b/io/open.c index 57ff0bf..9f68de0 100644 --- a/io/open.c +++ b/io/open.c @@ -762,6 +762,8 @@ inode_help(void) " -l -- Returns the largest inode number in the filesystem\n" " -s -- Returns the physical size (in bits) of the\n" " largest inode number in the filesystem\n" +" -n -- Return the next valid inode after [num]" +"[num] Check if the inode [num] exists in the filesystem" "\n")); } @@ -774,18 +776,19 @@ inode_f( __s32 lastgrp = 0; __u64 last = 0; __u64 lastino = 0; - struct xfs_inogrp igroup[1024]; - struct xfs_fsop_bulkreq bulkreq; + __u64 userino = 0; + char *p; int c; int ret_lsize = 0; int ret_largest = 0; + int ret_isvalid = 0; + int ret_next = 0; + struct xfs_inogrp igroup[1024]; + struct xfs_fsop_bulkreq bulkreq; + struct xfs_bstat bstat; - bulkreq.lastip = &last; - bulkreq.icount = 1024; /* maybe an user-defined value!? */ - bulkreq.ubuffer = &igroup; - bulkreq.ocount = &count; - while ((c = getopt(argc, argv, "sl")) != EOF) { + while ((c = getopt(argc, argv, "sln:")) != EOF) { switch (c) { case 's': ret_lsize = 1; @@ -793,12 +796,34 @@ inode_f( case 'l': ret_largest = 1; break; + case 'n': + ret_next = 1; + userino = strtoull(optarg, &p, 10); + break; default: return command_usage(&inode_cmd); } } + if ((optind < argc) && !(ret_next || ret_lsize || ret_largest)) { + ret_isvalid = 1; + userino = strtoull(argv[optind], &p, 10); + } + + if (userino) + if (*p != '\0') { + printf("[num] must be a valid number\n"); + exitcode = 1; + return 0; + } + if (ret_lsize || ret_largest) { + + bulkreq.lastip = &last; + bulkreq.icount = 1024; /* User-defined maybe!? */ + bulkreq.ubuffer = &igroup; + bulkreq.ocount = &count; + for (;;) { if (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, &bulkreq)) { @@ -806,7 +831,7 @@ inode_f( exitcode = 1; return 0; } - if (count < XFS_INODES_PER_CHUNK && count > 0) + if (count < 1024 && count > 0) lastgrp = count; if (!count) break; @@ -822,8 +847,47 @@ inode_f( else printf(_("Largest inode: %llu\n"), lastino); + return 0; + } + + /* Setup bulkreq for -n or [num] only */ + last = userino; + bulkreq.lastip = &last; + bulkreq.icount = 1; + bulkreq.ubuffer = &bstat; + bulkreq.ocount = &count; + + if (ret_next) { + if (xfsctl(file->name, file->fd, XFS_IOC_FSBULKSTAT, &bulkreq)) { + if (errno == EINVAL) + printf("Invalid or non-existent inode\n"); + else + perror("XFS_IOC_FSBULKSTAT"); + exitcode = 1; + return 0; + } + + if (!bstat.bs_ino) { + printf("There are no further inodes in the filesystem\n"); + return 0; + } + + printf("Next inode: %llu\n", bstat.bs_ino); + return 0; } + if (ret_isvalid) { + if (xfsctl(file->name, file->fd, XFS_IOC_FSBULKSTAT_SINGLE, &bulkreq)) { + if (errno == EINVAL) { + printf("Invalid or non-existent inode number\n"); + } else + perror("XFS_IOC_FSBULKSTAT_SINGLE"); + exitcode = 1; + return 0; + } + printf("Valid inode: %llu\n", bstat.bs_ino); + return 0; + } return 0; } @@ -895,9 +959,9 @@ open_init(void) inode_cmd.name = "inode"; inode_cmd.cfunc = inode_f; - inode_cmd.args = _("[-s | -l]"); + inode_cmd.args = _("[-s | -l | -n] [num]"); inode_cmd.argmin = 1; - inode_cmd.argmax = 1; + inode_cmd.argmax = 2; inode_cmd.flags = CMD_NOMAP_OK; inode_cmd.oneline = _("Query inode number usage in the filesystem"); -- 2.4.3 From cmaiolino@redhat.com Fri Sep 25 08:12:51 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 4AE357F37 for ; Fri, 25 Sep 2015 08:12:51 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 369318F8035 for ; Fri, 25 Sep 2015 06:12:51 -0700 (PDT) X-ASG-Debug-ID: 1443186769-04cbb033b0ea3f0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id DIHMLUJyYI169g1L (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 06:12:50 -0700 (PDT) X-Barracuda-Envelope-From: cmaiolino@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 94C588C1DA for ; Fri, 25 Sep 2015 13:12:49 +0000 (UTC) Received: from redhat.com (dhcp-26-103.brq.redhat.com [10.34.26.103]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PDCkth003323 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 25 Sep 2015 09:12:49 -0400 Date: Fri, 25 Sep 2015 15:12:46 +0200 From: Carlos Maiolino To: xfs@oss.sgi.com Subject: Re: [PATCH 1/3] xfs_io: Add inode '-s' command to query physical size of largest inode Message-ID: <20150925131246.GA3341@redhat.com> X-ASG-Orig-Subj: Re: [PATCH 1/3] xfs_io: Add inode '-s' command to query physical size of largest inode Mail-Followup-To: xfs@oss.sgi.com References: <1443186467-20110-1-git-send-email-cmaiolino@redhat.com> <1443186467-20110-2-git-send-email-cmaiolino@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1443186467-20110-2-git-send-email-cmaiolino@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443186770 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Fri, Sep 25, 2015 at 03:07:45PM +0200, Carlos Maiolino wrote: > Add a new inode command to xfs_io, which aims to implement a tool for query > information about inode usage of the filesystem. > > This patch implements '-s' inode option, which query the filesystem for the > physical size of the largest filesystem inode > > Signed-off-by: Carlos Maiolino > --- > io/open.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 81 insertions(+) > > diff --git a/io/open.c b/io/open.c > index ac5a5e0..6a794ba 100644 > --- a/io/open.c > +++ b/io/open.c > @@ -20,6 +20,7 @@ > #include "input.h" > #include "init.h" > #include "io.h" > +#include "libxfs.h" > > #ifndef __O_TMPFILE > #if defined __alpha__ > @@ -44,6 +45,7 @@ static cmdinfo_t statfs_cmd; > static cmdinfo_t chproj_cmd; > static cmdinfo_t lsproj_cmd; > static cmdinfo_t extsize_cmd; > +static cmdinfo_t inode_cmd; > static prid_t prid; > static long extsize; > > @@ -750,6 +752,74 @@ statfs_f( > return 0; > } > > +static void > +inode_help(void) > +{ > + printf(_( > +"\n" > +"Query physical information about the inode" > +"\n" > +" -s -- Returns the physical size (in bits) of the\n" > +" largest inode number in the filesystem\n" > +"\n")); > +} > + > +static int > +inode_f( > + int argc, > + char **argv) > +{ > + __s32 count = 0; > + __s32 lastgrp = 0; > + __u64 last = 0; > + __u64 lastino = 0; > + struct xfs_inogrp igroup[1024]; > + struct xfs_fsop_bulkreq bulkreq; > + int c; > + int ret_lsize = 0; > + > + bulkreq.lastip = &last; > + bulkreq.icount = 1024; /* maybe an user-defined value!? */ > + bulkreq.ubuffer = &igroup; > + bulkreq.ocount = &count; > + > + while ((c = getopt(argc, argv, "s")) != EOF) { > + switch (c) { > + case 's': > + ret_lsize = 1; > + break; > + default: > + return command_usage(&inode_cmd); > + } > + } > + > + if (ret_lsize) { > + for (;;) { > + if (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS, > + &bulkreq)) { > + perror("XFS_IOC_FSINUMBERS"); > + exitcode = 1; > + return 0; > + } > + if (count < XFS_INODES_PER_CHUNK && count > 0) ^^^ bummer :( I forgot to remove this macro before commiting this patch, it has been changed to 1024 in the patch 3/3 will fix this up before sending V3, after getting more reviews on these patches > + lastgrp = count; > + if (!count) > + break; > + } > + > + lastgrp--; > + lastino = igroup[lastgrp].xi_startino + > + xfs_highbit64(igroup[lastgrp].xi_allocmask); > + > + printf (_("Largest inode size: %d\n"), > + lastino > XFS_MAXINUMBER_32 ? 64 : 32); > + > + } > + > + > + return 0; > +} > + > void > open_init(void) > { > @@ -815,6 +885,16 @@ open_init(void) > _("get/set preferred extent size (in bytes) for the open file"); > extsize_cmd.help = extsize_help; > > + inode_cmd.name = "inode"; > + inode_cmd.cfunc = inode_f; > + inode_cmd.args = _("[-s]"); > + inode_cmd.argmin = 1; > + inode_cmd.argmax = 1; > + inode_cmd.flags = CMD_NOMAP_OK; > + inode_cmd.oneline = > + _("Query inode number usage in the filesystem"); > + inode_cmd.help = inode_help; > + > add_command(&open_cmd); > add_command(&stat_cmd); > add_command(&close_cmd); > @@ -822,4 +902,5 @@ open_init(void) > add_command(&chproj_cmd); > add_command(&lsproj_cmd); > add_command(&extsize_cmd); > + add_command(&inode_cmd); > } > -- > 2.4.3 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- Carlos From mstsxfx@gmail.com Fri Sep 25 10:04:32 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id CF0097F37 for ; Fri, 25 Sep 2015 10:04:32 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id BE6A930404E for ; Fri, 25 Sep 2015 08:04:29 -0700 (PDT) X-ASG-Debug-ID: 1443193466-04cbb033b1ecaa0001-NocioJ Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by cuda.sgi.com with ESMTP id At98XTcEPtlj2HT4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 25 Sep 2015 08:04:27 -0700 (PDT) X-Barracuda-Envelope-From: mstsxfx@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.212.175 Received: by wiclk2 with SMTP id lk2so23531094wic.1 for ; Fri, 25 Sep 2015 08:04:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=from:to:cc:subject:date:message-id; bh=cO6Elm7LeS5rbA4o4OckM2EvneinDPHj/7NwtK6H3vM=; b=eMmT/7I+6wZK8kyfMWMG/unW0L0lVlCTrq/HtnDYxRrTqaAwyiD0iRJzel5RbQ07MF F0t+s6lVMzwR6Xjz9uaTBQRvq0XUuZwclj2gioiDlKkPgnuMOBN+ZxXvV+C0dhwAYtf2 FEy+WtsVOIJb0lbQPcvWVxwdsZ3bLgOOXndPKLPcPXD7mnRod4ywJCoUzL7zeWcD8/jh nlVEiyUvh9CfS6LJtPuPm4l1LdvN+Bbay+WUp1RzBev6Tw51/sUXe1TD5ruSSUwEzjSz SELsCMTccm21lrU0f5kdr/dTXdO8yGMGugY4yz1PikjOw/idSU8lvuBDZgzNcJuh5sAw wDuQ== X-Received: by 10.180.105.234 with SMTP id gp10mr3726656wib.51.1443193466175; Fri, 25 Sep 2015 08:04:26 -0700 (PDT) Received: from tiehlicka.suse.cz (nat1.scz.suse.com. [213.151.88.250]) by smtp.gmail.com with ESMTPSA id ub7sm3670698wib.17.2015.09.25.08.04.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Sep 2015 08:04:25 -0700 (PDT) From: mhocko@kernel.org To: Cc: Andrew Morton , Dave Chinner , "Theodore Ts'o" , Ming Lei , Andreas Dilger , Oleg Drokin , Al Viro , Christoph Hellwig , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, Michal Hocko Subject: [PATCH] mm, fs: Obey gfp_mapping for add_to_page_cache Date: Fri, 25 Sep 2015 17:04:21 +0200 X-ASG-Orig-Subj: [PATCH] mm, fs: Obey gfp_mapping for add_to_page_cache Message-Id: <1443193461-31402-1-git-send-email-mhocko@kernel.org> X-Mailer: git-send-email 2.5.1 X-Barracuda-Connect: mail-wi0-f175.google.com[209.85.212.175] X-Barracuda-Start-Time: 1443193467 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22890 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header From: Michal Hocko 6afdb859b710 ("mm: do not ignore mapping_gfp_mask in page cache allocation paths) has caught some users of hardcoded GFP_KERNEL used in the page cache allocation paths. This, however, wasn't complete and there were others which went unnoticed. Dave Chinner has reported the following deadlock for xfs on loop device: : With the recent merge of the loop device changes, I'm now seeing : XFS deadlock on my single CPU, 1GB RAM VM running xfs/073. : : The deadlocked is as follows: : : kloopd1: loop_queue_read_work : xfs_file_iter_read : lock XFS inode XFS_IOLOCK_SHARED (on image file) : page cache read (GFP_KERNEL) : radix tree alloc : memory reclaim : reclaim XFS inodes : log force to unpin inodes : : : xfs-cil/loop1: : xlog_cil_push : xlog_write : : xlog_state_get_iclog_space() : : : : kloopd1: loop_queue_write_work : xfs_file_write_iter : lock XFS inode XFS_IOLOCK_EXCL (on image file) : : : i.e. the kloopd, with it's split read and write work queues, has : introduced a dependency through memory reclaim. i.e. that writes : need to be able to progress for reads make progress. : : The problem, fundamentally, is that mpage_readpages() does a : GFP_KERNEL allocation, rather than paying attention to the inode's : mapping gfp mask, which is set to GFP_NOFS. : : The didn't used to happen, because the loop device used to issue : reads through the splice path and that does: : : error = add_to_page_cache_lru(page, mapping, index, : GFP_KERNEL & mapping_gfp_mask(mapping)); This has changed by aa4d86163e4 (block: loop: switch to VFS ITER_BVEC). This patch changes mpage_readpage{s} to follow gfp mask set for the mapping. There are, however, other places which are doing basically the same. lustre:ll_dir_filler is doing GFP_KERNEL from the function which apparently uses GFP_NOFS for other allocations so let's make this consistent. cifs:readpages_get_pages is called from cifs_readpages and __cifs_readpages_from_fscache called from the same path obeys mapping gfp. ramfs_nommu_expand_for_mapping is hardcoding GFP_KERNEL as well regardless it uses mapping_gfp_mask for the page allocation. ext4_mpage_readpages is the called from the page cache allocation path same as read_pages and read_cache_pages Reported-by: Dave Chinner Signed-off-by: Michal Hocko --- Hi, this is a rebase on top of the current mmotm (2015-09-22-15-28) of the patch previously posted http://lkml.kernel.org/r/20150721085859.GG11967%40dhcp22.suse.cz There were no changes since then. As I've noticed in my previous post I cannot say I would be happy about sprinkling mapping_gfp_mask all over the place and it sounds like we should drop gfp_mask argument altogether and use it internally in __add_to_page_cache_locked that would require all the filesystems to use mapping gfp consistently which I am not sure is the case here. From a quick glance it seems that some file system use it all the time while others are selective. drivers/staging/lustre/lustre/llite/dir.c | 2 +- fs/cifs/file.c | 5 +++-- fs/ext4/readpage.c | 3 ++- fs/mpage.c | 14 +++++++++----- fs/ramfs/file-nommu.c | 5 +++-- mm/readahead.c | 6 ++++-- 6 files changed, 22 insertions(+), 13 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/dir.c b/drivers/staging/lustre/lustre/llite/dir.c index 3d746a94f92e..d746d354ce20 100644 --- a/drivers/staging/lustre/lustre/llite/dir.c +++ b/drivers/staging/lustre/lustre/llite/dir.c @@ -225,7 +225,7 @@ static int ll_dir_filler(void *_hash, struct page *page0) prefetchw(&page->flags); ret = add_to_page_cache_lru(page, inode->i_mapping, offset, - GFP_KERNEL); + GFP_NOFS); if (ret == 0) { unlock_page(page); if (ll_pagevec_add(&lru_pvec, page) == 0) diff --git a/fs/cifs/file.c b/fs/cifs/file.c index 94f81962368c..55ea7a49121b 100644 --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -3380,6 +3380,7 @@ readpages_get_pages(struct address_space *mapping, struct list_head *page_list, struct page *page, *tpage; unsigned int expected_index; int rc; + gfp_t gfp = GFP_KERNEL & mapping_gfp_mask(mapping); INIT_LIST_HEAD(tmplist); @@ -3392,7 +3393,7 @@ readpages_get_pages(struct address_space *mapping, struct list_head *page_list, */ __SetPageLocked(page); rc = add_to_page_cache_locked(page, mapping, - page->index, GFP_KERNEL); + page->index, gfp); /* give up if we can't stick it in the cache */ if (rc) { @@ -3419,7 +3420,7 @@ readpages_get_pages(struct address_space *mapping, struct list_head *page_list, __SetPageLocked(page); if (add_to_page_cache_locked(page, mapping, page->index, - GFP_KERNEL)) { + gfp)) { __ClearPageLocked(page); break; } diff --git a/fs/ext4/readpage.c b/fs/ext4/readpage.c index ec3ef93a52db..ef724bf82e87 100644 --- a/fs/ext4/readpage.c +++ b/fs/ext4/readpage.c @@ -166,7 +166,8 @@ int ext4_mpage_readpages(struct address_space *mapping, page = list_entry(pages->prev, struct page, lru); list_del(&page->lru); if (add_to_page_cache_lru(page, mapping, - page->index, GFP_KERNEL)) + page->index, + GFP_KERNEL & mapping_gfp_mask(mapping))) goto next_page; } diff --git a/fs/mpage.c b/fs/mpage.c index dde689d0759d..4a54bd13c9bd 100644 --- a/fs/mpage.c +++ b/fs/mpage.c @@ -139,7 +139,8 @@ map_buffer_to_page(struct page *page, struct buffer_head *bh, int page_block) static struct bio * do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages, sector_t *last_block_in_bio, struct buffer_head *map_bh, - unsigned long *first_logical_block, get_block_t get_block) + unsigned long *first_logical_block, get_block_t get_block, + gfp_t gfp) { struct inode *inode = page->mapping->host; const unsigned blkbits = inode->i_blkbits; @@ -278,7 +279,7 @@ do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages, } bio = mpage_alloc(bdev, blocks[0] << (blkbits - 9), min_t(int, nr_pages, bio_get_nr_vecs(bdev)), - GFP_KERNEL); + gfp); if (bio == NULL) goto confused; } @@ -361,6 +362,7 @@ mpage_readpages(struct address_space *mapping, struct list_head *pages, sector_t last_block_in_bio = 0; struct buffer_head map_bh; unsigned long first_logical_block = 0; + gfp_t gfp = GFP_KERNEL & mapping_gfp_mask(mapping); map_bh.b_state = 0; map_bh.b_size = 0; @@ -370,12 +372,13 @@ mpage_readpages(struct address_space *mapping, struct list_head *pages, prefetchw(&page->flags); list_del(&page->lru); if (!add_to_page_cache_lru(page, mapping, - page->index, GFP_KERNEL)) { + page->index, + gfp)) { bio = do_mpage_readpage(bio, page, nr_pages - page_idx, &last_block_in_bio, &map_bh, &first_logical_block, - get_block); + get_block, gfp); } page_cache_release(page); } @@ -395,11 +398,12 @@ int mpage_readpage(struct page *page, get_block_t get_block) sector_t last_block_in_bio = 0; struct buffer_head map_bh; unsigned long first_logical_block = 0; + gfp_t gfp = mapping_gfp_mask(page->mapping); map_bh.b_state = 0; map_bh.b_size = 0; bio = do_mpage_readpage(bio, page, 1, &last_block_in_bio, - &map_bh, &first_logical_block, get_block); + &map_bh, &first_logical_block, get_block, gfp); if (bio) mpage_bio_submit(READ, bio); return 0; diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c index ba1323a94924..a586467f6ff6 100644 --- a/fs/ramfs/file-nommu.c +++ b/fs/ramfs/file-nommu.c @@ -70,6 +70,7 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize) unsigned order; void *data; int ret; + gfp_t gfp = mapping_gfp_mask(inode->i_mapping); /* make various checks */ order = get_order(newsize); @@ -84,7 +85,7 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize) /* allocate enough contiguous pages to be able to satisfy the * request */ - pages = alloc_pages(mapping_gfp_mask(inode->i_mapping), order); + pages = alloc_pages(gfp, order); if (!pages) return -ENOMEM; @@ -108,7 +109,7 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize) struct page *page = pages + loop; ret = add_to_page_cache_lru(page, inode->i_mapping, loop, - GFP_KERNEL); + gfp); if (ret < 0) goto add_error; diff --git a/mm/readahead.c b/mm/readahead.c index b4937a6bfcd6..1ede8c0d3702 100644 --- a/mm/readahead.c +++ b/mm/readahead.c @@ -90,7 +90,8 @@ int read_cache_pages(struct address_space *mapping, struct list_head *pages, page = list_to_page(pages); list_del(&page->lru); if (add_to_page_cache_lru(page, mapping, - page->index, GFP_KERNEL)) { + page->index, + GFP_KERNEL & mapping_gfp_mask(mapping))) { read_cache_pages_invalidate_page(mapping, page); continue; } @@ -128,7 +129,8 @@ static int read_pages(struct address_space *mapping, struct file *filp, struct page *page = list_to_page(pages); list_del(&page->lru); if (!add_to_page_cache_lru(page, mapping, - page->index, GFP_KERNEL)) { + page->index, + GFP_KERNEL & mapping_gfp_mask(mapping))) { mapping->a_ops->readpage(filp, page); } page_cache_release(page); -- 2.5.1 From MD-NO--34305-54-FR-PR--xfs=oss.sgi.com@lists.mdirector.com Fri Sep 25 11:34:03 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE, T_KHOP_FOREIGN_CLICK autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id C9A8F7F37 for ; Fri, 25 Sep 2015 11:34:03 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3972E8F8049 for ; Fri, 25 Sep 2015 09:34:00 -0700 (PDT) X-ASG-Debug-ID: 1443198833-04bdf04622e1fc0001-NocioJ Received: from mta141.182.mdrctr.com (mta141.182.mdrctr.com [62.97.141.182]) by cuda.sgi.com with ESMTP id YQEYiFKQiMLexes7 for ; Fri, 25 Sep 2015 09:33:53 -0700 (PDT) X-Barracuda-Envelope-From: MD-NO--34305-54-FR-PR--xfs=oss.sgi.com@lists.mdirector.com X-Barracuda-Apparent-Source-IP: 62.97.141.182 Received: from pmta4.mta.antevenio.com (172.16.18.13) by mta141.181.mdrctr.com id h0lrn615miom for ; Fri, 25 Sep 2015 18:30:56 +0200 (envelope-from ) From: "L'Agneau si simple si bon !" Reply-To: "L'Agneau si simple si bon !" To: Precedence: bulk X-rpcampaign: mdMDNO3430554FRPR X-rpcampaignok: mdmdMD-NO--34305-54-FR-PR X-reputation: 5 Date: Fri, 25 Sep 2015 18:30:56 +0200 List-Id: 34305-4.mdirector.com List-Unsubscribe: , X-LU: , Subject: =?UTF-8?Q?=C3=80=20la=20rentr=C3=A9e?=, =?UTF-8?Q?=20vous=20avez=20tout=20=C3=A0=20ga?= =?UTF-8?Q?gner=20avec=20l?= 'agneau. MIME-Version: 1.0 X-ASG-Orig-Subj: =?UTF-8?Q?=C3=80=20la=20rentr=C3=A9e?=, =?UTF-8?Q?=20vous=20avez=20tout=20=C3=A0=20ga?= =?UTF-8?Q?gner=20avec=20l?= 'agneau. Content-Type: multipart/mixed; boundary="boundaryTagForMixed" Message-ID: <0.0.1.377.1D0F7AF8DB0FEF8.5CA58F@mta141.181.mdrctr.com> X-Barracuda-Connect: mta141.182.mdrctr.com[62.97.141.182] X-Barracuda-Start-Time: 1443198833 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.40 X-Barracuda-Spam-Status: No, SCORE=0.40 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA085b, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22892 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.40 BSF_SC0_SA085b Custom Rule SA085b --boundaryTagForMixed Content-Type: multipart/alternative; boundary="boundaryTagForAlternative" --boundaryTagForAlternative Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit ********************************************************************** Vous pourrez exercer vos droits d´accès, annulation, rectification et opposition concernant vos données à caractère personnel, en cliquant * annulation //www.mdirector.com/track/pre-unsubscribe/category/EMAIL/empId/34305/subId/54/listId/4/conId/27806/signature/54be1e419dcb972852d33cfb62970024/conEmail/xfs@oss.sgi.com/conMovil/- --boundaryTagForAlternative Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Recette Exclusive : WRAP À L’AGNEAU ET AU GUACAMOLE
 
Si vous n’arrivez pas à visualiser cet email, cliquez ici.
 
 
DÉCOUVREZ EN EXCLUSIVITÉ UNE RECETTE QUI VA ENCHANTER VOTRE TABLE POUR CETTE RENTRÉE !
 
Wrap Agneau Avocat
 
WRAP À L’AGNEAU ET AU GUACAMOLE
 
Temps de préparation : 15 minutesTemps de préparation : 15 minutes
 
DÉCOUVREZ LA RECETTE
 
 
TENTEZ DE GAGNER* L'UN DES 100 COFFRETS WOK OU POÊLES AVEC LEUR POIGNÉE MAGNÉTIQUE
JE TENTE MA CHANCE
 
Le saviez-vous ? Un agneau est un mouton de moins de 300 jours
S'INSCRIRE À LA NEWSLETTER
 
Campagne financée avec le concours de l'Union EuropéenneInterbevAHDBBord BIA
 
Conformément à la loi "Informatique et libertés" du 6 janvier 1978, vous bénéficiez d'un droit d'accès, de modification, de rectification et de suppression des données qui vous concernent. Si vous souhaitez exercer ce droit et obtenir communication des informations vous concernant, veuillez vous adresser à : Venise Activation, 7-13 boulevard Paul Émile Victor 92200 Neuilly-Sur-Seine.
*Le règlement du jeu concours sans obligation d’achat « Si simple et si bon de jouer avec l’agneau » est disponible en cliquant sur ce lien: http://www.sisimplesibondejoueraveclagneau.com.
 
 
Pour ne plus recevoir d'email de la part de L’agneau si simple si bon, cliquez ici.
 
Vous pourrez exercer vos droits d´accès, annulation, rectification et opposition concernant vos données à caractère personnel, en cliquant annulation.
--boundaryTagForAlternative-- --boundaryTagForMixed-- From billodo@redhat.com Fri Sep 25 18:23:44 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A5C427F37 for ; Fri, 25 Sep 2015 18:23:44 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 0DBF1AC00B for ; Fri, 25 Sep 2015 16:23:43 -0700 (PDT) X-ASG-Debug-ID: 1443223392-04cb6c6b07e6080001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id DpyXFx4vNI4oA6ZF (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 16:23:13 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id C5240C0B64BF for ; Fri, 25 Sep 2015 23:23:12 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-243.rdu2.redhat.com [10.10.55.243]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PNNBp0021662 for ; Fri, 25 Sep 2015 19:23:12 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 0/7 v8] xfs: stats in sysfs Date: Fri, 25 Sep 2015 18:22:53 -0500 X-ASG-Orig-Subj: [PATCH 0/7 v8] xfs: stats in sysfs Message-Id: <1443223380-18870-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443223393 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 0 Hello- Following is the next iteration of the series to add xfs stats to sysfs. This iteration adds patches 6 and 7 to complete the incorporation of sysfs/kobject into xfsstats, including working global and per-fs stats. ----------history--------------- v8: (add patches 6 and 7) -patch 6: per-filesystem stats in sysfs. Implement per-filesystem stats objects in sysfs. Stats objects are instantiated when an xfs filesystem is mounted and deleted on unmount. With this patch, the stats directory is created and populated with the familiar stats and stats_clear files. Example: /sys/fs/xfs/sda9/stats/stats /sys/fs/xfs/sda9/stats/stats_clear With this patch, the individual counts within the new per-fs stats file(s) remain at zero. Functions that use the the macros to increment, decrement, and add-to the per-fs stats counts will be covered in the next patch (7). Also, this patch includes some minor fixups for style issues in patch 5. -patch 7: per-filesystem stats counter implementation Modify the stats counting macros and the callers to those macros to properly increment, decrement, and add-to the xfs stats counts. The counts for global and per-fs stats are correctly advanced, and cleared by writing a "1" to the corresponding clear file. global counts: /sys/fs/xfs/stats/stats per-fs counts: /sys/fs/xfs/sda*/stats/stats global clear: /sys/fs/xfs/stats/stats_clear per-fs clear: /sys/fs/xfs/sda*/stats/stats_clear v7: add patch 5/5: incorporate sysfs/kobject in xfsstats: handlers take kobjects. Allocate & deallocate per-fs stats structures and set up the sysfs entries for them. Add kobject and a pointer to a per-cpu struct xfsstats. Modify the macros that manipulate the stats accordingly. v6: -add patch 4/4: move to_xlog(kobject) to the relevant show/store operations. This keeps the xfs_sysfs_object_show/store functions generic. Also, with the change, there can be some cleanup of the show/store function arguments. v5: -optimization of sysfs_ops function. -style fixups v4: -whitespace fixup of patch 1 -add patch 4 (sysfs ops consolidation - dbg, stats, log) v3: -style fixups and removal of extraneous printk. v2: -style fixups. v1: -------------------------------- We already have per-fs information in /sys, so it makes sense to have per-fs stats there too. The series moves existing global stats infrastructure to /sys and reuses that code to create per-fs stats in /sys. Patch 1 handles the bring-up and tear down of xfs/stats directory structure in sysfs when an fs is mounted. The directory contains the stats file and the stats_clear file. The stats file contents mimic those of /proc/fs/xfs/stat. The stats_clear file is empty, and much like the current stat_clear command, handles the zeroing of the stats file when a "1" is echoed to the stats_clear file. Patch 2 creates the symlink for stats from procfs to sysfs. Patch 3 removes the now unused portions of procfs for stat. Patch 4 consolidates the sysfs ops for dbg, stats, log. Patch 5 allocates and deallocates per-fs stats structures and sets up the sysfs entries for them. Add kobject and a pointer to a per-cpu struct xfsstats. Modify the macros that manipulate the stats accordingly. Patch 6 implements per-filesystem stats objects in sysfs. Stats objects are instantiated when an xfs filesystem is mounted and deleted on unmount. Patch 7 modifies the stats counting macros and the callers to those macros to properly increment, decrement, and add-to the xfs stats counts. The counts for global and per-fs stats are correctly advanced, and cleared by writing a "1" to the corresponding clear file. Once again, comments and questions are welcome. Thanks- Bill From billodo@redhat.com Fri Sep 25 18:23:46 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id E63AA7F37 for ; Fri, 25 Sep 2015 18:23:46 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id B49E78F8035 for ; Fri, 25 Sep 2015 16:23:46 -0700 (PDT) X-ASG-Debug-ID: 1443223395-04bdf04628ea2f0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id o0LfggtXobCPLM1h (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 16:23:15 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 4F52FC0B64C6 for ; Fri, 25 Sep 2015 23:23:15 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-243.rdu2.redhat.com [10.10.55.243]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PNNBp4021662 for ; Fri, 25 Sep 2015 19:23:14 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 4/7] xfs: consolidate sysfs ops (dbg, stats, log) Date: Fri, 25 Sep 2015 18:22:57 -0500 X-ASG-Orig-Subj: [PATCH 4/7] xfs: consolidate sysfs ops (dbg, stats, log) Message-Id: <1443223380-18870-5-git-send-email-billodo@redhat.com> In-Reply-To: <1443223380-18870-1-git-send-email-billodo@redhat.com> References: <1443223380-18870-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443223395 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 0 As a part of the series to move xfs global stats from procfs to sysfs, this patch consolidates the sysfs ops functions and removes redundancy. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 2 +- fs/xfs/xfs_sysfs.c | 182 +++++++++++++++++++---------------------------------- 2 files changed, 64 insertions(+), 120 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 05d5227..dc6ca67 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -92,7 +92,7 @@ int xfs_stats_format(char *buf) 0); #endif -return len; + return len; } void xfs_stats_clearall(void) diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index a094e20..ab4850b 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -25,8 +25,9 @@ struct xfs_sysfs_attr { struct attribute attr; - ssize_t (*show)(char *buf, void *data); - ssize_t (*store)(const char *buf, size_t count, void *data); + ssize_t (*show)(struct kobject *kobject, char *buf); + ssize_t (*store)(struct kobject *kobject, const char *buf, + size_t count); }; static inline struct xfs_sysfs_attr * @@ -54,14 +55,42 @@ struct kobj_type xfs_mp_ktype = { .release = xfs_sysfs_release, }; +STATIC ssize_t +xfs_sysfs_object_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->show ? xfs_attr->show(kobject, buf) : 0; +} + +STATIC ssize_t +xfs_sysfs_object_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->store ? xfs_attr->store(kobject, buf, count) : 0; +} + +static const struct sysfs_ops xfs_sysfs_ops = { + .show = xfs_sysfs_object_show, + .store = xfs_sysfs_object_store, +}; + #ifdef DEBUG /* debug */ STATIC ssize_t log_recovery_delay_store( + struct kobject *kobject, const char *buf, - size_t count, - void *data) + size_t count) { int ret; int val; @@ -80,8 +109,8 @@ log_recovery_delay_store( STATIC ssize_t log_recovery_delay_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { return snprintf(buf, PAGE_SIZE, "%d\n", xfs_globals.log_recovery_delay); } @@ -92,49 +121,20 @@ static struct attribute *xfs_dbg_attrs[] = { NULL, }; -STATIC ssize_t -xfs_dbg_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; -} - -STATIC ssize_t -xfs_dbg_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; -} - -static struct sysfs_ops xfs_dbg_ops = { - .show = xfs_dbg_show, - .store = xfs_dbg_store, -}; - struct kobj_type xfs_dbg_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_dbg_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_dbg_attrs, }; #endif /* DEBUG */ - /* stats */ STATIC ssize_t stats_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { return xfs_stats_format(buf); } @@ -142,9 +142,9 @@ XFS_SYSFS_ATTR_RO(stats); STATIC ssize_t stats_clear_store( + struct kobject *kobject, const char *buf, - size_t count, - void *data) + size_t count) { int ret; int val; @@ -166,50 +166,30 @@ static struct attribute *xfs_stats_attrs[] = { NULL, }; -STATIC ssize_t -xfs_stats_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; -} - -STATIC ssize_t -xfs_stats_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; -} - -static struct sysfs_ops xfs_stats_ops = { - .show = xfs_stats_show, - .store = xfs_stats_store, -}; - struct kobj_type xfs_stats_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_stats_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_stats_attrs, }; /* xlog */ +static inline struct xlog * +to_xlog(struct kobject *kobject) +{ + struct xfs_kobj *kobj = to_kobj(kobject); + + return container_of(kobj, struct xlog, l_kobj); +} + STATIC ssize_t log_head_lsn_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { - struct xlog *log = data; int cycle; int block; + struct xlog *log = to_xlog(kobject); spin_lock(&log->l_icloglock); cycle = log->l_curr_cycle; @@ -222,12 +202,12 @@ XFS_SYSFS_ATTR_RO(log_head_lsn); STATIC ssize_t log_tail_lsn_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { - struct xlog *log = data; int cycle; int block; + struct xlog *log = to_xlog(kobject); xlog_crack_atomic_lsn(&log->l_tail_lsn, &cycle, &block); return snprintf(buf, PAGE_SIZE, "%d:%d\n", cycle, block); @@ -236,12 +216,13 @@ XFS_SYSFS_ATTR_RO(log_tail_lsn); STATIC ssize_t reserve_grant_head_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) + { - struct xlog *log = data; int cycle; int bytes; + struct xlog *log = to_xlog(kobject); xlog_crack_grant_head(&log->l_reserve_head.grant, &cycle, &bytes); return snprintf(buf, PAGE_SIZE, "%d:%d\n", cycle, bytes); @@ -250,12 +231,12 @@ XFS_SYSFS_ATTR_RO(reserve_grant_head); STATIC ssize_t write_grant_head_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { - struct xlog *log = data; int cycle; int bytes; + struct xlog *log = to_xlog(kobject); xlog_crack_grant_head(&log->l_write_head.grant, &cycle, &bytes); return snprintf(buf, PAGE_SIZE, "%d:%d\n", cycle, bytes); @@ -270,45 +251,8 @@ static struct attribute *xfs_log_attrs[] = { NULL, }; -static inline struct xlog * -to_xlog(struct kobject *kobject) -{ - struct xfs_kobj *kobj = to_kobj(kobject); - return container_of(kobj, struct xlog, l_kobj); -} - -STATIC ssize_t -xfs_log_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xlog *log = to_xlog(kobject); - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, log) : 0; -} - -STATIC ssize_t -xfs_log_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xlog *log = to_xlog(kobject); - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, log) : 0; -} - -static struct sysfs_ops xfs_log_ops = { - .show = xfs_log_show, - .store = xfs_log_store, -}; - struct kobj_type xfs_log_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_log_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_log_attrs, }; -- 2.4.3 From billodo@redhat.com Fri Sep 25 18:23:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 144F17F37 for ; Fri, 25 Sep 2015 18:23:48 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id B03E3AC00B for ; Fri, 25 Sep 2015 16:23:47 -0700 (PDT) X-ASG-Debug-ID: 1443223394-04bdf04626ea2e0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id AEETDdUCk5Hdlhzj (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 16:23:14 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 0A6B285545 for ; Fri, 25 Sep 2015 23:23:14 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-243.rdu2.redhat.com [10.10.55.243]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PNNBp2021662 for ; Fri, 25 Sep 2015 19:23:13 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 2/7] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Date: Fri, 25 Sep 2015 18:22:55 -0500 X-ASG-Orig-Subj: [PATCH 2/7] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-Id: <1443223380-18870-3-git-send-email-billodo@redhat.com> In-Reply-To: <1443223380-18870-1-git-send-email-billodo@redhat.com> References: <1443223380-18870-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443223394 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 0 As a part of the work to move xfs global stats from procfs to sysfs, this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 6008e25..a9f05de 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -244,9 +244,10 @@ xfs_init_procfs(void) if (!proc_mkdir("fs/xfs", NULL)) goto out; - if (!proc_create("fs/xfs/stat", 0, NULL, - &xfs_stat_proc_fops)) + if (!proc_symlink("fs/xfs/stat", NULL, + "/sys/fs/xfs/stats/stats")) goto out_remove_xfs_dir; + #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, &xqmstat_proc_fops)) -- 2.4.3 From billodo@redhat.com Fri Sep 25 18:23:49 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id EA3A77F51 for ; Fri, 25 Sep 2015 18:23:48 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id B826B30404E for ; Fri, 25 Sep 2015 16:23:45 -0700 (PDT) X-ASG-Debug-ID: 1443223394-04bdf04622ea2e0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id DLSixXeaRxj2Er1m (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 16:23:14 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 946F76D for ; Fri, 25 Sep 2015 23:23:14 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-243.rdu2.redhat.com [10.10.55.243]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PNNBp3021662 for ; Fri, 25 Sep 2015 19:23:14 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 3/7] xfs: remove unused procfs code Date: Fri, 25 Sep 2015 18:22:56 -0500 X-ASG-Orig-Subj: [PATCH 3/7] xfs: remove unused procfs code Message-Id: <1443223380-18870-4-git-send-email-billodo@redhat.com> In-Reply-To: <1443223380-18870-1-git-send-email-billodo@redhat.com> References: <1443223380-18870-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443223394 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 0 As a part of the work to move xfs global stats from procfs to sysfs, this patch removes the now unused procfs code that was xfs stat specific. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 74 ------------------------------------------------------ 1 file changed, 74 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index a9f05de..05d5227 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -112,80 +112,6 @@ void xfs_stats_clearall(void) } } -static int xfs_stat_proc_show(struct seq_file *m, void *v) -{ - int i, j; - __uint64_t xs_xstrat_bytes = 0; - __uint64_t xs_write_bytes = 0; - __uint64_t xs_read_bytes = 0; - - static const struct xstats_entry { - char *desc; - int endpoint; - } xstats[] = { - { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, - { "abt", XFSSTAT_END_ALLOC_BTREE }, - { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, - { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, - { "dir", XFSSTAT_END_DIRECTORY_OPS }, - { "trans", XFSSTAT_END_TRANSACTIONS }, - { "ig", XFSSTAT_END_INODE_OPS }, - { "log", XFSSTAT_END_LOG_OPS }, - { "push_ail", XFSSTAT_END_TAIL_PUSHING }, - { "xstrat", XFSSTAT_END_WRITE_CONVERT }, - { "rw", XFSSTAT_END_READ_WRITE_OPS }, - { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, - { "icluster", XFSSTAT_END_INODE_CLUSTER }, - { "vnodes", XFSSTAT_END_VNODE_OPS }, - { "buf", XFSSTAT_END_BUF }, - { "abtb2", XFSSTAT_END_ABTB_V2 }, - { "abtc2", XFSSTAT_END_ABTC_V2 }, - { "bmbt2", XFSSTAT_END_BMBT_V2 }, - { "ibt2", XFSSTAT_END_IBT_V2 }, - { "fibt2", XFSSTAT_END_FIBT_V2 }, - /* we print both series of quota information together */ - { "qm", XFSSTAT_END_QM }, - }; - - /* Loop over all stats groups */ - for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { - seq_printf(m, "%s", xstats[i].desc); - /* inner loop does each group */ - for (; j < xstats[i].endpoint; j++) - seq_printf(m, " %u", counter_val(j)); - seq_putc(m, '\n'); - } - /* extra precision counters */ - for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; - } - - seq_printf(m, "xpc %Lu %Lu %Lu\n", - xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); - seq_printf(m, "debug %u\n", -#if defined(DEBUG) - 1); -#else - 0); -#endif - return 0; -} - -static int xfs_stat_proc_open(struct inode *inode, struct file *file) -{ - return single_open(file, xfs_stat_proc_show, NULL); -} - -static const struct file_operations xfs_stat_proc_fops = { - .owner = THIS_MODULE, - .open = xfs_stat_proc_open, - .read = seq_read, - .llseek = seq_lseek, - .release = single_release, -}; - /* legacy quota interfaces */ #ifdef CONFIG_XFS_QUOTA static int xqm_proc_show(struct seq_file *m, void *v) -- 2.4.3 From billodo@redhat.com Fri Sep 25 18:23:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id BC23E7F37 for ; Fri, 25 Sep 2015 18:23:48 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 59120AC00B for ; Fri, 25 Sep 2015 16:23:48 -0700 (PDT) X-ASG-Debug-ID: 1443223393-04bdf04627ea2e0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id w1B2RI1XCCCUFRcQ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 16:23:14 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 864FFC0B1B33 for ; Fri, 25 Sep 2015 23:23:13 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-243.rdu2.redhat.com [10.10.55.243]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PNNBp1021662 for ; Fri, 25 Sep 2015 19:23:12 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 1/7] xfs: create global stats and stats_clear in sysfs Date: Fri, 25 Sep 2015 18:22:54 -0500 X-ASG-Orig-Subj: [PATCH 1/7] xfs: create global stats and stats_clear in sysfs Message-Id: <1443223380-18870-2-git-send-email-billodo@redhat.com> In-Reply-To: <1443223380-18870-1-git-send-email-billodo@redhat.com> References: <1443223380-18870-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443223394 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 0 Currently, xfs global stats are in procfs. This patch introduces (replicates) the global stats in sysfs. Additionally a stats_clear file is introduced in sysfs. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_stats.h | 2 ++ fs/xfs/xfs_super.c | 20 +++++++++---- fs/xfs/xfs_sysctl.c | 15 ++-------- fs/xfs/xfs_sysfs.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_sysfs.h | 1 + 6 files changed, 179 insertions(+), 17 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index f224038..6008e25 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -29,6 +29,89 @@ static int counter_val(int idx) return val; } +int xfs_stats_format(char *buf) +{ + int i, j; + int len = 0; + __uint64_t xs_xstrat_bytes = 0; + __uint64_t xs_write_bytes = 0; + __uint64_t xs_read_bytes = 0; + + static const struct xstats_entry { + char *desc; + int endpoint; + } xstats[] = { + { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, + { "abt", XFSSTAT_END_ALLOC_BTREE }, + { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, + { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, + { "dir", XFSSTAT_END_DIRECTORY_OPS }, + { "trans", XFSSTAT_END_TRANSACTIONS }, + { "ig", XFSSTAT_END_INODE_OPS }, + { "log", XFSSTAT_END_LOG_OPS }, + { "push_ail", XFSSTAT_END_TAIL_PUSHING }, + { "xstrat", XFSSTAT_END_WRITE_CONVERT }, + { "rw", XFSSTAT_END_READ_WRITE_OPS }, + { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, + { "icluster", XFSSTAT_END_INODE_CLUSTER }, + { "vnodes", XFSSTAT_END_VNODE_OPS }, + { "buf", XFSSTAT_END_BUF }, + { "abtb2", XFSSTAT_END_ABTB_V2 }, + { "abtc2", XFSSTAT_END_ABTC_V2 }, + { "bmbt2", XFSSTAT_END_BMBT_V2 }, + { "ibt2", XFSSTAT_END_IBT_V2 }, + { "fibt2", XFSSTAT_END_FIBT_V2 }, + /* we print both series of quota information together */ + { "qm", XFSSTAT_END_QM }, + }; + + /* Loop over all stats groups */ + + for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { + len += snprintf(buf + len, PATH_MAX - len, "%s", + xstats[i].desc); + /* inner loop does each group */ + for (; j < xstats[i].endpoint; j++) + len += snprintf(buf + len, PATH_MAX - len, " %u", + counter_val(j)); + len += snprintf(buf + len, PATH_MAX - len, "\n"); + } + /* extra precision counters */ + for_each_possible_cpu(i) { + xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; + xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; + xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; + } + + len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", + xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); + len += snprintf(buf+len, PATH_MAX-len, "debug %u\n", +#if defined(DEBUG) + 1); +#else + 0); +#endif + +return len; +} + +void xfs_stats_clearall(void) +{ + int c; + __uint32_t vn_active; + + xfs_notice(NULL, "Clearing xfsstats"); + for_each_possible_cpu(c) { + preempt_disable(); + /* save vn_active, it's a universal truth! */ + vn_active = per_cpu(xfsstats, c).vn_active; + memset(&per_cpu(xfsstats, c), 0, + sizeof(struct xfsstats)); + per_cpu(xfsstats, c).vn_active = vn_active; + preempt_enable(); + } +} + static int xfs_stat_proc_show(struct seq_file *m, void *v) { int i, j; diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index c8f238b..18807b5 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -18,6 +18,8 @@ #ifndef __XFS_STATS_H__ #define __XFS_STATS_H__ +int xfs_stats_format(char *buf); +void xfs_stats_clearall(void); #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 904f637..0dfc53b 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -61,6 +61,7 @@ static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; static struct kset *xfs_kset; /* top-level xfs sysfs dir */ +static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ #ifdef DEBUG static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ #endif @@ -1838,19 +1839,25 @@ init_xfs_fs(void) xfs_kset = kset_create_and_add("xfs", NULL, fs_kobj); if (!xfs_kset) { error = -ENOMEM; - goto out_sysctl_unregister;; + goto out_sysctl_unregister; } + xfs_stats_kobj.kobject.kset = xfs_kset; + error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, + "stats"); + if (error) + goto out_kset_unregister; + #ifdef DEBUG xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_kset_unregister; + goto out_remove_stats_kobj; #endif error = xfs_qm_init(); if (error) - goto out_remove_kobj; + goto out_remove_dbg_kobj; error = register_filesystem(&xfs_fs_type); if (error) @@ -1859,11 +1866,13 @@ init_xfs_fs(void) out_qm_exit: xfs_qm_exit(); - out_remove_kobj: + out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_kset_unregister: + out_remove_stats_kobj: #endif + xfs_sysfs_del(&xfs_stats_kobj); + out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: xfs_sysctl_unregister(); @@ -1889,6 +1898,7 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif + xfs_sysfs_del(&xfs_stats_kobj); kset_unregister(xfs_kset); xfs_sysctl_unregister(); xfs_cleanup_procfs(); diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c index a0c8067..5defabb 100644 --- a/fs/xfs/xfs_sysctl.c +++ b/fs/xfs/xfs_sysctl.c @@ -19,6 +19,7 @@ #include #include #include "xfs_error.h" +#include "xfs_stats.h" static struct ctl_table_header *xfs_table_header; @@ -31,22 +32,12 @@ xfs_stats_clear_proc_handler( size_t *lenp, loff_t *ppos) { - int c, ret, *valp = ctl->data; - __uint32_t vn_active; + int ret, *valp = ctl->data; ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); if (!ret && write && *valp) { - xfs_notice(NULL, "Clearing xfsstats"); - for_each_possible_cpu(c) { - preempt_disable(); - /* save vn_active, it's a universal truth! */ - vn_active = per_cpu(xfsstats, c).vn_active; - memset(&per_cpu(xfsstats, c), 0, - sizeof(struct xfsstats)); - per_cpu(xfsstats, c).vn_active = vn_active; - preempt_enable(); - } + xfs_stats_clearall(); xfs_stats_clear = 0; } diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index aa03670..a094e20 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -21,6 +21,7 @@ #include "xfs_log_format.h" #include "xfs_log.h" #include "xfs_log_priv.h" +#include "xfs_stats.h" struct xfs_sysfs_attr { struct attribute attr; @@ -38,6 +39,8 @@ to_attr(struct attribute *attr) static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RW(name) #define XFS_SYSFS_ATTR_RO(name) \ static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RO(name) +#define XFS_SYSFS_ATTR_WO(name) \ + static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_WO(name) #define ATTR_LIST(name) &xfs_sysfs_attr_##name.attr @@ -125,6 +128,78 @@ struct kobj_type xfs_dbg_ktype = { #endif /* DEBUG */ + +/* stats */ + +STATIC ssize_t +stats_show( + char *buf, + void *data) +{ + return xfs_stats_format(buf); +} +XFS_SYSFS_ATTR_RO(stats); + +STATIC ssize_t +stats_clear_store( + const char *buf, + size_t count, + void *data) +{ + int ret; + int val; + + ret = kstrtoint(buf, 0, &val); + if (ret) + return ret; + + if (val != 1) + return -EINVAL; + xfs_stats_clearall(); + return count; +} +XFS_SYSFS_ATTR_WO(stats_clear); + +static struct attribute *xfs_stats_attrs[] = { + ATTR_LIST(stats), + ATTR_LIST(stats_clear), + NULL, +}; + +STATIC ssize_t +xfs_stats_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; +} + +STATIC ssize_t +xfs_stats_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; +} + +static struct sysfs_ops xfs_stats_ops = { + .show = xfs_stats_show, + .store = xfs_stats_store, +}; + +struct kobj_type xfs_stats_ktype = { + .release = xfs_sysfs_release, + .sysfs_ops = &xfs_stats_ops, + .default_attrs = xfs_stats_attrs, +}; + /* xlog */ STATIC ssize_t diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h index 240eee3..be692e5 100644 --- a/fs/xfs/xfs_sysfs.h +++ b/fs/xfs/xfs_sysfs.h @@ -22,6 +22,7 @@ extern struct kobj_type xfs_mp_ktype; /* xfs_mount */ extern struct kobj_type xfs_dbg_ktype; /* debug */ extern struct kobj_type xfs_log_ktype; /* xlog */ +extern struct kobj_type xfs_stats_ktype; /* stats */ static inline struct xfs_kobj * to_kobj(struct kobject *kobject) -- 2.4.3 From billodo@redhat.com Fri Sep 25 18:23:51 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 06A827F37 for ; Fri, 25 Sep 2015 18:23:51 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id CCF7230404E for ; Fri, 25 Sep 2015 16:23:50 -0700 (PDT) X-ASG-Debug-ID: 1443223399-04bdf04622ea2f0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id XfD71spyF1GLYhtO (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 16:23:19 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 5465F2FAA7A for ; Fri, 25 Sep 2015 23:23:19 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-243.rdu2.redhat.com [10.10.55.243]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PNNBp6021662 for ; Fri, 25 Sep 2015 19:23:16 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 6/7] xfs: per-filesystem stats in sysfs. Date: Fri, 25 Sep 2015 18:22:59 -0500 X-ASG-Orig-Subj: [PATCH 6/7] xfs: per-filesystem stats in sysfs. Message-Id: <1443223380-18870-7-git-send-email-billodo@redhat.com> In-Reply-To: <1443223380-18870-1-git-send-email-billodo@redhat.com> References: <1443223380-18870-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443223399 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 0 This patch implements per-filesystem stats objects in sysfs. It depends on the application of the previous patch series that develops the infrastructure to support both xfs global stats and xfs per-fs stats in sysfs. Stats objects are instantiated when an xfs filesystem is mounted and deleted on unmount. With this patch, the stats directory is created and populated with the familiar stats and stats_clear files. Example: /sys/fs/xfs/sda9/stats/stats /sys/fs/xfs/sda9/stats/stats_clear With this patch, the individual counts within the new per-fs stats file(s) remain at zero. Functions that use the the macros to increment, decrement, and add-to the per-fs stats counts will be covered in a separate new patch to follow this one. Note that the counts within the global stats file (/sys/fs/xfs/stats/stats) advance normally and can be cleared as it was prior to this patch. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_linux.h | 4 ++-- fs/xfs/xfs_mount.c | 24 +++++++++++++++++++++++- fs/xfs/xfs_mount.h | 1 + fs/xfs/xfs_stats.c | 34 +++++++++++++++++++--------------- fs/xfs/xfs_stats.h | 5 ++++- fs/xfs/xfs_super.c | 21 ++++++++++++++++----- fs/xfs/xfs_sysfs.c | 6 +++--- 7 files changed, 68 insertions(+), 27 deletions(-) diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h index f1a8505..ec0e239 100644 --- a/fs/xfs/xfs_linux.h +++ b/fs/xfs/xfs_linux.h @@ -172,8 +172,8 @@ struct xfs_kobj { }; struct xstats { - struct xfsstats __percpu *xs_stats; - struct xfs_kobj xs_kobj; + struct xfsstats __percpu *xs_stats; + struct xfs_kobj xs_kobj; }; extern struct xstats xfsstats; diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index bf92e0c..5921d18 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -791,11 +791,25 @@ xfs_mountfs( goto out_free_dir; } + /* + * Allocate stats memory and create stats sysfs object. + */ + mp->m_stats.xs_stats = alloc_percpu(struct xfsstats); + if (IS_ERR(mp->m_stats.xs_stats)) { + error = PTR_ERR(mp->m_stats.xs_stats); + goto out_free_perag; + } + error = xfs_sysfs_init(&mp->m_stats.xs_kobj, &xfs_stats_ktype, + &mp->m_kobj, + "stats"); + if (error) + goto out_free_stats; + if (!sbp->sb_logblocks) { xfs_warn(mp, "no log defined"); XFS_ERROR_REPORT("xfs_mountfs", XFS_ERRLEVEL_LOW, mp); error = -EFSCORRUPTED; - goto out_free_perag; + goto out_del_stats; } /* @@ -965,6 +979,10 @@ xfs_mountfs( if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) xfs_wait_buftarg(mp->m_logdev_targp); xfs_wait_buftarg(mp->m_ddev_targp); + out_del_stats: + xfs_sysfs_del(&mp->m_stats.xs_kobj); + out_free_stats: + free_percpu(mp->m_stats.xs_stats); out_free_perag: xfs_free_perag(mp); out_free_dir: @@ -1047,6 +1065,10 @@ xfs_unmountfs( xfs_warn(mp, "Unable to update superblock counters. " "Freespace may not be correct on next mount."); + /* remove the stats kobject and free stats memory */ + xfs_sysfs_del(&mp->m_stats.xs_kobj); + free_percpu(mp->m_stats.xs_stats); + xfs_log_unmount(mp); xfs_da_unmount(mp); xfs_uuid_unmount(mp); diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 7999e91..8795272 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -127,6 +127,7 @@ typedef struct xfs_mount { int64_t m_low_space[XFS_LOWSP_MAX]; /* low free space thresholds */ struct xfs_kobj m_kobj; + struct xstats m_stats; /* per-fs stats */ struct workqueue_struct *m_buf_workqueue; struct workqueue_struct *m_data_workqueue; diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index ab79973..d5b3704 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -18,6 +18,11 @@ #include "xfs.h" #include +#include "xfs_format.h" +#include "xfs_trans_resv.h" +#include "xfs_mount.h" +#include "xfs_sysfs.h" + struct xstats xfsstats; static int counter_val(struct xfsstats __percpu *stats, int idx) @@ -25,7 +30,7 @@ static int counter_val(struct xfsstats __percpu *stats, int idx) int val = 0, cpu; for_each_possible_cpu(cpu) - val += *(((__u32 *)&per_cpu(*stats, cpu) + idx)); + val += *(((__u32 *)per_cpu_ptr(stats, cpu) + idx)); return val; } @@ -78,9 +83,9 @@ int xfs_stats_format(struct xfsstats __percpu *stats, char *buf) } /* extra precision counters */ for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(*stats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(*stats, i).xs_write_bytes; - xs_read_bytes += per_cpu(*stats, i).xs_read_bytes; + xs_xstrat_bytes += per_cpu_ptr(stats, i)->xs_xstrat_bytes; + xs_write_bytes += per_cpu_ptr(stats, i)->xs_write_bytes; + xs_read_bytes += per_cpu_ptr(stats, i)->xs_read_bytes; } len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", @@ -104,10 +109,9 @@ void xfs_stats_clearall(struct xfsstats __percpu *stats) for_each_possible_cpu(c) { preempt_disable(); /* save vn_active, it's a universal truth! */ - vn_active = per_cpu(*stats, c).vn_active; - memset(&per_cpu(*stats, c), 0, - sizeof(*stats)); - per_cpu(*stats, c).vn_active = vn_active; + vn_active = per_cpu_ptr(stats, c)->vn_active; + memset(per_cpu_ptr(stats, c), 0, sizeof(*stats)); + per_cpu_ptr(stats, c)->vn_active = vn_active; preempt_enable(); } } @@ -172,28 +176,28 @@ xfs_init_procfs(void) goto out; if (!proc_symlink("fs/xfs/stat", NULL, - "/sys/fs/xfs/stats/stats")) + "/sys/fs/xfs/stats/stats")) goto out_remove_xfs_dir; #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, - &xqmstat_proc_fops)) + &xqmstat_proc_fops)) goto out_remove_stat_file; if (!proc_create("fs/xfs/xqm", 0, NULL, - &xqm_proc_fops)) + &xqm_proc_fops)) goto out_remove_xqmstat_file; #endif return 0; #ifdef CONFIG_XFS_QUOTA -out_remove_xqmstat_file: + out_remove_xqmstat_file: remove_proc_entry("fs/xfs/xqmstat", NULL); -out_remove_stat_file: + out_remove_stat_file: remove_proc_entry("fs/xfs/stat", NULL); #endif -out_remove_xfs_dir: + out_remove_xfs_dir: remove_proc_entry("fs/xfs", NULL); -out: + out: return -ENOMEM; } diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index 672fe83..00afc13 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -218,13 +218,16 @@ int xfs_stats_format(struct xfsstats __percpu *stats, char *buf); void xfs_stats_clearall(struct xfsstats __percpu *stats); extern struct xstats xfsstats; +struct xfs_mount; + /* * We don't disable preempt, not too worried about poking the * wrong CPU's stat for now (also aggregated before reporting). */ #define XFS_STATS_INC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v++) #define XFS_STATS_DEC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v--) -#define XFS_STATS_ADD(v, inc) (per_cpu(*xfsstats.xs_stats, current_cpu()).v += (inc)) +#define XFS_STATS_ADD(v, inc) (per_cpu(*xfsstats.xs_stats, current_cpu()).v \ + += (inc)) extern int xfs_init_procfs(void); extern void xfs_cleanup_procfs(void); diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 23e5681..3898643 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1801,7 +1801,6 @@ xfs_destroy_workqueues(void) destroy_workqueue(xfs_alloc_wq); } - STATIC int __init init_xfs_fs(void) { @@ -1843,17 +1842,26 @@ init_xfs_fs(void) } xfsstats.xs_stats = alloc_percpu(struct xfsstats); + if (!xfsstats.xs_stats) { + error = -ENOMEM; + goto out_kset_unregister; + } xfsstats.xs_kobj.kobject.kset = xfs_kset; + if (!xfsstats.xs_kobj.kobject.kset) { + error = -ENOMEM; + goto out_free_stats; + } + error = xfs_sysfs_init(&xfsstats.xs_kobj, &xfs_stats_ktype, NULL, - "stats"); + "stats"); if (error) - goto out_kset_unregister; + goto out_free_stats; #ifdef DEBUG xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_remove_stats; + goto out_del_stats; #endif error = xfs_qm_init(); @@ -1870,8 +1878,10 @@ init_xfs_fs(void) out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_remove_stats: + out_del_stats: #endif + xfs_sysfs_del(&xfsstats.xs_kobj); + out_free_stats: free_percpu(xfsstats.xs_stats); out_kset_unregister: kset_unregister(xfs_kset); @@ -1899,6 +1909,7 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif + xfs_sysfs_del(&xfsstats.xs_kobj); free_percpu(xfsstats.xs_stats); kset_unregister(xfs_kset); xfs_sysctl_unregister(); diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index 3275408..a6bc433 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -143,9 +143,9 @@ to_xstats(struct kobject *kobject) STATIC ssize_t stats_show( struct kobject *kobject, - char *buf) + char *buf) { - struct xstats *stats = to_xstats(kobject); + struct xstats *stats = to_xstats(kobject); return xfs_stats_format(stats->xs_stats, buf); } @@ -159,7 +159,7 @@ stats_clear_store( { int ret; int val; - struct xstats *stats = to_xstats(kobject); + struct xstats *stats = to_xstats(kobject); ret = kstrtoint(buf, 0, &val); if (ret) -- 2.4.3 From billodo@redhat.com Fri Sep 25 18:23:52 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id B69637F69 for ; Fri, 25 Sep 2015 18:23:52 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 6A74C304053 for ; Fri, 25 Sep 2015 16:23:52 -0700 (PDT) X-ASG-Debug-ID: 1443223396-04bdf04627ea2f0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id FQKD1gx6DrtHcjfx (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 16:23:16 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 242F3AD030 for ; Fri, 25 Sep 2015 23:23:16 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-243.rdu2.redhat.com [10.10.55.243]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PNNBp5021662 for ; Fri, 25 Sep 2015 19:23:15 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 5/7] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. Date: Fri, 25 Sep 2015 18:22:58 -0500 X-ASG-Orig-Subj: [PATCH 5/7] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. Message-Id: <1443223380-18870-6-git-send-email-billodo@redhat.com> In-Reply-To: <1443223380-18870-1-git-send-email-billodo@redhat.com> References: <1443223380-18870-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443223396 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 0 This patch is the next step toward per-fs xfs stats. Allocate & deallocate per-fs stats structures and set up the sysfs entries for them. Instead of a single global xfsstats structure, add kobject and a pointer to a per-cpu struct xfsstats. Modify the macros that manipulate the stats accordingly: XFS_STATS_INC, XFS_STATS_DEC, and XFS_STATS_ADD now access xfsstats->xs_stats. The sysfs functions need to get from the kobject back to the xfsstats structure which contains it, and pass the pointer to the ->xs_stats percpu structure into the show & clear routines. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_linux.h | 7 +++++++ fs/xfs/xfs_stats.c | 47 ++++++++++++++++++++++++----------------------- fs/xfs/xfs_stats.h | 13 ++++++------- fs/xfs/xfs_super.c | 15 ++++++++------- fs/xfs/xfs_sysctl.c | 2 +- fs/xfs/xfs_sysfs.c | 17 +++++++++++++++-- 6 files changed, 61 insertions(+), 40 deletions(-) diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h index 85f883d..f1a8505 100644 --- a/fs/xfs/xfs_linux.h +++ b/fs/xfs/xfs_linux.h @@ -171,6 +171,13 @@ struct xfs_kobj { struct completion complete; }; +struct xstats { + struct xfsstats __percpu *xs_stats; + struct xfs_kobj xs_kobj; +}; + +extern struct xstats xfsstats; + /* Kernel uid/gid conversion. These are used to convert to/from the on disk * uid_t/gid_t types to the kuid_t/kgid_t types that the kernel uses internally. * The conversion here is type only, the value will remain the same since we diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index dc6ca67..ab79973 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -18,18 +18,18 @@ #include "xfs.h" #include -DEFINE_PER_CPU(struct xfsstats, xfsstats); +struct xstats xfsstats; -static int counter_val(int idx) +static int counter_val(struct xfsstats __percpu *stats, int idx) { int val = 0, cpu; for_each_possible_cpu(cpu) - val += *(((__u32 *)&per_cpu(xfsstats, cpu) + idx)); + val += *(((__u32 *)&per_cpu(*stats, cpu) + idx)); return val; } -int xfs_stats_format(char *buf) +int xfs_stats_format(struct xfsstats __percpu *stats, char *buf) { int i, j; int len = 0; @@ -73,14 +73,14 @@ int xfs_stats_format(char *buf) /* inner loop does each group */ for (; j < xstats[i].endpoint; j++) len += snprintf(buf + len, PATH_MAX - len, " %u", - counter_val(j)); + counter_val(stats, j)); len += snprintf(buf + len, PATH_MAX - len, "\n"); } /* extra precision counters */ for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; + xs_xstrat_bytes += per_cpu(*stats, i).xs_xstrat_bytes; + xs_write_bytes += per_cpu(*stats, i).xs_write_bytes; + xs_read_bytes += per_cpu(*stats, i).xs_read_bytes; } len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", @@ -95,7 +95,7 @@ int xfs_stats_format(char *buf) return len; } -void xfs_stats_clearall(void) +void xfs_stats_clearall(struct xfsstats __percpu *stats) { int c; __uint32_t vn_active; @@ -104,10 +104,10 @@ void xfs_stats_clearall(void) for_each_possible_cpu(c) { preempt_disable(); /* save vn_active, it's a universal truth! */ - vn_active = per_cpu(xfsstats, c).vn_active; - memset(&per_cpu(xfsstats, c), 0, - sizeof(struct xfsstats)); - per_cpu(xfsstats, c).vn_active = vn_active; + vn_active = per_cpu(*stats, c).vn_active; + memset(&per_cpu(*stats, c), 0, + sizeof(*stats)); + per_cpu(*stats, c).vn_active = vn_active; preempt_enable(); } } @@ -119,9 +119,10 @@ static int xqm_proc_show(struct seq_file *m, void *v) /* maximum; incore; ratio free to inuse; freelist */ seq_printf(m, "%d\t%d\t%d\t%u\n", 0, - counter_val(XFSSTAT_END_XQMSTAT), + counter_val(xfsstats.xs_stats, XFSSTAT_END_XQMSTAT), 0, - counter_val(XFSSTAT_END_XQMSTAT + 1)); + counter_val(xfsstats.xs_stats, + XFSSTAT_END_XQMSTAT + 1)); return 0; } @@ -145,7 +146,7 @@ static int xqmstat_proc_show(struct seq_file *m, void *v) seq_printf(m, "qm"); for (j = XFSSTAT_END_IBT_V2; j < XFSSTAT_END_XQMSTAT; j++) - seq_printf(m, " %u", counter_val(j)); + seq_printf(m, " %u", counter_val(xfsstats.xs_stats, j)); seq_putc(m, '\n'); return 0; } @@ -171,28 +172,28 @@ xfs_init_procfs(void) goto out; if (!proc_symlink("fs/xfs/stat", NULL, - "/sys/fs/xfs/stats/stats")) + "/sys/fs/xfs/stats/stats")) goto out_remove_xfs_dir; #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, - &xqmstat_proc_fops)) + &xqmstat_proc_fops)) goto out_remove_stat_file; if (!proc_create("fs/xfs/xqm", 0, NULL, - &xqm_proc_fops)) + &xqm_proc_fops)) goto out_remove_xqmstat_file; #endif return 0; #ifdef CONFIG_XFS_QUOTA - out_remove_xqmstat_file: +out_remove_xqmstat_file: remove_proc_entry("fs/xfs/xqmstat", NULL); - out_remove_stat_file: +out_remove_stat_file: remove_proc_entry("fs/xfs/stat", NULL); #endif - out_remove_xfs_dir: +out_remove_xfs_dir: remove_proc_entry("fs/xfs", NULL); - out: +out: return -ENOMEM; } diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index 18807b5..672fe83 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -18,9 +18,6 @@ #ifndef __XFS_STATS_H__ #define __XFS_STATS_H__ -int xfs_stats_format(char *buf); -void xfs_stats_clearall(void); - #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) #include @@ -217,15 +214,17 @@ struct xfsstats { __uint64_t xs_read_bytes; }; -DECLARE_PER_CPU(struct xfsstats, xfsstats); +int xfs_stats_format(struct xfsstats __percpu *stats, char *buf); +void xfs_stats_clearall(struct xfsstats __percpu *stats); +extern struct xstats xfsstats; /* * We don't disable preempt, not too worried about poking the * wrong CPU's stat for now (also aggregated before reporting). */ -#define XFS_STATS_INC(v) (per_cpu(xfsstats, current_cpu()).v++) -#define XFS_STATS_DEC(v) (per_cpu(xfsstats, current_cpu()).v--) -#define XFS_STATS_ADD(v, inc) (per_cpu(xfsstats, current_cpu()).v += (inc)) +#define XFS_STATS_INC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v++) +#define XFS_STATS_DEC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v--) +#define XFS_STATS_ADD(v, inc) (per_cpu(*xfsstats.xs_stats, current_cpu()).v += (inc)) extern int xfs_init_procfs(void); extern void xfs_cleanup_procfs(void); diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 0dfc53b..23e5681 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -61,7 +61,6 @@ static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; static struct kset *xfs_kset; /* top-level xfs sysfs dir */ -static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ #ifdef DEBUG static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ #endif @@ -1802,6 +1801,7 @@ xfs_destroy_workqueues(void) destroy_workqueue(xfs_alloc_wq); } + STATIC int __init init_xfs_fs(void) { @@ -1842,8 +1842,9 @@ init_xfs_fs(void) goto out_sysctl_unregister; } - xfs_stats_kobj.kobject.kset = xfs_kset; - error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, + xfsstats.xs_stats = alloc_percpu(struct xfsstats); + xfsstats.xs_kobj.kobject.kset = xfs_kset; + error = xfs_sysfs_init(&xfsstats.xs_kobj, &xfs_stats_ktype, NULL, "stats"); if (error) goto out_kset_unregister; @@ -1852,7 +1853,7 @@ init_xfs_fs(void) xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_remove_stats_kobj; + goto out_remove_stats; #endif error = xfs_qm_init(); @@ -1869,9 +1870,9 @@ init_xfs_fs(void) out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_remove_stats_kobj: + out_remove_stats: #endif - xfs_sysfs_del(&xfs_stats_kobj); + free_percpu(xfsstats.xs_stats); out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: @@ -1898,7 +1899,7 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif - xfs_sysfs_del(&xfs_stats_kobj); + free_percpu(xfsstats.xs_stats); kset_unregister(xfs_kset); xfs_sysctl_unregister(); xfs_cleanup_procfs(); diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c index 5defabb..aed74d3 100644 --- a/fs/xfs/xfs_sysctl.c +++ b/fs/xfs/xfs_sysctl.c @@ -37,7 +37,7 @@ xfs_stats_clear_proc_handler( ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); if (!ret && write && *valp) { - xfs_stats_clearall(); + xfs_stats_clearall(xfsstats.xs_stats); xfs_stats_clear = 0; } diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index ab4850b..3275408 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -131,12 +131,23 @@ struct kobj_type xfs_dbg_ktype = { /* stats */ +static inline struct xstats * +to_xstats(struct kobject *kobject) +{ + struct xfs_kobj *kobj = to_kobj(kobject); + + return container_of(kobj, struct xstats, xs_kobj); +} + + STATIC ssize_t stats_show( struct kobject *kobject, char *buf) { - return xfs_stats_format(buf); + struct xstats *stats = to_xstats(kobject); + + return xfs_stats_format(stats->xs_stats, buf); } XFS_SYSFS_ATTR_RO(stats); @@ -148,6 +159,7 @@ stats_clear_store( { int ret; int val; + struct xstats *stats = to_xstats(kobject); ret = kstrtoint(buf, 0, &val); if (ret) @@ -155,7 +167,8 @@ stats_clear_store( if (val != 1) return -EINVAL; - xfs_stats_clearall(); + + xfs_stats_clearall(stats->xs_stats); return count; } XFS_SYSFS_ATTR_WO(stats_clear); -- 2.4.3 From billodo@redhat.com Fri Sep 25 18:23:54 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 1C3587F72 for ; Fri, 25 Sep 2015 18:23:54 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id EF6308F8049 for ; Fri, 25 Sep 2015 16:23:53 -0700 (PDT) X-ASG-Debug-ID: 1443223400-04cb6c6b05e6080001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Nmoch1M6DC1rJSlg (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Sep 2015 16:23:20 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 2DE2CA0BAC for ; Fri, 25 Sep 2015 23:23:20 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-243.rdu2.redhat.com [10.10.55.243]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PNNBp7021662 for ; Fri, 25 Sep 2015 19:23:19 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 7/7] xfs: per-filesystem stats counter implementation Date: Fri, 25 Sep 2015 18:23:00 -0500 X-ASG-Orig-Subj: [PATCH 7/7] xfs: per-filesystem stats counter implementation Message-Id: <1443223380-18870-8-git-send-email-billodo@redhat.com> In-Reply-To: <1443223380-18870-1-git-send-email-billodo@redhat.com> References: <1443223380-18870-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443223400 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 0 This patch modifies the stats counting macros and the callers to those macros to properly increment, decrement, and add-to the xfs stats counts. The counts for global and per-fs stats are correctly advanced, and cleared by writing a "1" to the corresponding clear file. global counts: /sys/fs/xfs/stats/stats per-fs counts: /sys/fs/xfs/sda*/stats/stats global clear: /sys/fs/xfs/stats/stats_clear per-fs clear: /sys/fs/xfs/sda*/stats/stats_clear Signed-off-by: Bill O'Donnell --- fs/xfs/libxfs/xfs_alloc.c | 8 ++++---- fs/xfs/libxfs/xfs_attr.c | 6 +++--- fs/xfs/libxfs/xfs_bmap.c | 20 ++++++++++---------- fs/xfs/libxfs/xfs_btree.h | 21 +++++++++++---------- fs/xfs/libxfs/xfs_dir2.c | 6 +++--- fs/xfs/xfs_attr_list.c | 2 +- fs/xfs/xfs_buf.c | 18 +++++++++--------- fs/xfs/xfs_dir2_readdir.c | 2 +- fs/xfs/xfs_dquot.c | 12 ++++++------ fs/xfs/xfs_file.c | 12 ++++++------ fs/xfs/xfs_icache.c | 18 +++++++++--------- fs/xfs/xfs_inode.c | 6 +++--- fs/xfs/xfs_ioctl.c | 2 +- fs/xfs/xfs_iomap.c | 4 ++-- fs/xfs/xfs_iops.c | 4 ++-- fs/xfs/xfs_log.c | 22 +++++++++++----------- fs/xfs/xfs_qm.c | 14 +++++++------- fs/xfs/xfs_stats.c | 8 +++----- fs/xfs/xfs_stats.h | 23 +++++++++++++++++++---- fs/xfs/xfs_super.c | 6 +++--- fs/xfs/xfs_trans.c | 6 +++--- fs/xfs/xfs_trans_ail.c | 12 ++++++------ 22 files changed, 123 insertions(+), 109 deletions(-) diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c index ffad7f2..9b5da7e3 100644 --- a/fs/xfs/libxfs/xfs_alloc.c +++ b/fs/xfs/libxfs/xfs_alloc.c @@ -651,8 +651,8 @@ xfs_alloc_ag_vextent( -((long)(args->len))); } - XFS_STATS_INC(xs_allocx); - XFS_STATS_ADD(xs_allocb, args->len); + XFS_STATS_INC(args->mp, xs_allocx); + XFS_STATS_ADD(args->mp, xs_allocb, args->len); return error; } @@ -1808,8 +1808,8 @@ xfs_free_ag_extent( if (!isfl) xfs_trans_mod_sb(tp, XFS_TRANS_SB_FDBLOCKS, (long)len); - XFS_STATS_INC(xs_freex); - XFS_STATS_ADD(xs_freeb, len); + XFS_STATS_INC(mp, xs_freex); + XFS_STATS_ADD(mp, xs_freeb, len); trace_xfs_free_extent(mp, agno, bno, len, isfl, haveleft, haveright); diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c index ff06557..f949818 100644 --- a/fs/xfs/libxfs/xfs_attr.c +++ b/fs/xfs/libxfs/xfs_attr.c @@ -125,7 +125,7 @@ xfs_attr_get( uint lock_mode; int error; - XFS_STATS_INC(xs_attr_get); + XFS_STATS_INC(ip->i_mount, xs_attr_get); if (XFS_FORCED_SHUTDOWN(ip->i_mount)) return -EIO; @@ -209,7 +209,7 @@ xfs_attr_set( int rsvd = (flags & ATTR_ROOT) != 0; int error, err2, committed, local; - XFS_STATS_INC(xs_attr_set); + XFS_STATS_INC(mp, xs_attr_set); if (XFS_FORCED_SHUTDOWN(dp->i_mount)) return -EIO; @@ -412,7 +412,7 @@ xfs_attr_remove( xfs_fsblock_t firstblock; int error; - XFS_STATS_INC(xs_attr_remove); + XFS_STATS_INC(mp, xs_attr_remove); if (XFS_FORCED_SHUTDOWN(dp->i_mount)) return -EIO; diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c index 8e2010d..5256fe5 100644 --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -1435,7 +1435,7 @@ xfs_bmap_search_extents( xfs_ifork_t *ifp; /* inode fork pointer */ xfs_bmbt_rec_host_t *ep; /* extent record pointer */ - XFS_STATS_INC(xs_look_exlist); + XFS_STATS_INC(ip->i_mount, xs_look_exlist); ifp = XFS_IFORK_PTR(ip, fork); ep = xfs_bmap_search_multi_extents(ifp, bno, eofp, lastxp, gotp, prevp); @@ -1732,7 +1732,7 @@ xfs_bmap_add_extent_delay_real( ASSERT(!bma->cur || (bma->cur->bc_private.b.flags & XFS_BTCUR_BPRV_WASDEL)); - XFS_STATS_INC(xs_add_exlist); + XFS_STATS_INC(mp, xs_add_exlist); #define LEFT r[0] #define RIGHT r[1] @@ -2286,7 +2286,7 @@ xfs_bmap_add_extent_unwritten_real( ASSERT(*idx <= ifp->if_bytes / sizeof(struct xfs_bmbt_rec)); ASSERT(!isnullstartblock(new->br_startblock)); - XFS_STATS_INC(xs_add_exlist); + XFS_STATS_INC(mp, xs_add_exlist); #define LEFT r[0] #define RIGHT r[1] @@ -2946,7 +2946,7 @@ xfs_bmap_add_extent_hole_real( ASSERT(!bma->cur || !(bma->cur->bc_private.b.flags & XFS_BTCUR_BPRV_WASDEL)); - XFS_STATS_INC(xs_add_exlist); + XFS_STATS_INC(mp, xs_add_exlist); state = 0; if (whichfork == XFS_ATTR_FORK) @@ -4036,7 +4036,7 @@ xfs_bmapi_read( if (XFS_FORCED_SHUTDOWN(mp)) return -EIO; - XFS_STATS_INC(xs_blk_mapr); + XFS_STATS_INC(mp, xs_blk_mapr); ifp = XFS_IFORK_PTR(ip, whichfork); @@ -4221,7 +4221,7 @@ xfs_bmapi_delay( if (XFS_FORCED_SHUTDOWN(mp)) return -EIO; - XFS_STATS_INC(xs_blk_mapw); + XFS_STATS_INC(mp, xs_blk_mapw); if (!(ifp->if_flags & XFS_IFEXTENTS)) { error = xfs_iread_extents(NULL, ip, XFS_DATA_FORK); @@ -4525,7 +4525,7 @@ xfs_bmapi_write( ifp = XFS_IFORK_PTR(ip, whichfork); - XFS_STATS_INC(xs_blk_mapw); + XFS_STATS_INC(mp, xs_blk_mapw); if (*firstblock == NULLFSBLOCK) { if (XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_BTREE) @@ -4718,12 +4718,12 @@ xfs_bmap_del_extent( xfs_filblks_t temp2; /* for indirect length calculations */ int state = 0; - XFS_STATS_INC(xs_del_exlist); + mp = ip->i_mount; + XFS_STATS_INC(mp, xs_del_exlist); if (whichfork == XFS_ATTR_FORK) state |= BMAP_ATTRFORK; - mp = ip->i_mount; ifp = XFS_IFORK_PTR(ip, whichfork); ASSERT((*idx >= 0) && (*idx < ifp->if_bytes / (uint)sizeof(xfs_bmbt_rec_t))); @@ -5070,7 +5070,7 @@ xfs_bunmapi( *done = 1; return 0; } - XFS_STATS_INC(xs_blk_unmap); + XFS_STATS_INC(mp, xs_blk_unmap); isrt = (whichfork == XFS_DATA_FORK) && XFS_IS_REALTIME_INODE(ip); start = bno; bno = start + len - 1; diff --git a/fs/xfs/libxfs/xfs_btree.h b/fs/xfs/libxfs/xfs_btree.h index 8f18bab..e42d969 100644 --- a/fs/xfs/libxfs/xfs_btree.h +++ b/fs/xfs/libxfs/xfs_btree.h @@ -84,22 +84,23 @@ union xfs_btree_rec { /* * Generic stats interface */ -#define __XFS_BTREE_STATS_INC(type, stat) \ - XFS_STATS_INC(xs_ ## type ## _2_ ## stat) -#define XFS_BTREE_STATS_INC(cur, stat) \ +#define __XFS_BTREE_STATS_INC(mp, type, stat) \ + XFS_STATS_INC(mp, xs_ ## type ## _2_ ## stat) +#define XFS_BTREE_STATS_INC(cur, stat) \ do { \ + struct xfs_mount *mp = cur->bc_mp; \ switch (cur->bc_btnum) { \ - case XFS_BTNUM_BNO: __XFS_BTREE_STATS_INC(abtb, stat); break; \ - case XFS_BTNUM_CNT: __XFS_BTREE_STATS_INC(abtc, stat); break; \ - case XFS_BTNUM_BMAP: __XFS_BTREE_STATS_INC(bmbt, stat); break; \ - case XFS_BTNUM_INO: __XFS_BTREE_STATS_INC(ibt, stat); break; \ - case XFS_BTNUM_FINO: __XFS_BTREE_STATS_INC(fibt, stat); break; \ + case XFS_BTNUM_BNO: __XFS_BTREE_STATS_INC(mp, abtb, stat); break; \ + case XFS_BTNUM_CNT: __XFS_BTREE_STATS_INC(mp, abtc, stat); break; \ + case XFS_BTNUM_BMAP: __XFS_BTREE_STATS_INC(mp, bmbt, stat); break; \ + case XFS_BTNUM_INO: __XFS_BTREE_STATS_INC(mp, ibt, stat); break; \ + case XFS_BTNUM_FINO: __XFS_BTREE_STATS_INC(mp, fibt, stat); break; \ case XFS_BTNUM_MAX: ASSERT(0); /* fucking gcc */ ; break; \ } \ } while (0) #define __XFS_BTREE_STATS_ADD(type, stat, val) \ - XFS_STATS_ADD(xs_ ## type ## _2_ ## stat, val) + XFS_STATS_ADD(cur->bc_mp, xs_ ## type ## _2_ ## stat, val) #define XFS_BTREE_STATS_ADD(cur, stat, val) \ do { \ switch (cur->bc_btnum) { \ @@ -108,7 +109,7 @@ do { \ case XFS_BTNUM_BMAP: __XFS_BTREE_STATS_ADD(bmbt, stat, val); break; \ case XFS_BTNUM_INO: __XFS_BTREE_STATS_ADD(ibt, stat, val); break; \ case XFS_BTNUM_FINO: __XFS_BTREE_STATS_ADD(fibt, stat, val); break; \ - case XFS_BTNUM_MAX: ASSERT(0); /* fucking gcc */ ; break; \ + case XFS_BTNUM_MAX: ASSERT(0); /* fucking gcc */ ; break; \ } \ } while (0) diff --git a/fs/xfs/libxfs/xfs_dir2.c b/fs/xfs/libxfs/xfs_dir2.c index 9de401d..2fb53a5 100644 --- a/fs/xfs/libxfs/xfs_dir2.c +++ b/fs/xfs/libxfs/xfs_dir2.c @@ -271,7 +271,7 @@ xfs_dir_createname( rval = xfs_dir_ino_validate(tp->t_mountp, inum); if (rval) return rval; - XFS_STATS_INC(xs_dir_create); + XFS_STATS_INC(dp->i_mount, xs_dir_create); } args = kmem_zalloc(sizeof(*args), KM_SLEEP | KM_NOFS); @@ -365,7 +365,7 @@ xfs_dir_lookup( int lock_mode; ASSERT(S_ISDIR(dp->i_d.di_mode)); - XFS_STATS_INC(xs_dir_lookup); + XFS_STATS_INC(dp->i_mount, xs_dir_lookup); /* * We need to use KM_NOFS here so that lockdep will not throw false @@ -444,7 +444,7 @@ xfs_dir_removename( int v; /* type-checking value */ ASSERT(S_ISDIR(dp->i_d.di_mode)); - XFS_STATS_INC(xs_dir_remove); + XFS_STATS_INC(dp->i_mount, xs_dir_remove); args = kmem_zalloc(sizeof(*args), KM_SLEEP | KM_NOFS); if (!args) diff --git a/fs/xfs/xfs_attr_list.c b/fs/xfs/xfs_attr_list.c index 65fb37a..0ef7c2e 100644 --- a/fs/xfs/xfs_attr_list.c +++ b/fs/xfs/xfs_attr_list.c @@ -511,7 +511,7 @@ xfs_attr_list_int( xfs_inode_t *dp = context->dp; uint lock_mode; - XFS_STATS_INC(xs_attr_list); + XFS_STATS_INC(dp->i_mount, xs_attr_list); if (XFS_FORCED_SHUTDOWN(dp->i_mount)) return -EIO; diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index 8ecffb3..90815c2 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -201,7 +201,7 @@ _xfs_buf_alloc( atomic_set(&bp->b_pin_count, 0); init_waitqueue_head(&bp->b_waiters); - XFS_STATS_INC(xb_create); + XFS_STATS_INC(target->bt_mount, xb_create); trace_xfs_buf_init(bp, _RET_IP_); return bp; @@ -357,12 +357,12 @@ retry: "possible memory allocation deadlock in %s (mode:0x%x)", __func__, gfp_mask); - XFS_STATS_INC(xb_page_retries); + XFS_STATS_INC(bp->b_target->bt_mount, xb_page_retries); congestion_wait(BLK_RW_ASYNC, HZ/50); goto retry; } - XFS_STATS_INC(xb_page_found); + XFS_STATS_INC(bp->b_target->bt_mount, xb_page_found); nbytes = min_t(size_t, size, PAGE_SIZE - offset); size -= nbytes; @@ -516,7 +516,7 @@ _xfs_buf_find( new_bp->b_pag = pag; spin_unlock(&pag->pag_buf_lock); } else { - XFS_STATS_INC(xb_miss_locked); + XFS_STATS_INC(btp->bt_mount, xb_miss_locked); spin_unlock(&pag->pag_buf_lock); xfs_perag_put(pag); } @@ -529,11 +529,11 @@ found: if (!xfs_buf_trylock(bp)) { if (flags & XBF_TRYLOCK) { xfs_buf_rele(bp); - XFS_STATS_INC(xb_busy_locked); + XFS_STATS_INC(btp->bt_mount, xb_busy_locked); return NULL; } xfs_buf_lock(bp); - XFS_STATS_INC(xb_get_locked_waited); + XFS_STATS_INC(btp->bt_mount, xb_get_locked_waited); } /* @@ -549,7 +549,7 @@ found: } trace_xfs_buf_find(bp, flags, _RET_IP_); - XFS_STATS_INC(xb_get_locked); + XFS_STATS_INC(btp->bt_mount, xb_get_locked); return bp; } @@ -603,7 +603,7 @@ found: } } - XFS_STATS_INC(xb_get); + XFS_STATS_INC(target->bt_mount, xb_get); trace_xfs_buf_get(bp, flags, _RET_IP_); return bp; } @@ -643,7 +643,7 @@ xfs_buf_read_map( trace_xfs_buf_read(bp, flags, _RET_IP_); if (!XFS_BUF_ISDONE(bp)) { - XFS_STATS_INC(xb_get_read); + XFS_STATS_INC(target->bt_mount, xb_get_read); bp->b_ops = ops; _xfs_buf_read(bp, flags); } else if (flags & XBF_ASYNC) { diff --git a/fs/xfs/xfs_dir2_readdir.c b/fs/xfs/xfs_dir2_readdir.c index a989a9c..642d55d 100644 --- a/fs/xfs/xfs_dir2_readdir.c +++ b/fs/xfs/xfs_dir2_readdir.c @@ -666,7 +666,7 @@ xfs_readdir( return -EIO; ASSERT(S_ISDIR(dp->i_d.di_mode)); - XFS_STATS_INC(xs_dir_getdents); + XFS_STATS_INC(dp->i_mount, xs_dir_getdents); args.dp = dp; args.geo = dp->i_mount->m_dir_geo; diff --git a/fs/xfs/xfs_dquot.c b/fs/xfs/xfs_dquot.c index 30cb3af..c801a0b 100644 --- a/fs/xfs/xfs_dquot.c +++ b/fs/xfs/xfs_dquot.c @@ -77,7 +77,7 @@ xfs_qm_dqdestroy( mutex_destroy(&dqp->q_qlock); kmem_zone_free(xfs_qm_dqzone, dqp); - XFS_STATS_DEC(xs_qm_dquot); + XFS_STATS_DEC(dqp->q_mount, xs_qm_dquot); } /* @@ -605,7 +605,7 @@ xfs_qm_dqread( break; } - XFS_STATS_INC(xs_qm_dquot); + XFS_STATS_INC(dqp->q_mount, xs_qm_dquot); trace_xfs_dqread(dqp); @@ -747,12 +747,12 @@ restart: mutex_unlock(&qi->qi_tree_lock); trace_xfs_dqget_hit(dqp); - XFS_STATS_INC(xs_qm_dqcachehits); + XFS_STATS_INC(dqp->q_mount, xs_qm_dqcachehits); *O_dqpp = dqp; return 0; } mutex_unlock(&qi->qi_tree_lock); - XFS_STATS_INC(xs_qm_dqcachemisses); + XFS_STATS_INC(dqp->q_mount, xs_qm_dqcachemisses); /* * Dquot cache miss. We don't want to keep the inode lock across @@ -806,7 +806,7 @@ restart: mutex_unlock(&qi->qi_tree_lock); trace_xfs_dqget_dup(dqp); xfs_qm_dqdestroy(dqp); - XFS_STATS_INC(xs_qm_dquot_dups); + XFS_STATS_INC(dqp->q_mount, xs_qm_dquot_dups); goto restart; } @@ -846,7 +846,7 @@ xfs_qm_dqput( trace_xfs_dqput_free(dqp); if (list_lru_add(&qi->qi_lru, &dqp->q_lru)) - XFS_STATS_INC(xs_qm_dquot_unused); + XFS_STATS_INC(dqp->q_mount, xs_qm_dquot_unused); } xfs_dqunlock(dqp); } diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index e78feb4..088e509 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -287,7 +287,7 @@ xfs_file_read_iter( xfs_fsize_t n; loff_t pos = iocb->ki_pos; - XFS_STATS_INC(xs_read_calls); + XFS_STATS_INC(mp, xs_read_calls); if (unlikely(iocb->ki_flags & IOCB_DIRECT)) ioflags |= XFS_IO_ISDIRECT; @@ -365,7 +365,7 @@ xfs_file_read_iter( ret = generic_file_read_iter(iocb, to); if (ret > 0) - XFS_STATS_ADD(xs_read_bytes, ret); + XFS_STATS_ADD(mp, xs_read_bytes, ret); xfs_rw_iunlock(ip, XFS_IOLOCK_SHARED); return ret; @@ -383,7 +383,7 @@ xfs_file_splice_read( int ioflags = 0; ssize_t ret; - XFS_STATS_INC(xs_read_calls); + XFS_STATS_INC(ip->i_mount, xs_read_calls); if (infilp->f_mode & FMODE_NOCMTIME) ioflags |= XFS_IO_INVIS; @@ -401,7 +401,7 @@ xfs_file_splice_read( else ret = generic_file_splice_read(infilp, ppos, pipe, count, flags); if (ret > 0) - XFS_STATS_ADD(xs_read_bytes, ret); + XFS_STATS_ADD(ip->i_mount, xs_read_bytes, ret); xfs_rw_iunlock(ip, XFS_IOLOCK_SHARED); return ret; @@ -867,7 +867,7 @@ xfs_file_write_iter( ssize_t ret; size_t ocount = iov_iter_count(from); - XFS_STATS_INC(xs_write_calls); + XFS_STATS_INC(ip->i_mount, xs_write_calls); if (ocount == 0) return 0; @@ -883,7 +883,7 @@ xfs_file_write_iter( if (ret > 0) { ssize_t err; - XFS_STATS_ADD(xs_write_bytes, ret); + XFS_STATS_ADD(ip->i_mount, xs_write_bytes, ret); /* Handle various SYNC-type writes */ err = generic_write_sync(file, iocb->ki_pos - ret, ret); diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index 0a326bd..d7a490f 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -63,7 +63,7 @@ xfs_inode_alloc( return NULL; } - XFS_STATS_INC(vn_active); + XFS_STATS_INC(mp, vn_active); ASSERT(atomic_read(&ip->i_pincount) == 0); ASSERT(!spin_is_locked(&ip->i_flags_lock)); ASSERT(!xfs_isiflocked(ip)); @@ -129,7 +129,7 @@ xfs_inode_free( /* asserts to verify all state is correct here */ ASSERT(atomic_read(&ip->i_pincount) == 0); ASSERT(!xfs_isiflocked(ip)); - XFS_STATS_DEC(vn_active); + XFS_STATS_DEC(ip->i_mount, vn_active); call_rcu(&VFS_I(ip)->i_rcu, xfs_inode_free_callback); } @@ -159,7 +159,7 @@ xfs_iget_cache_hit( spin_lock(&ip->i_flags_lock); if (ip->i_ino != ino) { trace_xfs_iget_skip(ip); - XFS_STATS_INC(xs_ig_frecycle); + XFS_STATS_INC(mp, xs_ig_frecycle); error = -EAGAIN; goto out_error; } @@ -177,7 +177,7 @@ xfs_iget_cache_hit( */ if (ip->i_flags & (XFS_INEW|XFS_IRECLAIM)) { trace_xfs_iget_skip(ip); - XFS_STATS_INC(xs_ig_frecycle); + XFS_STATS_INC(mp, xs_ig_frecycle); error = -EAGAIN; goto out_error; } @@ -259,7 +259,7 @@ xfs_iget_cache_hit( xfs_ilock(ip, lock_flags); xfs_iflags_clear(ip, XFS_ISTALE | XFS_IDONTCACHE); - XFS_STATS_INC(xs_ig_found); + XFS_STATS_INC(mp, xs_ig_found); return 0; @@ -342,7 +342,7 @@ xfs_iget_cache_miss( error = radix_tree_insert(&pag->pag_ici_root, agino, ip); if (unlikely(error)) { WARN_ON(error != -EEXIST); - XFS_STATS_INC(xs_ig_dup); + XFS_STATS_INC(mp, xs_ig_dup); error = -EAGAIN; goto out_preload_end; } @@ -412,7 +412,7 @@ xfs_iget( if (!ino || XFS_INO_TO_AGNO(mp, ino) >= mp->m_sb.sb_agcount) return -EINVAL; - XFS_STATS_INC(xs_ig_attempts); + XFS_STATS_INC(mp, xs_ig_attempts); /* get the perag structure and ensure that it's inode capable */ pag = xfs_perag_get(mp, XFS_INO_TO_AGNO(mp, ino)); @@ -429,7 +429,7 @@ again: goto out_error_or_again; } else { rcu_read_unlock(); - XFS_STATS_INC(xs_ig_missed); + XFS_STATS_INC(mp, xs_ig_missed); error = xfs_iget_cache_miss(mp, pag, tp, ino, &ip, flags, lock_flags); @@ -965,7 +965,7 @@ reclaim: xfs_ifunlock(ip); xfs_iunlock(ip, XFS_ILOCK_EXCL); - XFS_STATS_INC(xs_ig_reclaims); + XFS_STATS_INC(ip->i_mount, xs_ig_reclaims); /* * Remove the inode from the per-AG radix tree. * diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index dc40a6d..a0f2bae 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -3271,8 +3271,8 @@ xfs_iflush_cluster( } if (clcount) { - XFS_STATS_INC(xs_icluster_flushcnt); - XFS_STATS_ADD(xs_icluster_flushinode, clcount); + XFS_STATS_INC(mp, xs_icluster_flushcnt); + XFS_STATS_ADD(mp, xs_icluster_flushinode, clcount); } out_free: @@ -3345,7 +3345,7 @@ xfs_iflush( struct xfs_dinode *dip; int error; - XFS_STATS_INC(xs_iflush_count); + XFS_STATS_INC(mp, xs_iflush_count); ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)); ASSERT(xfs_isiflocked(ip)); diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c index ea7d85a..b67a130 100644 --- a/fs/xfs/xfs_ioctl.c +++ b/fs/xfs/xfs_ioctl.c @@ -1028,7 +1028,7 @@ xfs_ioctl_setattr_xflags( xfs_diflags_to_linux(ip); xfs_trans_ichgtime(tp, ip, XFS_ICHGTIME_CHG); xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - XFS_STATS_INC(xs_ig_attrchg); + XFS_STATS_INC(mp, xs_ig_attrchg); return 0; } diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 1f86033..dca69c6 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -670,7 +670,7 @@ xfs_iomap_write_allocate( count_fsb = imap->br_blockcount; map_start_fsb = imap->br_startoff; - XFS_STATS_ADD(xs_xstrat_bytes, XFS_FSB_TO_B(mp, count_fsb)); + XFS_STATS_ADD(mp, xs_xstrat_bytes, XFS_FSB_TO_B(mp, count_fsb)); while (count_fsb != 0) { /* @@ -777,7 +777,7 @@ xfs_iomap_write_allocate( if ((offset_fsb >= imap->br_startoff) && (offset_fsb < (imap->br_startoff + imap->br_blockcount))) { - XFS_STATS_INC(xs_xstrat_quick); + XFS_STATS_INC(mp, xs_xstrat_quick); return 0; } diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c index 8294132..245268a 100644 --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -695,7 +695,7 @@ xfs_setattr_nonsize( xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - XFS_STATS_INC(xs_ig_attrchg); + XFS_STATS_INC(mp, xs_ig_attrchg); if (mp->m_flags & XFS_MOUNT_WSYNC) xfs_trans_set_sync(tp); @@ -922,7 +922,7 @@ xfs_setattr_size( xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - XFS_STATS_INC(xs_ig_attrchg); + XFS_STATS_INC(mp, xs_ig_attrchg); if (mp->m_flags & XFS_MOUNT_WSYNC) xfs_trans_set_sync(tp); diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index aaadee0..4012523 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -268,7 +268,7 @@ xlog_grant_head_wait( __set_current_state(TASK_UNINTERRUPTIBLE); spin_unlock(&head->lock); - XFS_STATS_INC(xs_sleep_logspace); + XFS_STATS_INC(log->l_mp, xs_sleep_logspace); trace_xfs_log_grant_sleep(log, tic); schedule(); @@ -379,7 +379,7 @@ xfs_log_regrant( if (XLOG_FORCED_SHUTDOWN(log)) return -EIO; - XFS_STATS_INC(xs_try_logspace); + XFS_STATS_INC(mp, xs_try_logspace); /* * This is a new transaction on the ticket, so we need to change the @@ -448,7 +448,7 @@ xfs_log_reserve( if (XLOG_FORCED_SHUTDOWN(log)) return -EIO; - XFS_STATS_INC(xs_try_logspace); + XFS_STATS_INC(mp, xs_try_logspace); ASSERT(*ticp == NULL); tic = xlog_ticket_alloc(log, unit_bytes, cnt, client, permanent, @@ -1768,7 +1768,7 @@ xlog_sync( int v2 = xfs_sb_version_haslogv2(&log->l_mp->m_sb); int size; - XFS_STATS_INC(xs_log_writes); + XFS_STATS_INC(log->l_mp, xs_log_writes); ASSERT(atomic_read(&iclog->ic_refcnt) == 0); /* Add for LR header */ @@ -1805,7 +1805,7 @@ xlog_sync( bp = iclog->ic_bp; XFS_BUF_SET_ADDR(bp, BLOCK_LSN(be64_to_cpu(iclog->ic_header.h_lsn))); - XFS_STATS_ADD(xs_log_blocks, BTOBB(count)); + XFS_STATS_ADD(log->l_mp, xs_log_blocks, BTOBB(count)); /* Do we need to split this write into 2 parts? */ if (XFS_BUF_ADDR(bp) + BTOBB(count) > log->l_logBBsize) { @@ -2913,7 +2913,7 @@ restart: iclog = log->l_iclog; if (iclog->ic_state != XLOG_STATE_ACTIVE) { - XFS_STATS_INC(xs_log_noiclogs); + XFS_STATS_INC(log->l_mp, xs_log_noiclogs); /* Wait for log writes to have flushed */ xlog_wait(&log->l_flush_wait, &log->l_icloglock); @@ -3212,7 +3212,7 @@ _xfs_log_force( struct xlog_in_core *iclog; xfs_lsn_t lsn; - XFS_STATS_INC(xs_log_force); + XFS_STATS_INC(mp, xs_log_force); xlog_cil_force(log); @@ -3297,7 +3297,7 @@ maybe_sleep: spin_unlock(&log->l_icloglock); return -EIO; } - XFS_STATS_INC(xs_log_force_sleep); + XFS_STATS_INC(mp, xs_log_force_sleep); xlog_wait(&iclog->ic_force_wait, &log->l_icloglock); /* * No need to grab the log lock here since we're @@ -3362,7 +3362,7 @@ _xfs_log_force_lsn( ASSERT(lsn != 0); - XFS_STATS_INC(xs_log_force); + XFS_STATS_INC(mp, xs_log_force); lsn = xlog_cil_force_lsn(log, lsn); if (lsn == NULLCOMMITLSN) @@ -3411,7 +3411,7 @@ try_again: (XLOG_STATE_WANT_SYNC | XLOG_STATE_SYNCING))) { ASSERT(!(iclog->ic_state & XLOG_STATE_IOERROR)); - XFS_STATS_INC(xs_log_force_sleep); + XFS_STATS_INC(mp, xs_log_force_sleep); xlog_wait(&iclog->ic_prev->ic_write_wait, &log->l_icloglock); @@ -3441,7 +3441,7 @@ try_again: spin_unlock(&log->l_icloglock); return -EIO; } - XFS_STATS_INC(xs_log_force_sleep); + XFS_STATS_INC(mp, xs_log_force_sleep); xlog_wait(&iclog->ic_force_wait, &log->l_icloglock); /* * No need to grab the log lock here since we're diff --git a/fs/xfs/xfs_qm.c b/fs/xfs/xfs_qm.c index eac9549..7af7648 100644 --- a/fs/xfs/xfs_qm.c +++ b/fs/xfs/xfs_qm.c @@ -184,7 +184,7 @@ xfs_qm_dqpurge( */ ASSERT(!list_empty(&dqp->q_lru)); list_lru_del(&qi->qi_lru, &dqp->q_lru); - XFS_STATS_DEC(xs_qm_dquot_unused); + XFS_STATS_DEC(mp, xs_qm_dquot_unused); xfs_qm_dqdestroy(dqp); return 0; @@ -448,11 +448,11 @@ xfs_qm_dquot_isolate( */ if (dqp->q_nrefs) { xfs_dqunlock(dqp); - XFS_STATS_INC(xs_qm_dqwants); + XFS_STATS_INC(dqp->q_mount, xs_qm_dqwants); trace_xfs_dqreclaim_want(dqp); list_lru_isolate(lru, &dqp->q_lru); - XFS_STATS_DEC(xs_qm_dquot_unused); + XFS_STATS_DEC(dqp->q_mount, xs_qm_dquot_unused); return LRU_REMOVED; } @@ -496,19 +496,19 @@ xfs_qm_dquot_isolate( ASSERT(dqp->q_nrefs == 0); list_lru_isolate_move(lru, &dqp->q_lru, &isol->dispose); - XFS_STATS_DEC(xs_qm_dquot_unused); + XFS_STATS_DEC(dqp->q_mount, xs_qm_dquot_unused); trace_xfs_dqreclaim_done(dqp); - XFS_STATS_INC(xs_qm_dqreclaims); + XFS_STATS_INC(dqp->q_mount, xs_qm_dqreclaims); return LRU_REMOVED; out_miss_busy: trace_xfs_dqreclaim_busy(dqp); - XFS_STATS_INC(xs_qm_dqreclaim_misses); + XFS_STATS_INC(dqp->q_mount, xs_qm_dqreclaim_misses); return LRU_SKIP; out_unlock_dirty: trace_xfs_dqreclaim_busy(dqp); - XFS_STATS_INC(xs_qm_dqreclaim_misses); + XFS_STATS_INC(dqp->q_mount, xs_qm_dqreclaim_misses); xfs_dqunlock(dqp); spin_lock(lru_lock); return LRU_RETRY; diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index d5b3704..d3c8da3 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -122,11 +122,9 @@ static int xqm_proc_show(struct seq_file *m, void *v) { /* maximum; incore; ratio free to inuse; freelist */ seq_printf(m, "%d\t%d\t%d\t%u\n", - 0, - counter_val(xfsstats.xs_stats, XFSSTAT_END_XQMSTAT), - 0, - counter_val(xfsstats.xs_stats, - XFSSTAT_END_XQMSTAT + 1)); + 0, counter_val(xfsstats.xs_stats, XFSSTAT_END_XQMSTAT), + 0, counter_val(xfsstats.xs_stats, + XFSSTAT_END_XQMSTAT + 1)); return 0; } diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index 00afc13..7e84702 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -224,10 +224,25 @@ struct xfs_mount; * We don't disable preempt, not too worried about poking the * wrong CPU's stat for now (also aggregated before reporting). */ -#define XFS_STATS_INC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v++) -#define XFS_STATS_DEC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v--) -#define XFS_STATS_ADD(v, inc) (per_cpu(*xfsstats.xs_stats, current_cpu()).v \ - += (inc)) +#define XFS_STATS_INC(mp, v) { per_cpu_ptr(xfsstats.xs_stats, \ + current_cpu())->v++; \ + per_cpu_ptr( \ + mp->m_stats.xs_stats, \ + current_cpu())->v++; } + +#define XFS_STATS_DEC(mp, v) { per_cpu_ptr(xfsstats.xs_stats, \ + current_cpu())->v++; \ + per_cpu_ptr( \ + mp->m_stats.xs_stats, \ + current_cpu())->v--; } + +#define XFS_STATS_ADD(mp, v, inc) { per_cpu_ptr(xfsstats.xs_stats, \ + current_cpu())->v \ + += (inc); \ + per_cpu_ptr( \ + mp->m_stats.xs_stats, \ + current_cpu())->v \ + += (inc); } extern int xfs_init_procfs(void); extern void xfs_cleanup_procfs(void); diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 3898643..ae07a04 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -922,7 +922,7 @@ xfs_fs_destroy_inode( trace_xfs_destroy_inode(ip); - XFS_STATS_INC(vn_reclaim); + XFS_STATS_INC(ip->i_mount, vn_reclaim); ASSERT(XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0); @@ -983,8 +983,8 @@ xfs_fs_evict_inode( truncate_inode_pages_final(&inode->i_data); clear_inode(inode); - XFS_STATS_INC(vn_rele); - XFS_STATS_INC(vn_remove); + XFS_STATS_INC(ip->i_mount, vn_rele); + XFS_STATS_INC(ip->i_mount, vn_remove); xfs_inactive(ip); } diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c index a0ab1da..748b16a 100644 --- a/fs/xfs/xfs_trans.c +++ b/fs/xfs/xfs_trans.c @@ -930,9 +930,9 @@ __xfs_trans_commit( */ if (sync) { error = _xfs_log_force_lsn(mp, commit_lsn, XFS_LOG_SYNC, NULL); - XFS_STATS_INC(xs_trans_sync); + XFS_STATS_INC(mp, xs_trans_sync); } else { - XFS_STATS_INC(xs_trans_async); + XFS_STATS_INC(mp, xs_trans_async); } return error; @@ -955,7 +955,7 @@ out_unreserve: xfs_trans_free_items(tp, NULLCOMMITLSN, !!error); xfs_trans_free(tp); - XFS_STATS_INC(xs_trans_empty); + XFS_STATS_INC(mp, xs_trans_empty); return error; } diff --git a/fs/xfs/xfs_trans_ail.c b/fs/xfs/xfs_trans_ail.c index 1098cf4..4f18fd9 100644 --- a/fs/xfs/xfs_trans_ail.c +++ b/fs/xfs/xfs_trans_ail.c @@ -349,7 +349,7 @@ xfsaild_push( xfs_ail_min_lsn(ailp))) { ailp->xa_log_flush = 0; - XFS_STATS_INC(xs_push_ail_flush); + XFS_STATS_INC(mp, xs_push_ail_flush); xfs_log_force(mp, XFS_LOG_SYNC); } @@ -371,7 +371,7 @@ xfsaild_push( goto out_done; } - XFS_STATS_INC(xs_push_ail); + XFS_STATS_INC(mp, xs_push_ail); lsn = lip->li_lsn; while ((XFS_LSN_CMP(lip->li_lsn, target) <= 0)) { @@ -385,7 +385,7 @@ xfsaild_push( lock_result = lip->li_ops->iop_push(lip, &ailp->xa_buf_list); switch (lock_result) { case XFS_ITEM_SUCCESS: - XFS_STATS_INC(xs_push_ail_success); + XFS_STATS_INC(mp, xs_push_ail_success); trace_xfs_ail_push(lip); ailp->xa_last_pushed_lsn = lsn; @@ -403,7 +403,7 @@ xfsaild_push( * re-try the flushing relatively soon if most of the * AIL is beeing flushed. */ - XFS_STATS_INC(xs_push_ail_flushing); + XFS_STATS_INC(mp, xs_push_ail_flushing); trace_xfs_ail_flushing(lip); flushing++; @@ -411,14 +411,14 @@ xfsaild_push( break; case XFS_ITEM_PINNED: - XFS_STATS_INC(xs_push_ail_pinned); + XFS_STATS_INC(mp, xs_push_ail_pinned); trace_xfs_ail_pinned(lip); stuck++; ailp->xa_log_flush++; break; case XFS_ITEM_LOCKED: - XFS_STATS_INC(xs_push_ail_locked); + XFS_STATS_INC(mp, xs_push_ail_locked); trace_xfs_ail_locked(lip); stuck++; -- 2.4.3 From uuujsof@ujyg.com Fri Sep 25 23:47:36 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 116E97F37 for ; Fri, 25 Sep 2015 23:47:36 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 73A55AC005 for ; Fri, 25 Sep 2015 21:47:35 -0700 (PDT) X-ASG-Debug-ID: 1443242848-04cbb033b2fbea0001-NocioJ Received: from ujyg.com ([14.118.213.48]) by cuda.sgi.com with ESMTP id aTSGwys3a6vF8FgT for ; Fri, 25 Sep 2015 21:47:29 -0700 (PDT) X-Barracuda-Envelope-From: uuujsof@ujyg.com X-Barracuda-Apparent-Source-IP: 14.118.213.48 Received: from 2012-20140327VR ([127.0.0.1]) by localhost via TCP with ESMTPA; Sat, 26 Sep 2015 12:46:23 +0800 MIME-Version: 1.0 From: "Joyce Chung" Sender: "Joyce Chung" To: xfs@oss.sgi.com Reply-To: "Joyce Chung" Date: 26 Sep 2015 12:46:23 +0800 Subject: =?utf-8?B?Rmlyc3Qgb2YgdGhlIFdvcmxkISEhIEZhc3QgQ2hhcmdlciEgU21hcnQgUG93ZXIgYmFuayB3aXRoIER1YWwgSW5wdXQgSW50ZXJmYWNlIChMaWdodGluZyZNaXJjbyk=?= Content-Type: multipart/alternative; boundary=--boundary_28899_0eeba46a-8043-4288-bc2d-9e6272efa6e0 X-ASG-Orig-Subj: =?utf-8?B?Rmlyc3Qgb2YgdGhlIFdvcmxkISEhIEZhc3QgQ2hhcmdlciEgU21hcnQgUG93ZXIgYmFuayB3aXRoIER1YWwgSW5wdXQgSW50ZXJmYWNlIChMaWdodGluZyZNaXJjbyk=?= X-Barracuda-Connect: UNKNOWN[14.118.213.48] X-Barracuda-Start-Time: 1443242848 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.20 X-Barracuda-Spam-Status: No, SCORE=1.20 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC5_MJ1963, HTML_MESSAGE, MISSING_MID, PLING_PLING, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22906 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 MISSING_MID Missing Message-Id: header 0.00 HTML_MESSAGE BODY: HTML included in message 0.46 PLING_PLING Subject has lots of exclamation marks 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 Message-Id: <20150926044734.B46CB106C0A0@cuda.sgi.com> ----boundary_28899_0eeba46a-8043-4288-bc2d-9e6272efa6e0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQpXaXRoIExFRCBEaXNwbGF5IEZhc3QgQ2hhcmdlciAyLjFBLzEuMEEgJm5ic3A7RnVsbCAx MDAwME1BSCBzaGFrZSBhIHNoYWtlIFNtYXJ0IFBvd2VyIGJhbmtTIHdpdGggTGlnaHRpbmcm YW1wO01pcmNvIEludGVyZmFjZQ0KDQpGZWF0dXJlOg0KRmVhdHVyZToNCjEuJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IER1YWwgaW5wdXQgaW50ZXJmYWNlKDFBICZh bXA7IDIuMUEpDQoyLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEdWFs IE91dHB1dCBJbnRlcmZhY2UgKExpZ2h0aW5nJmFtcDtNaXJjbykNCjMuJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIuMUEgRmFzdCBDaGFyZ2VyIE91dHB1dA0KNC4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTEVEIGRpc3BsYXkoc2hvdyB0 aGUgcGVyY2VudGFnZSBvZiB0aGUgcG93ZXIgYmFuaykNCjUuJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNoYWtlIGEgc2hha2UsIEludGVsbGlnZW50Jm5ic3A7IHBv d2VyIG9uDQo2LiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGdWxsIENh cGFjaXR5IDoxMDAwME1haA0KNy4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgNyZuYnNwOyBQcm90ZWN0aW9ucyhPdmVyIGNoYXJnZXIsIG92ZXJoZWF0LCBzaG9ydCBj aXJjdWl0LCBvdmVyIGN1cnJlbnQsIG92ZXIgZGlzY2hhcmdlLCBvdmVyIHZvbHRhZ2UsIHZl ciBwb3dlcikNCjguJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFjY2Vw dCBzbWFsbCBvcmRlciAsT0VNJmFtcDtPRE0gU2VydmljZQ0KJm5ic3A7DQpIYXZlIGFueSBp bnRlcmVzdGVkLCB3ZWxjb21lIHRvIGNvbnRhY3Qgd2l0aCB1czogYWRtaW5AZ3pxaW5saW5n LmNvbS5jbiZuYnNwOyZuYnNwOyBoZXJlIGlzIEpveWNl ----boundary_28899_0eeba46a-8043-4288-bc2d-9e6272efa6e0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IENhbGli cmk7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250 LWZhbWlseTogQ2FsaWJyaTsgbXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItbGF0aW4iPjxT UEFOIHN0eWxlPSJtc28tbGlzdDogSWdub3JlIj48Rk9OVCBmYWNlPUNhbGlicmk+DQo8UD48 U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAyNHB4Ij48U1RST05HPjxTUEFOIHN0eWxlPSJCQUNL R1JPVU5ELUNPTE9SOiByZ2IoMCwyNTUsMCkiPldpdGggTEVEIERpc3BsYXkgRmFzdCBDaGFy Z2VyIDIuMUEvMS4wQSAmbmJzcDtGdWxsIDEwMDAwTUFIIHNoYWtlIGEgc2hha2UgU21hcnQg UG93ZXIgYmFua1Mgd2l0aCBMaWdodGluZyZhbXA7TWlyY28gSW50ZXJmYWNlPC9TUEFOPjwv U1RST05HPjwvU1BBTj48L1A+DQo8UD48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAyNHB4Ij48 U1RST05HPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiByZ2IoMCwyNTUsMCkiPjxJ TUcgYWx0PTAxLmpwZyBzcmM9Imh0dHA6Ly9nMDQuYS5hbGljZG4uY29tL2tmL0hUQjE1WE5H SlhYWFhYYkVhcFhYcTZ4WEZYWFhtLzIwMDM5OTcwMC9IVEIxNVhOR0pYWFhYWGJFYXBYWHE2 eFhGWFhYbS5qcGc/d2lkdGg9MTAwMCZhbXA7aGVpZ2h0PTc2MiZhbXA7c2l6ZT05NzU2MCZh bXA7aGFzaD03MTMyZDMwNGIzZGI0NmI5NzVjMTFkYWU2N2MxNjI4YyI+PElNRyBhbHQ9MTAu anBnIHNyYz0iaHR0cDovL2cwMS5hLmFsaWNkbi5jb20va2YvSFRCMW8zQjRKWFhYWFhYblhw WFhxNnhYRlhYWEsvMjAwMzk5NzAwL0hUQjFvM0I0SlhYWFhYWG5YcFhYcTZ4WEZYWFhLLmpw Zz93aWR0aD0xMDAwJmFtcDtoZWlnaHQ9NzIyJmFtcDtzaXplPTI3OTE1MiZhbXA7aGFzaD0x MmQyMGI5YzYxYzc4Y2U3NmIxMjYxN2QxODljMDIwZiI+PElNRyBhbHQ9MDIuanBnIHNyYz0i aHR0cDovL2cwMS5hLmFsaWNkbi5jb20va2YvSFRCMXlpNFRKWFhYWFhjT1hGWFhxNnhYRlhY WDUvMjAwMzk5NzAwL0hUQjF5aTRUSlhYWFhYY09YRlhYcTZ4WEZYWFg1LmpwZz93aWR0aD0x MDAwJmFtcDtoZWlnaHQ9NjE4JmFtcDtzaXplPTE2MjIzNiZhbXA7aGFzaD0wZDY4YWIxNGI0 NTQ0NGJiOWFiNmI4NjFmNjJhODFiNSI+PElNRyBhbHQ9MDUuanBnIHNyYz0iaHR0cDovL2cw NC5hLmFsaWNkbi5jb20va2YvSFRCMTJEZE1KWFhYWFhYM2FYWFhxNnhYRlhYWE4vMjAwMzk5 NzAwL0hUQjEyRGRNSlhYWFhYWDNhWFhYcTZ4WEZYWFhOLmpwZz93aWR0aD0xMDAwJmFtcDto ZWlnaHQ9NTk1JmFtcDtzaXplPTE2OTE3NiZhbXA7aGFzaD1lNTQ3Mzc5OGVhZmRkZWEzMDM4 YjhiY2MxMThkNTMxNiI+PElNRyBhbHQ9MDYuanBnIHNyYz0iaHR0cDovL2cwMy5hLmFsaWNk bi5jb20va2YvSFRCMXVwbDhKWFhYWFhhdFhYWFhxNnhYRlhYWHUvMjAwMzk5NzAwL0hUQjF1 cGw4SlhYWFhYYXRYWFhYcTZ4WEZYWFh1LmpwZz93aWR0aD0xMDAwJmFtcDtoZWlnaHQ9NTg2 JmFtcDtzaXplPTIxMTM5NSZhbXA7aGFzaD03MDRhZWVhMGQ4MGI3ZmQ4ZTdlMmQ1OGZiNzVl MjE2MSI+PElNRyBhbHQ9MDMuanBnIHNyYz0iaHR0cDovL2cwMi5hLmFsaWNkbi5jb20va2Yv SFRCMWlTQlNKWFhYWFhjblhGWFhxNnhYRlhYWGYvMjAwMzk5NzAwL0hUQjFpU0JTSlhYWFhY Y25YRlhYcTZ4WEZYWFhmLmpwZz93aWR0aD0xMDAwJmFtcDtoZWlnaHQ9Njk5JmFtcDtzaXpl PTE5NjE4MCZhbXA7aGFzaD1iMTNkOTdjMDNkYzExMWZjNWUzMTRhZDlmYjQzOTA1ZCI+PElN RyBhbHQ9MDcuanBnIHNyYz0iaHR0cDovL2cwMS5hLmFsaWNkbi5jb20va2YvSFRCMS54MEdK WFhYWFhhR2FwWFhxNnhYRlhYWHkvMjAwMzk5NzAwL0hUQjEueDBHSlhYWFhYYUdhcFhYcTZ4 WEZYWFh5LmpwZz93aWR0aD0xMDAwJmFtcDtoZWlnaHQ9NTg5JmFtcDtzaXplPTIxODI3NSZh bXA7aGFzaD1iMmVkYjliZTliMzk3NzJjZDI1NWY4YTUwZTM0NTNmNCI+PElNRyBhbHQ9MDgu anBnIHNyYz0iaHR0cDovL2cwMS5hLmFsaWNkbi5jb20va2YvSFRCMTl2QldKWFhYWFhheFhG WFhxNnhYRlhYWGUvMjAwMzk5NzAwL0hUQjE5dkJXSlhYWFhYYXhYRlhYcTZ4WEZYWFhlLmpw Zz93aWR0aD0xMDAwJmFtcDtoZWlnaHQ9NjQ5JmFtcDtzaXplPTE0MzY4NCZhbXA7aGFzaD1j ZTVjMmY2MjMzYjEyYWU5MzdlMjg2ZGE0YWZmYTg3NiI+PElNRyBhbHQ9MDQuanBnIHNyYz0i aHR0cDovL2cwMi5hLmFsaWNkbi5jb20va2YvSFRCMTdmcEhKWFhYWFhYSmFwWFhxNnhYRlhY WEovMjAwMzk5NzAwL0hUQjE3ZnBISlhYWFhYWEphcFhYcTZ4WEZYWFhKLmpwZz93aWR0aD0x MDAwJmFtcDtoZWlnaHQ9ODc1JmFtcDtzaXplPTE5MzE1NSZhbXA7aGFzaD0yODlkMzE5ZTY2 NmE3Mjc1ZjY2MTY2MjUzMmEyOTdmYiI+PEJSPjwvU1BBTj48L1NUUk9ORz48L1NQQU4+PC9Q Pg0KPFA+PFNUUk9ORyBzdHlsZT0iRk9OVC1TSVpFOiAyNHB4OyBDT0xPUjogcmdiKDI1NSww LDApOyBMSU5FLUhFSUdIVDogMS41Ij5GZWF0dXJlOjwvU1RST05HPjwvUD48L0ZPTlQ+PC9T UEFOPjwvU1BBTj4NCjxQIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQgMThwdDsgVEVYVC1JTkRFTlQ6IC0xOHB0OyBtc28tY2hhci1pbmRlbnQt Y291bnQ6IDA7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSI+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1mYXJlYXN0LXRo ZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogQ2FsaWJyaTsg bXNvLWJpZGktdGhlbWUtZm9udDogbWlub3ItbGF0aW4iPjxTUEFOIHN0eWxlPSJtc28tbGlz dDogSWdub3JlIj48Rk9OVCBmYWNlPUNhbGlicmk+RmVhdHVyZTo8L0ZPTlQ+PC9TUEFOPjwv U1BBTj48L1A+DQo8UCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSJNQVJHSU46IDBj bSAwY20gMHB0IDE4cHQ7IFRFWFQtSU5ERU5UOiAtMThwdDsgbXNvLWNoYXItaW5kZW50LWNv dW50OiAwOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzEiPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tZmFyZWFzdC10aGVt ZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6IENhbGlicmk7IG1z by1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluIj48U1BBTiBzdHlsZT0ibXNvLWxpc3Q6 IElnbm9yZSI+PEZPTlQgZmFjZT1DYWxpYnJpPjEuPC9GT05UPjxTUEFOIHN0eWxlPSdGT05U OiA3cHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZh Y2U9Q2FsaWJyaT5EdWFsIGlucHV0IGludGVyZmFjZSgxQSAmYW1wOyAyLjFBKTwvRk9OVD48 L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0iTUFSR0lOOiAw Y20gMGNtIDBwdCAxOHB0OyBURVhULUlOREVOVDogLTE4cHQ7IG1zby1jaGFyLWluZGVudC1j b3VudDogMDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWZhcmVhc3QtdGhl bWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBt c28tYmlkaS10aGVtZS1mb250OiBtaW5vci1sYXRpbiI+PFNQQU4gc3R5bGU9Im1zby1saXN0 OiBJZ25vcmUiPjxGT05UIGZhY2U9Q2FsaWJyaT4yLjwvRk9OVD48U1BBTiBzdHlsZT0nRk9O VDogN3B0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBm YWNlPUNhbGlicmk+RHVhbCBPdXRwdXQgSW50ZXJmYWNlIChMaWdodGluZyZhbXA7TWlyY28p PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSJN QVJHSU46IDBjbSAwY20gMHB0IDE4cHQ7IFRFWFQtSU5ERU5UOiAtMThwdDsgbXNvLWNoYXIt aW5kZW50LWNvdW50OiAwOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzEiPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tZmFy ZWFzdC10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6IENh bGlicmk7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluIj48U1BBTiBzdHlsZT0i bXNvLWxpc3Q6IElnbm9yZSI+PEZPTlQgZmFjZT1DYWxpYnJpPjMuPC9GT05UPjxTUEFOIHN0 eWxlPSdGT05UOiA3cHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVT PjxGT05UIGZhY2U9Q2FsaWJyaT4yLjFBIEZhc3QgQ2hhcmdlciBPdXRwdXQ8L0ZPTlQ+PC9T UEFOPjwvUD4NCjxQIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQgMThwdDsgVEVYVC1JTkRFTlQ6IC0xOHB0OyBtc28tY2hhci1pbmRlbnQtY291 bnQ6IDA7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSI+PFNQQU4gbGFuZz1FTi1VUyBzdHls ZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1mYXJlYXN0LXRoZW1l LWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNv LWJpZGktdGhlbWUtZm9udDogbWlub3ItbGF0aW4iPjxTUEFOIHN0eWxlPSJtc28tbGlzdDog SWdub3JlIj48Rk9OVCBmYWNlPUNhbGlicmk+NC48L0ZPTlQ+PFNQQU4gc3R5bGU9J0ZPTlQ6 IDdwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvU1BBTj48L1NQQU4+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFj ZT1DYWxpYnJpPkxFRCBkaXNwbGF5KHNob3cgdGhlIHBlcmNlbnRhZ2Ugb2YgdGhlIHBvd2Vy IGJhbmspPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0 eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IDE4cHQ7IFRFWFQtSU5ERU5UOiAtMThwdDsgbXNv LWNoYXItaW5kZW50LWNvdW50OiAwOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzEiPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBt c28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1p bHk6IENhbGlicmk7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluIj48U1BBTiBz dHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+PEZPTlQgZmFjZT1DYWxpYnJpPjUuPC9GT05UPjxT UEFOIHN0eWxlPSdGT05UOiA3cHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiBsYW5n PUVOLVVTPjxGT05UIGZhY2U9Q2FsaWJyaT5TaGFrZSBhIHNoYWtlLCBJbnRlbGxpZ2VudDxT UEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj5wb3dlciBvbjwv Rk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDBwdCAxOHB0OyBURVhULUlOREVOVDogLTE4cHQ7IG1zby1jaGFyLWlu ZGVudC1jb3VudDogMDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWZhcmVh c3QtdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBDYWxp YnJpOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1sYXRpbiI+PFNQQU4gc3R5bGU9Im1z by1saXN0OiBJZ25vcmUiPjxGT05UIGZhY2U9Q2FsaWJyaT42LjwvRk9OVD48U1BBTiBzdHls ZT0nRk9OVDogN3B0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUz48 Rk9OVCBmYWNlPUNhbGlicmk+RnVsbCBDYXBhY2l0eSA6MTAwMDBNYWg8L0ZPTlQ+PC9TUEFO PjwvUD4NCjxQIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9Ik1BUkdJTjogMGNtIDBj bSAwcHQgMThwdDsgVEVYVC1JTkRFTlQ6IC0xOHB0OyBtc28tY2hhci1pbmRlbnQtY291bnQ6 IDA7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1mYXJlYXN0LXRoZW1lLWZv bnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWJp ZGktdGhlbWUtZm9udDogbWlub3ItbGF0aW4iPjxTUEFOIHN0eWxlPSJtc28tbGlzdDogSWdu b3JlIj48Rk9OVCBmYWNlPUNhbGlicmk+Ny48L0ZPTlQ+PFNQQU4gc3R5bGU9J0ZPTlQ6IDdw dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvU1BBTj48L1NQQU4+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT1D YWxpYnJpPjc8U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+ UHJvdGVjdGlvbnMoT3ZlciBjaGFyZ2VyLCBvdmVyaGVhdCwgc2hvcnQgY2lyY3VpdCwgb3Zl ciBjdXJyZW50LCBvdmVyIGRpc2NoYXJnZSwgb3ZlciB2b2x0YWdlLCB2ZXIgcG93ZXIpPC9G T05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSJNQVJH SU46IDBjbSAwY20gMHB0IDE4cHQ7IFRFWFQtSU5ERU5UOiAtMThwdDsgbXNvLWNoYXItaW5k ZW50LWNvdW50OiAwOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzEiPjxTUEFOIGxhbmc9RU4t VVMgc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tZmFyZWFz dC10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6IENhbGli cmk7IG1zby1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluIj48U1BBTiBzdHlsZT0ibXNv LWxpc3Q6IElnbm9yZSI+PEZPTlQgZmFjZT1DYWxpYnJpPjguPC9GT05UPjxTUEFOIHN0eWxl PSdGT05UOiA3cHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTPjxG T05UIGZhY2U9Q2FsaWJyaT5BY2NlcHQgc21hbGwgb3JkZXIgLE9FTSZhbXA7T0RNIFNlcnZp Y2U8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48P3htbDpuYW1lc3BhY2UgcHJlZml4 ID0gIm8iIG5zID0gInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIg Lz48bzpwPjxGT05UIGZhY2U9Q2FsaWJyaT4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQ QU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPUNhbGlicmk+SGF2ZSBhbnkgaW50ZXJlc3RlZCwg d2VsY29tZSB0byBjb250YWN0IHdpdGggdXM6IGFkbWluQGd6cWlubGluZy5jb20uY248U1BB TiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyA8L1NQQU4+aGVyZSBp cyBKb3ljZTwvRk9OVD48L1NQQU4+PC9QPg== ----boundary_28899_0eeba46a-8043-4288-bc2d-9e6272efa6e0-- From editor@pakinsight.com Sat Sep 26 05:01:52 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 438837F37 for ; Sat, 26 Sep 2015 05:01:52 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id E308A304032 for ; Sat, 26 Sep 2015 03:01:48 -0700 (PDT) X-ASG-Debug-ID: 1443261705-04bdf04622f3d50001-NocioJ Received: from pak.pakinsight.com (pak.pakinsight.com [50.116.74.27]) by cuda.sgi.com with ESMTP id T43Zx8RO960lURzX (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 26 Sep 2015 03:01:45 -0700 (PDT) X-Barracuda-Envelope-From: editor@pakinsight.com X-Barracuda-Apparent-Source-IP: 50.116.74.27 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=pakinsight.com; s=default; h=Content-Transfer-Encoding:Content-Type:List-Unsubscribe:MIME-Version:Reply-To:From:Date:Message-ID:Subject:To; bh=K15aKGFrJ06dHfkTwOik6q/cunFGcw/Cv/f7mHT/F24=; b=GT3zrdiI+yOjvPKqDP6aNnjKs01YWk6a2udn8czrlnbXXHM0sUY12k14hB8WDh6lBImYbKpp+MGN/aq6DWahjcB5dwU3cVEhr1Yinz+1zqJLBY+5zZYGb/o0Yi61i5FnE/3X+Vs3YuuVDTru5hDA7E69oZGKJhMoS+TE2p+AB6M=; Received: from qazi786 by pak.pakinsight.com with local (Exim 4.85) (envelope-from ) id 1ZfmIa-0003wm-Sf for xfs@oss.sgi.com; Sat, 26 Sep 2015 05:01:44 -0500 To: xfs@oss.sgi.com Subject: 4th International Conference on Emerging Trends in Scientific Research X-PHP-Script: marketing.pakinsight.com/admin/index.php for 175.139.2.178 X-ASG-Orig-Subj: 4th International Conference on Emerging Trends in Scientific Research Message-ID: <4999da352ac8c8ddae816f68824e0d03@marketing.pakinsight.com> Date: Sat, 26 Sep 2015 10:01:44 +0000 From: "Pakistan" Reply-To: editor@pakinsight.com MIME-Version: 1.0 X-Mailer-LID: 12,11 List-Unsubscribe: X-Mailer-RecptId: 513184 X-Mailer-SID: 11 X-Mailer-Sent-By: 1 Content-Type: multipart/alternative; charset="UTF-8"; boundary="b1_cf81daa30da121dd6d71536eef1c4a10" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - pak.pakinsight.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [504 513] / [47 12] X-AntiAbuse: Sender Address Domain - pakinsight.com X-Get-Message-Sender-Via: pak.pakinsight.com: authenticated_id: qazi786/from_h X-Barracuda-Connect: pak.pakinsight.com[50.116.74.27] X-Barracuda-Start-Time: 1443261705 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22912 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message --b1_cf81daa30da121dd6d71536eef1c4a10 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Your email client cannot read this email. To view it online, please go here: http://marketing.pakinsight.com/display.php?M=513184&C=a6e72a2ec2feed13df23d5858ee79367&S=11&L=12&N=6 To stop receiving these emails:http://marketing.pakinsight.com/unsubscribe.php?M=513184&C=a6e72a2ec2feed13df23d5858ee79367&L=12&N=11 Powered by Hairyspire --b1_cf81daa30da121dd6d71536eef1c4a10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Template

logo-1.png

4th International Conference on Emerging Trends in Scientific Research

28-29 November, 2015,

Nippon Hotel,
Ä°stanbul-Turkey
ISBN: 978-969-9952-02-9
URL : http://www.pakrdw.com/?ic=details&id=11 

Abstract Submission Date: 15th October, 2015
Decision of Acceptance/Rejection: Within 15 days of submission 
Full Paper Submission Date: 1st November, 2015
Early Bird Discount Date: 1st November, 2015
Conference Date: 28-29 November, 2015
 

The Pak Research & Development Wing proudly announce the  4th International Conference on Emerging Trends in Scientific Research, 28-29 November, 2015, Ä°stanbul-Turkey. The conference organizing committee invites you to submit your papers. The conference will cover important issues in Scientific Research under various sub-themes. The purpose of this conference is to bring together researchers from around the globe in order to present and discuss new trends in the fields of Scientific Research. 

Conference Main Tracks

  • Biomedical & Life Sciences
  • Business & Economics
  • Chemistry & Materials Science
  • Computer Science & Communications
  • Earth & Environmental Sciences
  • Engineering
  • Medicine & Healthcare
  • Physics & Mathematics
  • Social Sciences & Humanities
  • Foundations of Science, Engineering and Technology
  • Applications of Science, Engineering and Technology
Online Submission : http://www.pakrdw.com/?ic=details&id=11&info=submission
Registration Details : http://www.pakrdw.com/?ic=details&id=11&info=dates
Journal Publication: http://www.pakrdw.com/?ic=details&id=11&info=publication

Our Other Conferences

1. 3rd International Conference on Business Strategy and Social Sciences
    3-4 October, 2015, Langkawi, Malaysia
    URL: http://www.pakrdw.com/index.php?ic=details&id=10 

2. 4th International Conference on Economics, Finance and Management Outlooks
    29-30 December, 2015, Dubai
    URL :  http://www.pakrdw.com/index.php?ic=details&id=13

3.  2nd International Conference on Energy, Environment and Agricultural Sciences
    29-30 December, 2015, Dubai
    URL:  http://www.pakrdw.com/index.php?ic=details&id=14

4. 4th International Conference on Business Strategy and Social Sciences
     26-27 January, 2016, Singapore
     URL:  http://www.pakrdw.com/index.php?ic=details&id=15

List of Previous Proceedings Book


Unsubscribe | To contact us please email conference@pakinsight.com

Pak Research & Development Wing
 
Pak Publishing Group
Singapore Office : 22 Sin
Ming Lane #06-76 Midview City Singapore 573969
UK Office : Third
Floor, 207 Regent Street, London W1B 3HH
Pakistan Office : Amin Garh
Road, Near Hafiz Abad Colony, Rahim Yar Khan - 64200, Punjab,
Pakistan


Powered by Hairyspire
--b1_cf81daa30da121dd6d71536eef1c4a10-- From service@baidu.com Sat Sep 26 12:18:55 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 8641F7F37 for ; Sat, 26 Sep 2015 12:18:55 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 69CFA304043 for ; Sat, 26 Sep 2015 10:18:52 -0700 (PDT) X-ASG-Debug-ID: 1443287928-04cb6c6b06f6bb0001-NocioJ Received: from alph123.prodigy.net (alph123.prodigy.net [144.160.244.31]) by cuda.sgi.com with ESMTP id rmX9I6QcvKikPoCf (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 26 Sep 2015 10:18:48 -0700 (PDT) X-Barracuda-Envelope-From: service@baidu.com X-Barracuda-Apparent-Source-IP: 144.160.244.31 X-ORBL: [209.62.147.105] Received: from w219426vwap2035 (w219426icnvfw1001.usi.net [209.62.147.105]) by alph123.prodigy.net ( MISIO Bulk EOD 8.14.5 /8.14.5) with ESMTP id t8QHIgJO001363 for ; Sat, 26 Sep 2015 13:18:43 -0400 Message-ID: <1968831942.1443287928040.JavaMail.weblogic@w219426vwap2035> Date: Sat, 26 Sep 2015 12:18:48 -0500 (CDT) From: service@baidu.com To: xfs@oss.sgi.com Subject: =?UTF-8?B?5oKo55qE5pyL5Y+L5b6ea29obGVy5Lit5ZyL?= =?UTF-8?B?5a6Y5pa557ay56uZ5ZCR5oKo55m86YCB6Zu75a2Q6YO15Lu277yB?= MIME-Version: 1.0 X-ASG-Orig-Subj: =?UTF-8?B?5oKo55qE5pyL5Y+L5b6ea29obGVy5Lit5ZyL?= =?UTF-8?B?5a6Y5pa557ay56uZ5ZCR5oKo55m86YCB6Zu75a2Q6YO15Lu277yB?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Barracuda-Connect: alph123.prodigy.net[144.160.244.31] X-Barracuda-Start-Time: 1443287928 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MV0113c, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22919 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 BSF_SC0_MV0113c BSF_SC0_MV0113c 5oKo55qE5pyL5Y+L5o6o6I2Q5oKo5Y675rWP6KeI5q2k572R6aG177yaIA0K5oKo55qE5pyL5Y+L 5ZCR5oKo5YaZ5Yiw77yaIA0KDQoNCjnvvJrlpKnkuIvnrKzkuIDnvo7lpbMNCg0K6JGh5Lqs5pC6 5omLQkJJTiBPRyBYVEQgQUcgSEcgQUIg5YWt5aSn5bmz5Y+wDQoNCuS4k+WxnuazqOWGjOmAmumB kzo2IDkgOSA3IDcgNiAuY29tIOaIliB0bzQuY24vODk4ODc2DQoNCuaAu+WFrOWPuOS4reaWh+e9 keWdgO+8muiRoeS6rOWoseS5kOWfji7lhazlj7gNCg0K5pyA4oC75paw4oC75raI4oC75oGv77ya 6aaW5qyh4oC75a2Y4oC75qy+MTAw5YWD5Lul5LiK55qE77yM6LWg4oC76YCBMTAwJemmluKAu+Wt mOW9qeKAu+mHke+8jOWtmOKAu+asvuaIkOKAu+WKn+WFjeKAu+i0ueWNh+KAu+e6p+m7hOKAu+mH kVZJUOKAu+S8muKAu+WRmO+8jOacgOKAu+mrmOmZkOKAu+WItjUwMDAw5YWD77yMMTDlgI3mtYHi gLvmsLTljbPigLvlj6/lh7rigLvmrL4NCg0K6K+m5oOF55m75YWlLS3ms6jlhowtLS3lkqjor6It LS03eDI05bCP5pe25a6i5pyNDQoNCuWkqeWkqei/lOawtOmrmOmBlDIuOCXml6DkuIrpmZDvvIzl hazorqTkv6HoqokgIOWuieWFqOawuOS5he+8iOeLrOS4gOaXoOS6jO+8jOS7heatpOS4gOWutu+8 iQ0KDQrljZXnrJTmnIDpq5jmj5DmrL4xMDAw5LiH77yMIOWtmOWPluasvuiHqueUse+8jDDmiYvn u63otLkgM+WIhumSn+WIsOi0pg0KDQrotZvkuovmnIDlhajvvIzotZTnjofmnIDpq5jvvIzov5Tm sLTmnIDpq5jvvIznu5PnrpfmnIDlv6vvvIzmmK/kuprmtLLmnIDlj5fmrKLov47kvZPogrLmipXm s6jlubPlj7AuICAuDQoNCueUs+KImuivt+KImjE45YWD4piF5o6o4pmA5bm/5b2p4piG6YeR6ZyA 4oia6KaB5o6o4pmC5bm/6L2s4pmA5Y+R5raI4oia5oGv77yBDQoNCuiogOihjOS4jeWmpeWvueS4 jei1t++8jOaFsOmXruS7luS6uuivtOi+m+iLpu+8jOi/juaOpeWuouS6uuivtOasoui/juOAgg== From angelo.dureghello@nomovok.com Sat Sep 26 19:40:39 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id DA1BD7F37 for ; Sat, 26 Sep 2015 19:40:38 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 58D23AC001 for ; Sat, 26 Sep 2015 17:40:34 -0700 (PDT) X-ASG-Debug-ID: 1443314428-04cbb033b21117e0001-NocioJ Received: from mail.nomovok.com (mail.nomovok.com [83.150.122.238]) by cuda.sgi.com with ESMTP id w29OJzt5CCm2h6nG (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 26 Sep 2015 17:40:29 -0700 (PDT) X-Barracuda-Envelope-From: angelo.dureghello@nomovok.com X-Barracuda-Apparent-Source-IP: 83.150.122.238 Received: from [192.168.0.111] (unknown [95.233.233.211]) by mail.nomovok.com (Postfix) with ESMTPSA id B5088AE089 for ; Sun, 27 Sep 2015 03:40:26 +0300 (EEST) Message-ID: <56073AF8.4060801@nomovok.com> Date: Sun, 27 Sep 2015 02:40:24 +0200 From: Angelo Dureghello User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: xfstests, bad generic tests 009 and 308 References: <55FC3E0E.9060506@nomovok.com> <20150918224412.GE26895@dastard> <55FFE665.7040004@nomovok.com> <20150921225244.GD19114@dastard> <56028249.7040103@univ-nantes.fr> <20150923220444.GP19114@dastard> <5603B240.4030609@univ-nantes.fr> X-ASG-Orig-Subj: Re: xfstests, bad generic tests 009 and 308 In-Reply-To: <5603B240.4030609@univ-nantes.fr> Content-Type: multipart/mixed; boundary="------------000101010701030200020700" X-Barracuda-Connect: mail.nomovok.com[83.150.122.238] X-Barracuda-Start-Time: 1443314429 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-ASG-Whitelist: Body =?UTF-8?B?aHR0cDovL21hcmNcLmluZm8vXD8=?= X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 This is a multi-part message in MIME format. --------------000101010701030200020700 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dave and all, The 99% cpu loop on tests/generic/308 (on "rm") happens also on i686 (32bit), kernel 4.2.0 (gcc 4.9.1) So, we can exclude it is a cross-compilation issue, or an ARM specific issue. It should just be a 32-bit rch wide related issue. I hardly found out the reason, at my opinion it doesn't have to be fixed in xfs. I proposed this patch. http://marc.info/?l=linux-kernel&m=144330858305518&w=2 Let's see if the list reply. Couldn't proceed still on the other "all hole" errors, will look into that. As far as i know, tests as 009 seems to give same errors to non arm users too. Will investigate further. Best regards, Angelo Dureghello On 24/09/2015 10:20, Yann Dupont - Veille Techno wrote: > Le 24/09/2015 00:04, Dave Chinner a écrit : >> On Wed, Sep 23, 2015 at 12:43:21PM +0200, Yann Dupont - Veille Techno >> wrote: >>> Le 22/09/2015 00:52, Dave Chinner a écrit : >>>> As it is, I highly recommend that you try a current 4.3 kernel, as >>>> there are several code fixes in the XFS kernel code that work >>>> around compiler issues we know about. AFAIA, the do_div() asm bug >>>> that trips recent gcc optimisations isn't in the upstream kernel >>>> yet, but that can be worked around by setting >>>> CONFIG_CC_OPTIMIZE_FOR_SIZE=y in your build. >>> Hi dave, >>> >>> I can confirm that CONFIG_CC_OPTIMIZE_FOR_SIZE=y is (was ?) the only >>> way for me to have reliable XFS kernel code on different arm >>> platforms (Marvell kirkwood, Allwinner A20, Amlogic S805), no matter >>> what recent gcc version I've been using. >>> >>> I must admit I was cross-compiling from X86-64 too, but I think (not >>> sure) that it was also the case with native gcc. >>> >>> I must also admit that I didn't tried since some months, because >>> CONFIG_CC_OPTIMIZE_FOR_SIZE=y was the silver bullet for arm xfs >>> kernel crashes. This crash was difficult to understand because it >>> occurs quite randomly (I.e it can take several hours to trigger) >>> >>> If there's a patch floating around for gcc (or kernel), I'm >>> interested to test. >> See this subthread from august: >> >> http://oss.sgi.com/archives/xfs/2015-08/msg00234.html > > Oh, missed this thread. > > Thanks a lot for the pointer, will try this patch ! > Cheers, > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs -- Best regards, Angelo Dureghello --------------000101010701030200020700 Content-Type: text/plain; charset=UTF-8; name="ftrace_rm_308.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ftrace_rm_308.txt" IyBjYXQgL3N5cy9rZXJuZWwvZGVidWcvdHJhY2luZy90cmFjZSB8IGhlYWQgLTEwMDAKIyB0 cmFjZXI6IGZ1bmN0aW9uX2dyYXBoCiMKIyBDUFUgIERVUkFUSU9OICAgICAgICAgICAgICAg ICAgRlVOQ1RJT04gQ0FMTFMKIyB8ICAgICB8ICAgfCAgICAgICAgICAgICAgICAgICAgIHwg ICB8ICAgfCAgIHwKIDEpICAgMC44MTQgdXMgICAgfCAgeGZzX2ZpbGVfb3BlbigpOwogMCkg ICAgICAgICAgICAgICB8ICB4ZnNfeGF0dHJfZ2V0KCkgewogMCkgICAwLjY1MCB1cyAgICB8 ICAgIHhmc19hdHRyX2dldCgpOwogMCkgICA1Ljg1NiB1cyAgICB8ICB9CiAwKSAgICAgICAg ICAgICAgIHwgIHhmc19maWxlX3JlYWRfaXRlcigpIHsKIDApICAgMS4zMDEgdXMgICAgfCAg ICB4ZnNfaWxvY2soKTsKIDApICAgMS4xMzkgdXMgICAgfCAgICB4ZnNfaXVubG9jaygpOwog MCkgKyAxOS4wMzIgdXMgICB8ICB9CiAwKSAgICAgICAgICAgICAgIHwgIHhmc19maWxlX3Jl YWRfaXRlcigpIHsKIDApICAgMC44MTQgdXMgICAgfCAgICB4ZnNfaWxvY2soKTsKIDApICAg MC44MTMgdXMgICAgfCAgICB4ZnNfaXVubG9jaygpOwogMCkgKyAxNS45NDIgdXMgICB8ICB9 CiAwKSAgICAgICAgICAgICAgIHwgIHhmc19maWxlX3JlYWRfaXRlcigpIHsKIDApICAgMC40 ODggdXMgICAgfCAgICB4ZnNfaWxvY2soKTsKIDApICAgMC44MTMgdXMgICAgfCAgICB4ZnNf aXVubG9jaygpOwogMCkgKyAxMi4zNjMgdXMgICB8ICB9CiAwKSAgICAgICAgICAgICAgIHwg IHhmc192bl9mb2xsb3dfbGluaygpIHsKIDApICAgICAgICAgICAgICAgfCAgICB4ZnNfcmVh ZGxpbmsoKSB7CiAwKSAgIDAuODE0IHVzICAgIHwgICAgICB4ZnNfaWxvY2soKTsKIDApICAg MC42NTEgdXMgICAgfCAgICAgIHhmc19pdW5sb2NrKCk7CiAwKSAgIDkuMTA5IHVzICAgIHwg ICAgfQogMCkgKyAxNC4zMTUgdXMgICB8ICB9CiAwKSAgIDAuNDg4IHVzICAgIHwgIHhmc19m aWxlX29wZW4oKTsKIDApICAgICAgICAgICAgICAgfCAgeGZzX2ZpbGVfcmVhZF9pdGVyKCkg ewogMCkgICAwLjgxMyB1cyAgICB8ICAgIHhmc19pbG9jaygpOwogMCkgICAwLjgxNCB1cyAg ICB8ICAgIHhmc19pdW5sb2NrKCk7CiAwKSArIDEzLjUwMSB1cyAgIHwgIH0KIDApICAgICAg ICAgICAgICAgfCAgeGZzX2ZpbGVfcmVhZF9pdGVyKCkgewogMCkgICAwLjY1MSB1cyAgICB8 ICAgIHhmc19pbG9jaygpOwogMCkgICAwLjY1MSB1cyAgICB8ICAgIHhmc19pdW5sb2NrKCk7 CiAwKSArIDEyLjIwMCB1cyAgIHwgIH0KIDApICAgMC45NzYgdXMgICAgfCAgeGZzX2ZpbGVf bW1hcCgpOwogMCkgICAwLjY1MSB1cyAgICB8ICB4ZnNfZmlsZV9tbWFwKCk7CiAwKSAgICAg ICAgICAgICAgIHwgIHhmc19maWxlbWFwX2ZhdWx0KCkgewogMCkgICAwLjgxMyB1cyAgICB8 ICAgIHhmc19pbG9jaygpOwogMCkgICAwLjgxMyB1cyAgICB8ICAgIHhmc19pdW5sb2NrKCk7 CiAwKSArIDExLjU1MCB1cyAgIHwgIH0KIDApICAgMC44MTMgdXMgICAgfCAgeGZzX2ZpbGVf bW1hcCgpOwogMCkgICAwLjgxMyB1cyAgICB8ICB4ZnNfZmlsZV9tbWFwKCk7CiAwKSAgICAg ICAgICAgICAgIHwgIHhmc19maWxlbWFwX2ZhdWx0KCkgewogMCkgICAwLjgxMyB1cyAgICB8 ICAgIHhmc19pbG9jaygpOwogMCkgICAwLjY1MSB1cyAgICB8ICAgIHhmc19pdW5sb2NrKCk7 CiAwKSArIDEwLjQxMCB1cyAgIHwgIH0KIDApICAgICAgICAgICAgICAgfCAgeGZzX2ZpbGVf cmVsZWFzZSgpIHsKIDApICAgICAgICAgICAgICAgfCAgICB4ZnNfcmVsZWFzZSgpIHsKIDAp ICAgMC42NTAgdXMgICAgfCAgICAgIHhmc19jYW5fZnJlZV9lb2ZibG9ja3MoKTsKIDApICAg ICAgICAgICAgICAgfCAgICAgIHhmc19mcmVlX2VvZmJsb2NrcygpIHsKIDApICAgMC45NzYg dXMgICAgfCAgICAgICAgeGZzX2lsb2NrKCk7CiAwKSAgICAgICAgICAgICAgIHwgICAgICAg IHhmc19ibWFwaV9yZWFkKCkgewogMCkgICAwLjQ4OCB1cyAgICB8ICAgICAgICAgIHhmc19p c2lsb2NrZWQoKTsKIDApICAgICAgICAgICAgICAgfCAgICAgICAgICB4ZnNfYm1hcF9zZWFy Y2hfZXh0ZW50cygpIHsKIDApICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHhmc19ibWFw X3NlYXJjaF9tdWx0aV9leHRlbnRzKCkgewogMCkgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICB4ZnNfaWV4dF9ibm9fdG9fZXh0KCkgewogMCkgICAwLjMyNiB1cyAgICB8ICAgICAg ICAgICAgICAgIHhmc19ibWJ0X2dldF9zdGFydG9mZigpOwogMCkgICAwLjY1MCB1cyAgICB8 ICAgICAgICAgICAgICAgIHhmc19ibWJ0X2dldF9ibG9ja2NvdW50KCk7CiAwKSArIDc2LjI5 MSB1cyAgIHwgICAgICAgICAgICAgIH0KIDApICAgMC40ODggdXMgICAgfCAgICAgICAgICAg ICAgeGZzX2lleHRfZ2V0X2V4dCgpOwogMCkgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICB4ZnNfYm1idF9nZXRfYWxsKCkgewogMCkgICAwLjQ4OCB1cyAgICB8ICAgICAgICAgICAg ICAgIF9feGZzX2JtYnRfZ2V0X2FsbCgpOwogMCkgICA0LjA2NyB1cyAgICB8ICAgICAgICAg ICAgICB9CiAwKSArIDkyLjA3MCB1cyAgIHwgICAgICAgICAgICB9CiAwKSArIDk1LjY0OCB1 cyAgIHwgICAgICAgICAgfQogMCkgISAxMDQuMjcwIHVzICB8ICAgICAgICB9CiAwKSAgIDAu NjUwIHVzICAgIHwgICAgICAgIHhmc19pdW5sb2NrKCk7CiAwKSAhIDExNy42MDggdXMgIHwg ICAgICB9CiAwKSAhIDEyOC44MzIgdXMgIHwgICAgfQogMCkgISAxMzIuODk5IHVzICB8ICB9 CiAwKSAgICAgICAgICAgICAgIHwgIHhmc19maWxlX3JlbGVhc2UoKSB7CiAwKSAgICAgICAg ICAgICAgIHwgICAgeGZzX3JlbGVhc2UoKSB7CiAwKSAgIDAuNjUxIHVzICAgIHwgICAgICB4 ZnNfY2FuX2ZyZWVfZW9mYmxvY2tzKCk7CiAwKSAgICAgICAgICAgICAgIHwgICAgICB4ZnNf ZnJlZV9lb2ZibG9ja3MoKSB7CiAwKSAgIDAuOTc2IHVzICAgIHwgICAgICAgIHhmc19pbG9j aygpOwogMCkgICAgICAgICAgICAgICB8ICAgICAgICB4ZnNfYm1hcGlfcmVhZCgpIHsKIDAp ICAgMC4zMjUgdXMgICAgfCAgICAgICAgICB4ZnNfaXNpbG9ja2VkKCk7CiAwKSAgICAgICAg ICAgICAgIHwgICAgICAgICAgeGZzX2JtYXBfc2VhcmNoX2V4dGVudHMoKSB7CiAwKSAgICAg ICAgICAgICAgIHwgICAgICAgICAgICB4ZnNfYm1hcF9zZWFyY2hfbXVsdGlfZXh0ZW50cygp IHsKIDApICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgeGZzX2lleHRfYm5vX3RvX2V4 dCgpIHsKIDApICAgMC4zMjUgdXMgICAgfCAgICAgICAgICAgICAgICB4ZnNfYm1idF9nZXRf c3RhcnRvZmYoKTsKIDApICAgMC4zMjYgdXMgICAgfCAgICAgICAgICAgICAgICB4ZnNfYm1i dF9nZXRfYmxvY2tjb3VudCgpOwogMCkgICA3LjgwOCB1cyAgICB8ICAgICAgICAgICAgICB9 CiAwKSAgIDAuNDg4IHVzICAgIHwgICAgICAgICAgICAgIHhmc19pZXh0X2dldF9leHQoKTsK IDApICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgeGZzX2JtYnRfZ2V0X2FsbCgpIHsK IDApICAgMC40ODggdXMgICAgfCAgICAgICAgICAgICAgICBfX3hmc19ibWJ0X2dldF9hbGwo KTsKIDApICAgNC4wNjcgdXMgICAgfCAgICAgICAgICAgICAgfQogMCkgKyAyMi4yODYgdXMg ICB8ICAgICAgICAgICAgfQogMCkgKyAyNi4wMjcgdXMgICB8ICAgICAgICAgIH0KIDApICsg MzMuMzQ3IHVzICAgfCAgICAgICAgfQogMCkgICAwLjY1MSB1cyAgICB8ICAgICAgICB4ZnNf aXVubG9jaygpOwogMCkgKyA0OS42MTMgdXMgICB8ICAgICAgfQogMCkgKyA2MC4xODYgdXMg ICB8ICAgIH0KIDApICsgNjQuMDkwIHVzICAgfCAgfQogMCkgICAgICAgICAgICAgICB8ICB4 ZnNfZmlsZV9yZWxlYXNlKCkgewogMCkgICAgICAgICAgICAgICB8ICAgIHhmc19yZWxlYXNl KCkgewogMCkgICAwLjY1MSB1cyAgICB8ICAgICAgeGZzX2Nhbl9mcmVlX2VvZmJsb2Nrcygp OwogMCkgICAgICAgICAgICAgICB8ICAgICAgeGZzX2ZyZWVfZW9mYmxvY2tzKCkgewogMCkg ICAwLjY1MCB1cyAgICB8ICAgICAgICB4ZnNfaWxvY2soKTsKIDApICAgICAgICAgICAgICAg fCAgICAgICAgeGZzX2JtYXBpX3JlYWQoKSB7CiAwKSAgIDAuMzI2IHVzICAgIHwgICAgICAg ICAgeGZzX2lzaWxvY2tlZCgpOwogMCkgICAgICAgICAgICAgICB8ICAgICAgICAgIHhmc19i bWFwX3NlYXJjaF9leHRlbnRzKCkgewogMCkgICAgICAgICAgICAgICB8ICAgICAgICAgICAg eGZzX2JtYXBfc2VhcmNoX211bHRpX2V4dGVudHMoKSB7CiAwKSAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgIHhmc19pZXh0X2Jub190b19leHQoKSB7CiAwKSAgIDAuMzI1IHVzICAg IHwgICAgICAgICAgICAgICAgeGZzX2JtYnRfZ2V0X3N0YXJ0b2ZmKCk7CiAwKSAgIDAuMzI2 IHVzICAgIHwgICAgICAgICAgICAgICAgeGZzX2JtYnRfZ2V0X2Jsb2NrY291bnQoKTsKIDAp ICAgNy42NDUgdXMgICAgfCAgICAgICAgICAgICAgfQogMCkgICAwLjMyNSB1cyAgICB8ICAg ICAgICAgICAgICB4ZnNfaWV4dF9nZXRfZXh0KCk7CiAwKSAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgIHhmc19ibWJ0X2dldF9hbGwoKSB7CiAwKSAgIDAuMzI1IHVzICAgIHwgICAg ICAgICAgICAgICAgX194ZnNfYm1idF9nZXRfYWxsKCk7CiAwKSAgIDQuMDY3IHVzICAgIHwg ICAgICAgICAgICAgIH0KIDApICsgMjEuOTYwIHVzICAgfCAgICAgICAgICAgIH0KIDApICsg MjUuMzc2IHVzICAgfCAgICAgICAgICB9CiAwKSArIDMyLjY5NiB1cyAgIHwgICAgICAgIH0K IDApICAgMC42NTAgdXMgICAgfCAgICAgICAgeGZzX2l1bmxvY2soKTsKIDApICsgNDQuMjQ1 IHVzICAgfCAgICAgIH0KIDApICsgNTQuMDA1IHVzICAgfCAgICB9CiAwKSArIDU3Ljc0NyB1 cyAgIHwgIH0KIDApICAgICAgICAgICAgICAgfCAgeGZzX2ZpbGVfcmVsZWFzZSgpIHsKIDAp ICAgICAgICAgICAgICAgfCAgICB4ZnNfcmVsZWFzZSgpIHsKIDApICAgMC40ODggdXMgICAg fCAgICAgIHhmc19jYW5fZnJlZV9lb2ZibG9ja3MoKTsKIDApICAgICAgICAgICAgICAgfCAg ICAgIHhmc19mcmVlX2VvZmJsb2NrcygpIHsKIDApICAgMC44MTMgdXMgICAgfCAgICAgICAg eGZzX2lsb2NrKCk7CiAwKSAgICAgICAgICAgICAgIHwgICAgICAgIHhmc19ibWFwaV9yZWFk KCkgewogMCkgICAwLjMyNSB1cyAgICB8ICAgICAgICAgIHhmc19pc2lsb2NrZWQoKTsKIDAp ICAgICAgICAgICAgICAgfCAgICAgICAgICB4ZnNfYm1hcF9zZWFyY2hfZXh0ZW50cygpIHsK IDApICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHhmc19ibWFwX3NlYXJjaF9tdWx0aV9l eHRlbnRzKCkgewogMCkgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB4ZnNfaWV4dF9i bm9fdG9fZXh0KCkgewogMCkgICAwLjMyNiB1cyAgICB8ICAgICAgICAgICAgICAgIHhmc19i bWJ0X2dldF9zdGFydG9mZigpOwogMCkgICAwLjMyNSB1cyAgICB8ICAgICAgICAgICAgICAg IHhmc19ibWJ0X2dldF9ibG9ja2NvdW50KCk7CiAwKSAgIDcuNjQ1IHVzICAgIHwgICAgICAg ICAgICAgIH0KIDApICAgMC40ODggdXMgICAgfCAgICAgICAgICAgICAgeGZzX2lleHRfZ2V0 X2V4dCgpOwogMCkgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB4ZnNfYm1idF9nZXRf YWxsKCkgewogMCkgICAwLjMyNiB1cyAgICB8ICAgICAgICAgICAgICAgIF9feGZzX2JtYnRf Z2V0X2FsbCgpOwogMCkgICA0LjIyOSB1cyAgICB8ICAgICAgICAgICAgICB9CiAwKSArIDIy LjI4NSB1cyAgIHwgICAgICAgICAgICB9CiAwKSArIDI1LjcwMSB1cyAgIHwgICAgICAgICAg fQogMCkgKyAzMi42OTYgdXMgICB8ICAgICAgICB9CiAwKSAgIDAuNjUxIHVzICAgIHwgICAg ICAgIHhmc19pdW5sb2NrKCk7CiAwKSArIDQ0LjczMyB1cyAgIHwgICAgICB9CiAwKSArIDU0 LjMzMCB1cyAgIHwgICAgfQogMCkgKyA1Ny45MDkgdXMgICB8ICB9CiAwKSAgICAgICAgICAg ICAgIHwgIHhmc19maWxlX3JlbGVhc2UoKSB7CiAwKSAgICAgICAgICAgICAgIHwgICAgeGZz X3JlbGVhc2UoKSB7CiAwKSAgIDAuNjUxIHVzICAgIHwgICAgICB4ZnNfY2FuX2ZyZWVfZW9m YmxvY2tzKCk7CiAwKSAgICAgICAgICAgICAgIHwgICAgICB4ZnNfZnJlZV9lb2ZibG9ja3Mo KSB7CiAwKSAgIDAuNjUwIHVzICAgIHwgICAgICAgIHhmc19pbG9jaygpOwogMCkgICAgICAg ICAgICAgICB8ICAgICAgICB4ZnNfYm1hcGlfcmVhZCgpIHsKIDApICAgMC4xNjIgdXMgICAg fCAgICAgICAgICB4ZnNfaXNpbG9ja2VkKCk7CiAwKSAgICAgICAgICAgICAgIHwgICAgICAg ICAgeGZzX2JtYXBfc2VhcmNoX2V4dGVudHMoKSB7CiAwKSAgICAgICAgICAgICAgIHwgICAg ICAgICAgICB4ZnNfYm1hcF9zZWFyY2hfbXVsdGlfZXh0ZW50cygpIHsKIDApICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgeGZzX2lleHRfYm5vX3RvX2V4dCgpIHsKIDApICAgMC4z MjUgdXMgICAgfCAgICAgICAgICAgICAgICB4ZnNfYm1idF9nZXRfc3RhcnRvZmYoKTsKIDAp ICAgMC4zMjUgdXMgICAgfCAgICAgICAgICAgICAgICB4ZnNfYm1idF9nZXRfYmxvY2tjb3Vu dCgpOwogMCkgICA5LjExMCB1cyAgICB8ICAgICAgICAgICAgICB9CiAwKSAgIDAuMzI2IHVz ICAgIHwgICAgICAgICAgICAgIHhmc19pZXh0X2dldF9leHQoKTsKIDApICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgeGZzX2JtYnRfZ2V0X2FsbCgpIHsKIDApICAgMC4zMjUgdXMg ICAgfCAgICAgICAgICAgICAgICBfX3hmc19ibWJ0X2dldF9hbGwoKTsKIDApICAgNC4wNjcg dXMgICAgfCAgICAgICAgICAgICAgfQogMCkgKyAyMy43NTAgdXMgICB8ICAgICAgICAgICAg fQogMCkgKyAyNy4zMjggdXMgICB8ICAgICAgICAgIH0KIDApICsgMzQuNjQ4IHVzICAgfCAg ICAgICAgfQogMCkgICAwLjY1MSB1cyAgICB8ICAgICAgICB4ZnNfaXVubG9jaygpOwogMCkg KyA0Ni41MjIgdXMgICB8ICAgICAgfQogMCkgKyA1Ni4yODMgdXMgICB8ICAgIH0KIDApICsg NTkuODYxIHVzICAgfCAgfQogMCkgICAgICAgICAgICAgICB8ICB4ZnNfZmlsZV9yZWxlYXNl KCkgewogMCkgICAgICAgICAgICAgICB8ICAgIHhmc19yZWxlYXNlKCkgewogMCkgICAwLjQ4 OCB1cyAgICB8ICAgICAgeGZzX2Nhbl9mcmVlX2VvZmJsb2NrcygpOwogMCkgICAgICAgICAg ICAgICB8ICAgICAgeGZzX2ZyZWVfZW9mYmxvY2tzKCkgewogMCkgICAwLjgxNCB1cyAgICB8 ICAgICAgICB4ZnNfaWxvY2soKTsKIDApICAgICAgICAgICAgICAgfCAgICAgICAgeGZzX2Jt YXBpX3JlYWQoKSB7CiAwKSAgIDAuMzI1IHVzICAgIHwgICAgICAgICAgeGZzX2lzaWxvY2tl ZCgpOwogMCkgICAgICAgICAgICAgICB8ICAgICAgICAgIHhmc19ibWFwX3NlYXJjaF9leHRl bnRzKCkgewogMCkgICAgICAgICAgICAgICB8ICAgICAgICAgICAgeGZzX2JtYXBfc2VhcmNo X211bHRpX2V4dGVudHMoKSB7CiAwKSAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHhm c19pZXh0X2Jub190b19leHQoKSB7CiAwKSAgIDAuMzI2IHVzICAgIHwgICAgICAgICAgICAg ICAgeGZzX2JtYnRfZ2V0X3N0YXJ0b2ZmKCk7CiAwKSAgIDAuNDg4IHVzICAgIHwgICAgICAg ICAgICAgICAgeGZzX2JtYnRfZ2V0X2Jsb2NrY291bnQoKTsKIDApICAgNy44MDggdXMgICAg fCAgICAgICAgICAgICAgfQogMCkgICAwLjMyNSB1cyAgICB8ICAgICAgICAgICAgICB4ZnNf aWV4dF9nZXRfZXh0KCk7CiAwKSAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHhmc19i bWJ0X2dldF9hbGwoKSB7CiAwKSAgIDAuNDg4IHVzICAgIHwgICAgICAgICAgICAgICAgX194 ZnNfYm1idF9nZXRfYWxsKCk7CiAwKSAgIDMuOTA0IHVzICAgIHwgICAgICAgICAgICAgIH0K IDApICsgMjEuOTYwIHVzICAgfCAgICAgICAgICAgIH0KIDApICsgMjUuMzc2IHVzICAgfCAg ICAgICAgICB9CiAwKSArIDMyLjY5NiB1cyAgIHwgICAgICAgIH0KIDApICAgMC42NTEgdXMg ICAgfCAgICAgICAgeGZzX2l1bmxvY2soKTsKIDApICsgNDQuODk2IHVzICAgfCAgICAgIH0K IDApICsgNTQuNjU2IHVzICAgfCAgICB9CiAwKSArIDU4LjA3MiB1cyAgIHwgIH0KIDApICAg ICAgICAgICAgICAgfCAgeGZzX2ZpbGVfcmVsZWFzZSgpIHsKIDApICAgICAgICAgICAgICAg fCAgICB4ZnNfcmVsZWFzZSgpIHsKIDApICAgMC40ODggdXMgICAgfCAgICAgIHhmc19jYW5f ZnJlZV9lb2ZibG9ja3MoKTsKIDApICAgICAgICAgICAgICAgfCAgICAgIHhmc19mcmVlX2Vv ZmJsb2NrcygpIHsKIDApICAgMC42NTEgdXMgICAgfCAgICAgICAgeGZzX2lsb2NrKCk7CiAw KSAgICAgICAgICAgICAgIHwgICAgICAgIHhmc19ibWFwaV9yZWFkKCkgewogMCkgICAwLjMy NSB1cyAgICB8ICAgICAgICAgIHhmc19pc2lsb2NrZWQoKTsKIDApICAgICAgICAgICAgICAg fCAgICAgICAgICB4ZnNfYm1hcF9zZWFyY2hfZXh0ZW50cygpIHsKIDApICAgICAgICAgICAg ICAgfCAgICAgICAgICAgIHhmc19ibWFwX3NlYXJjaF9tdWx0aV9leHRlbnRzKCkgewogMCkg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB4ZnNfaWV4dF9ibm9fdG9fZXh0KCkgewog MCkgICAwLjE2MyB1cyAgICB8ICAgICAgICAgICAgICAgIHhmc19ibWJ0X2dldF9zdGFydG9m ZigpOwogMCkgICAwLjMyNSB1cyAgICB8ICAgICAgICAgICAgICAgIHhmc19ibWJ0X2dldF9i bG9ja2NvdW50KCk7CiAwKSAgIDcuODA4IHVzICAgIHwgICAgICAgICAgICAgIH0KIDApICAg MC4zMjUgdXMgICAgfCAgICAgICAgICAgICAgeGZzX2lleHRfZ2V0X2V4dCgpOwogMCkgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICB4ZnNfYm1idF9nZXRfYWxsKCkgewogMCkgICAw LjMyNSB1cyAgICB8ICAgICAgICAgICAgICAgIF9feGZzX2JtYnRfZ2V0X2FsbCgpOwogMCkg ICAzLjc0MiB1cyAgICB8ICAgICAgICAgICAgICB9CiAwKSArIDIxLjk2MCB1cyAgIHwgICAg ICAgICAgICB9CiAwKSArIDI1LjUzOSB1cyAgIHwgICAgICAgICAgfQogMCkgKyAzMi42OTYg dXMgICB8ICAgICAgICB9CiAwKSAgIDAuNjUxIHVzICAgIHwgICAgICAgIHhmc19pdW5sb2Nr KCk7CiAwKSArIDQ0LjczMyB1cyAgIHwgICAgICB9CiAwKSArIDU0LjQ5MyB1cyAgIHwgICAg fQogMCkgKyA1Ny45MDkgdXMgICB8ICB9CiAwKSAgIDAuODE0IHVzICAgIHwgIHhmc19maWxl X29wZW4oKTsKIDApICAgMC45NzYgdXMgICAgfCAgeGZzX3ZuX2dldGF0dHIoKTsKIDApICAg MS4xMzkgdXMgICAgfCAgeGZzX2ZpbGVfbW1hcCgpOwogMCkgICAgICAgICAgICAgICB8ICB4 ZnNfdm5fZm9sbG93X2xpbmsoKSB7CiAwKSAgICAgICAgICAgICAgIHwgICAgeGZzX3JlYWRs aW5rKCkgewogMCkgICAwLjY1MSB1cyAgICB8ICAgICAgeGZzX2lsb2NrKCk7CiAwKSAgIDAu NjUwIHVzICAgIHwgICAgICB4ZnNfaXVubG9jaygpOwogMCkgICA5LjQzNSB1cyAgICB8ICAg IH0KIDApICsgMTQuNDc3IHVzICAgfCAgfQogMCkgICAwLjY1MSB1cyAgICB8ICB4ZnNfZmls ZV9vcGVuKCk7CiAwKSAgICAgICAgICAgICAgIHwgIHhmc19maWxlX3JlYWRfaXRlcigpIHsK IDApICAgMC44MTQgdXMgICAgfCAgICB4ZnNfaWxvY2soKTsKIDApICAgMC44MTMgdXMgICAg fCAgICB4ZnNfaXVubG9jaygpOwogMCkgKyAxNy43MzEgdXMgICB8ICB9CiAwKSAgIDEuMTM4 IHVzICAgIHwgIHhmc19maWxlX2xsc2VlaygpOwogMCkgICAgICAgICAgICAgICB8ICB4ZnNf ZmlsZV9yZWFkX2l0ZXIoKSB7CiAwKSAgIDAuNjUwIHVzICAgIHwgICAgeGZzX2lsb2NrKCk7 CiAwKSAgIDAuODE0IHVzICAgIHwgICAgeGZzX2l1bmxvY2soKTsKIDApICsgMTguNzA3IHVz ICAgfCAgfQogMCkgICAwLjQ4OCB1cyAgICB8ICB4ZnNfZmlsZV9sbHNlZWsoKTsKIDApICAg ICAgICAgICAgICAgfCAgeGZzX2ZpbGVfcmVhZF9pdGVyKCkgewogMCkgICAwLjY1MSB1cyAg ICB8ICAgIHhmc19pbG9jaygpOwogMCkgICAwLjY1MCB1cyAgICB8ICAgIHhmc19pdW5sb2Nr KCk7CiAwKSArIDEyLjIwMCB1cyAgIHwgIH0KIDApICAgMC42NTEgdXMgICAgfCAgeGZzX3Zu X2dldGF0dHIoKTsKIDApICAgMC42NTEgdXMgICAgfCAgeGZzX2ZpbGVfbW1hcCgpOwogMCkg ICAwLjk3NiB1cyAgICB8ICB4ZnNfZmlsZV9tbWFwKCk7CiAwKSAgICAgICAgICAgICAgIHwg IHhmc19maWxlbWFwX2ZhdWx0KCkgewogMCkgICAwLjgxMyB1cyAgICB8ICAgIHhmc19pbG9j aygpOwogMCkgICAwLjY1MCB1cyAgICB8ICAgIHhmc19pdW5sb2NrKCk7CiAwKSArIDEwLjcz NiB1cyAgIHwgIH0KIDApICAgICAgICAgICAgICAgfCAgeGZzX2ZpbGVfcmVsZWFzZSgpIHsK IDApICAgICAgICAgICAgICAgfCAgICB4ZnNfcmVsZWFzZSgpIHsKIDApICAgMC40ODggdXMg ICAgfCAgICAgIHhmc19jYW5fZnJlZV9lb2ZibG9ja3MoKTsKIDApICAgICAgICAgICAgICAg fCAgICAgIHhmc19mcmVlX2VvZmJsb2NrcygpIHsKIDApICAgMC44MTMgdXMgICAgfCAgICAg ICAgeGZzX2lsb2NrKCk7CiAwKSAgICAgICAgICAgICAgIHwgICAgICAgIHhmc19ibWFwaV9y ZWFkKCkgewogMCkgICAwLjMyNiB1cyAgICB8ICAgICAgICAgIHhmc19pc2lsb2NrZWQoKTsK IDApICAgICAgICAgICAgICAgfCAgICAgICAgICB4ZnNfYm1hcF9zZWFyY2hfZXh0ZW50cygp IHsKIDApICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHhmc19ibWFwX3NlYXJjaF9tdWx0 aV9leHRlbnRzKCkgewogMCkgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB4ZnNfaWV4 dF9ibm9fdG9fZXh0KCkgewogMCkgICAwLjMyNiB1cyAgICB8ICAgICAgICAgICAgICAgIHhm c19ibWJ0X2dldF9zdGFydG9mZigpOwogMCkgICAwLjMyNSB1cyAgICB8ICAgICAgICAgICAg ICAgIHhmc19ibWJ0X2dldF9ibG9ja2NvdW50KCk7CiAwKSAgIDguMTMzIHVzICAgIHwgICAg ICAgICAgICAgIH0KIDApICAgMC4zMjUgdXMgICAgfCAgICAgICAgICAgICAgeGZzX2lleHRf Z2V0X2V4dCgpOwogMCkgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB4ZnNfYm1idF9n ZXRfYWxsKCkgewogMCkgICAwLjMyNiB1cyAgICB8ICAgICAgICAgICAgICAgIF9feGZzX2Jt YnRfZ2V0X2FsbCgpOwogMCkgICAzLjkwNCB1cyAgICB8ICAgICAgICAgICAgICB9CiAwKSAr IDIyLjI4NSB1cyAgIHwgICAgICAgICAgICB9CiAwKSArIDI1Ljg2NCB1cyAgIHwgICAgICAg ICAgfQogMCkgKyAzMy42NzIgdXMgICB8ICAgICAgICB9CiAwKSAgIDAuNjUwIHVzICAgIHwg ICAgICAgIHhmc19pdW5sb2NrKCk7CiAwKSArIDQ2LjUyMyB1cyAgIHwgICAgICB9CiAwKSAr IDU3LjQyMSB1cyAgIHwgICAgfQogMCkgKyA2MS40ODggdXMgICB8ICB9CiAwKSAgIDEuMTM4 IHVzICAgIHwgIHhmc192bl9nZXRhdHRyKCk7CiAwKSAgICAgICAgICAgICAgIHwgIHhmc192 bl91bmxpbmsoKSB7CiAwKSAgICAgICAgICAgICAgIHwgICAgeGZzX3JlbW92ZSgpIHsKIDAp ICAgICAgICAgICAgICAgfCAgICAgIHhmc190cmFuc19hbGxvYygpIHsKIDApICAgMS40NjQg dXMgICAgfCAgICAgICAgX3hmc190cmFuc19hbGxvYygpOwogMCkgICA2LjY2OSB1cyAgICB8 ICAgICAgfQogMCkgICAgICAgICAgICAgICB8ICAgICAgeGZzX3RyYW5zX3Jlc2VydmUoKSB7 CiAwKSAgIDEuNDY0IHVzICAgIHwgICAgICAgIHhmc19tb2RfZmRibG9ja3MoKTsKIDApICAg ICAgICAgICAgICAgfCAgICAgICAgeGZzX2xvZ19yZXNlcnZlKCkgewogMCkgICAwLjY1MCB1 cyAgICB8ICAgICAgICAgIHhmc19sb2dfY2FsY191bml0X3JlcygpOwogMCkgKyAxMy41MDEg dXMgICB8ICAgICAgICB9CiAwKSArIDIzLjI2MiB1cyAgIHwgICAgICB9CiAwKSAgIDAuOTc2 IHVzICAgIHwgICAgICB4ZnNfaWxvY2soKTsKIDApICAgICAgICAgICAgICAgfCAgICAgIHhm c19sb2NrX3R3b19pbm9kZXMoKSB7CiAwKSAgIDAuNjUxIHVzICAgIHwgICAgICAgIHhmc19p bG9jaygpOwogMCkgICAwLjk3NiB1cyAgICB8ICAgICAgICB4ZnNfaWxvY2tfbm93YWl0KCk7 CiAwKSAgIDkuMTEwIHVzICAgIHwgICAgICB9CiAwKSAgIDAuMzI2IHVzICAgIHwgICAgICB4 ZnNfaXNpbG9ja2VkKCk7CiAwKSAgIDEuNDY0IHVzICAgIHwgICAgICB4ZnNfdHJhbnNfYWRk X2l0ZW0oKTsKIDApICAgMC40ODggdXMgICAgfCAgICAgIHhmc19pc2lsb2NrZWQoKTsKIDAp ICAgMS4zMDEgdXMgICAgfCAgICAgIHhmc190cmFuc19hZGRfaXRlbSgpOwogMCkgICAwLjQ4 OCB1cyAgICB8ICAgICAgeGZzX2lzaWxvY2tlZCgpOwogMCkgICAwLjE2MyB1cyAgICB8ICAg ICAgeGZzX2lzaWxvY2tlZCgpOwogMCkgICAgICAgICAgICAgICB8ICAgICAgeGZzX2Ryb3Bs aW5rKCkgewogMCkgICAwLjMyNSB1cyAgICB8ICAgICAgICB4ZnNfaXNpbG9ja2VkKCk7CiAw KSAgIDAuMzI2IHVzICAgIHwgICAgICAgIHhmc19pc2lsb2NrZWQoKTsKIDApICAgICAgICAg ICAgICAgfCAgICAgICAgeGZzX2l1bmxpbmsoKSB7CiAwKSAgICAgICAgICAgICAgIHwgICAg ICAgICAgeGZzX3JlYWRfYWdpKCkgewogMCkgICAgICAgICAgICAgICB8ICAgICAgICAgICAg eGZzX2J1Zl9yZWFkX21hcCgpIHsKIDApICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg eGZzX2J1Zl9nZXRfbWFwKCkgewogMCkgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg IF94ZnNfYnVmX2ZpbmQoKSB7CiAwKSAgIDEuMzAxIHVzICAgIHwgICAgICAgICAgICAgICAg ICB4ZnNfcGVyYWdfZ2V0KCk7CiAwKSAgIDAuNjUxIHVzICAgIHwgICAgICAgICAgICAgICAg ICB4ZnNfcGVyYWdfcHV0KCk7CiAwKSAgIDEuMzAyIHVzICAgIHwgICAgICAgICAgICAgICAg ICB4ZnNfYnVmX3RyeWxvY2soKTsKIDApICsgMTYuNzU0IHVzICAgfCAgICAgICAgICAgICAg ICB9CiAwKSArIDIwLjk4NCB1cyAgIHwgICAgICAgICAgICAgIH0KIDApICsgMjUuMDUxIHVz ICAgfCAgICAgICAgICAgIH0KIDApICAgMS4zMDEgdXMgICAgfCAgICAgICAgICAgIHhmc190 cmFuc19hZGRfaXRlbSgpOwogMCkgKyAzNC45NzQgdXMgICB8ICAgICAgICAgIH0KIDApICsg NDAuOTkyIHVzICAgfCAgICAgICAgfQogMCkgKyA1NC42NTYgdXMgICB8ICAgICAgfQogMCkg ICAgICAgICAgICAgICB8ICAgICAgeGZzX2Rpcl9yZW1vdmVuYW1lKCkgewogMCkgICAgICAg ICAgICAgICB8ICAgICAgICB4ZnNfZGVmYXVsdF9oYXNobmFtZSgpIHsKIDApICAgMC4zMjUg dXMgICAgfCAgICAgICAgICB4ZnNfZGFfaGFzaG5hbWUoKTsKIDApICAgNC4zOTIgdXMgICAg fCAgICAgICAgfQogMCkgICAgICAgICAgICAgICB8ICAgICAgICB4ZnNfZGlyMl9zZl9yZW1v dmVuYW1lKCkgewogMCkgICAwLjY1MSB1cyAgICB8ICAgICAgICAgIHhmc19kYV9jb21wbmFt ZSgpOwogMCkgICAgICAgICAgICAgICB8ICAgICAgICAgIHhmc19kaXIyX3NmZV9nZXRfaW5v KCkgewogMCkgICAwLjMyNiB1cyAgICB8ICAgICAgICAgICAgeGZzX2RpcjJfc2ZfZ2V0X2lu by5pc3JhLjgoKTsKIDApICAgNC4wNjYgdXMgICAgfCAgICAgICAgICB9CiAwKSAgIDAuNDg4 IHVzICAgIHwgICAgICAgICAgeGZzX2RpcjJfc2ZfZW50c2l6ZSgpOwogMCkgICAwLjY1MSB1 cyAgICB8ICAgICAgICAgIHhmc19pZGF0YV9yZWFsbG9jKCk7CiAwKSAgICAgICAgICAgICAg IHwgICAgICAgICAgeGZzX2RpcjJfc2ZfY2hlY2suaXNyYS42KCkgewogMCkgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgeGZzX2RpcjJfc2ZfZ2V0X3BhcmVudF9pbm8oKSB7CiAwKSAg IDAuMzI1IHVzICAgIHwgICAgICAgICAgICAgIHhmc19kaXIyX3NmX2dldF9pbm8uaXNyYS44 KCk7CiAwKSAgIDMuOTA0IHVzICAgIHwgICAgICAgICAgICB9CiAwKSAgIDcuOTcxIHVzICAg IHwgICAgICAgICAgfQogMCkgICAwLjMyNiB1cyAgICB8ICAgICAgICAgIHhmc19pc2lsb2Nr ZWQoKTsKIDApICsgMzYuNjAwIHVzICAgfCAgICAgICAgfQogMCkgKyA1My4wMzAgdXMgICB8 ICAgICAgfQogMCkgICAwLjQ4OCB1cyAgICB8ICAgICAgeGZzX2JtYXBfZmluaXNoKCk7CiAw KSAgICAgICAgICAgICAgIHwgICAgICB4ZnNfdHJhbnNfY29tbWl0KCkgewogMCkgICAwLjMy NiB1cyAgICB8ICAgICAgICB4ZnNfaXNpbG9ja2VkKCk7CiAwKSAgICAgICAgICAgICAgIHwg ICAgICAgIHhmc19pZXh0ZW50c19jb3B5KCkgewogMCkgICAwLjQ4OCB1cyAgICB8ICAgICAg ICAgIHhmc19pc2lsb2NrZWQoKTsKIDApICAgMC40ODggdXMgICAgfCAgICAgICAgICB4ZnNf Ym1hcF90cmFjZV9leGxpc3QoKTsKIDApICAgMC4zMjUgdXMgICAgfCAgICAgICAgICB4ZnNf aWV4dF9nZXRfZXh0KCk7CiAwKSAgIDAuNDg4IHVzICAgIHwgICAgICAgICAgeGZzX2JtYnRf Z2V0X3N0YXJ0YmxvY2soKTsKIDApICAgICAgICAgICAgICAgfCAgICAgICAgICB4ZnNfdmFs aWRhdGVfZXh0ZW50cygpIHsKIDApICAgMC4zMjYgdXMgICAgfCAgICAgICAgICAgIHhmc19p ZXh0X2dldF9leHQoKTsKIDApICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHhmc19ibWJ0 X2dldF9hbGwoKSB7CiAwKSAgIDAuMzI1IHVzICAgIHwgICAgICAgICAgICAgIF9feGZzX2Jt YnRfZ2V0X2FsbCgpOwogMCkgICAzLjkwNCB1cyAgICB8ICAgICAgICAgICAgfQogMCkgKyAx MS4yMjQgdXMgICB8ICAgICAgICAgIH0KIDApICsgMzAuNzQ0IHVzICAgfCAgICAgICAgfQog MCkgICAwLjE2MyB1cyAgICB8ICAgICAgICB4ZnNfaXNpbG9ja2VkKCk7CiAwKSAgIDAuNDg4 IHVzICAgIHwgICAgICAgIHhmc19uZXh0X2JpdCgpOwogMCkgICAwLjMyNiB1cyAgICB8ICAg ICAgICB4ZnNfbmV4dF9iaXQoKTsKIDApICAgMC4zMjUgdXMgICAgfCAgICAgICAgeGZzX25l eHRfYml0KCk7CiAwKSAgIDAuMzI1IHVzICAgIHwgICAgICAgIHhmc19uZXh0X2JpdCgpOwog MCkgICAwLjQ4OCB1cyAgICB8ICAgICAgICB4ZnNfYnVmX29mZnNldCgpOwogMCkgICAgICAg ICAgICAgICB8ICAgICAgICB4ZnNfbG9nX2RvbmUoKSB7CiAwKSAgIDAuNDg4IHVzICAgIHwg ICAgICAgICAgeGZzX2xvZ19zcGFjZV93YWtlKCk7CiAwKSAgIDEuMzAyIHVzICAgIHwgICAg ICAgICAgeGZzX2xvZ190aWNrZXRfcHV0KCk7CiAwKSArIDEyLjUyNSB1cyAgIHwgICAgICAg IH0KIDApICAgICAgICAgICAgICAgfCAgICAgICAgeGZzX3RyYW5zX3VucmVzZXJ2ZV9hbmRf bW9kX3NiKCkgewogMCkgICAxLjEzOCB1cyAgICB8ICAgICAgICAgIHhmc19tb2RfZmRibG9j a3MoKTsKIDApICAgNS4wNDMgdXMgICAgfCAgICAgICAgfQogMCkgICAgICAgICAgICAgICB8 ICAgICAgICB4ZnNfdHJhbnNfZnJlZV9pdGVtcygpIHsKIDApICAgMC40ODggdXMgICAgfCAg ICAgICAgICB4ZnNfaXNpbG9ja2VkKCk7CiAwKSAgIDEuMzAyIHVzICAgIHwgICAgICAgICAg eGZzX2l1bmxvY2soKTsKIDApICAgMS4zMDIgdXMgICAgfCAgICAgICAgICB4ZnNfdHJhbnNf ZnJlZV9pdGVtX2Rlc2MoKTsKIDApICAgMC40ODggdXMgICAgfCAgICAgICAgICB4ZnNfaXNp bG9ja2VkKCk7CiAwKSAgIDAuNjUxIHVzICAgIHwgICAgICAgICAgeGZzX2l1bmxvY2soKTsK IDApICAgMS4zMDEgdXMgICAgfCAgICAgICAgICB4ZnNfdHJhbnNfZnJlZV9pdGVtX2Rlc2Mo KTsKIDApICAgMS4zMDEgdXMgICAgfCAgICAgICAgICB4ZnNfYnVmX3VubG9jaygpOwogMCkg ICAwLjgxNCB1cyAgICB8ICAgICAgICAgIHhmc19idWZfcmVsZSgpOwogMCkgICAwLjk3NiB1 cyAgICB8ICAgICAgICAgIHhmc190cmFuc19mcmVlX2l0ZW1fZGVzYygpOwogMCkgISAxMzUu MTc2IHVzICB8ICAgICAgICB9CiAwKSAgICAgICAgICAgICAgIHwgICAgICAgIHhmc190cmFu c19mcmVlKCkgewogMCkgICAwLjMyNSB1cyAgICB8ICAgICAgICAgIHhmc19leHRlbnRfYnVz eV9jbGVhcigpOwogMCkgICA1LjY5NCB1cyAgICB8ICAgICAgICB9CiAwKSAhIDI0Ny4wOTAg dXMgIHwgICAgICB9CiAwKSAhIDQ1Mi43MDIgdXMgIHwgICAgfQogMCkgISA0NTcuMjU2IHVz ICB8ICB9CiAwKSAgIDAuNDg4IHVzICAgIHwgIHhmc19mc19kcm9wX2lub2RlKCk7CiAwKSAg ICAgICAgICAgICAgIHwgIHhmc19mc19ldmljdF9pbm9kZSgpIHsKCgo= --------------000101010701030200020700-- From 2kx_dhh.h57.1db@audienceoneline.com Sat Sep 26 23:22:16 2015 Return-Path: <2kx_dhh.h57.1db@audienceoneline.com> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=HTML_IMAGE_RATIO_04, HTML_MESSAGE,T_DKIM_INVALID,T_REMOTE_IMAGE autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 7B6CB7F47 for ; Sat, 26 Sep 2015 23:22:16 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 552368F8035 for ; Sat, 26 Sep 2015 21:22:12 -0700 (PDT) X-ASG-Debug-ID: 1443327727-04cb6c6b07100740001-NocioJ Received: from smtp-a16.wesszing.com (smtp-a16.wesszing.com [82.97.40.200]) by cuda.sgi.com with ESMTP id fA7aqwRsoHhrJOo2 for ; Sat, 26 Sep 2015 21:22:07 -0700 (PDT) X-Barracuda-Envelope-From: 2kx_dhh.h57.1db@audienceoneline.com X-Barracuda-Apparent-Source-IP: 82.97.40.200 DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=audienceoneline.com; h=to :subject:date:from:reply-to:list-unsubscribe:message-id :mime-version:content-type; s=smtp; bh=v3+2FJZ8Ss5f2NwWQqCxsTz6W 7w=; b=ezsRjtu4oqEYxJ4l9K2XursQU2PuJvh6Dzf4luCMVCROAVcXbGEVNt5ab g5iMA5kVSbqTtZV4xqGSby7xTg6ePQmmSJwW5xkREeKOH8zUgpNntTpX/dtpW10b jIW1SYFoggnwPTUVdyGHYtjHE1DLzB2mH70AgZgw6sqh/9T1Co= DomainKey-Signature: a=rsa-sha1; c=simple; d=audienceoneline.com; h=to :subject:date:from:reply-to:list-unsubscribe:message-id :mime-version:content-type; q=dns; s=smtp; b=ARtbliSpk4C5Xf2vVIc 54MSYgHzpjxsuOniCxaGrrZ7Rns4AvJTZ1+NwPn7ttP/Cs8qhrpECW2e5bv5vKco O+/Id3gqXgghYIezvWKj8cfj6T7Yb9h/UuPFSnK3Ss6LmBZTUMO2xtn3Bj+1FViU q5qgw6mJoxlvpJPL70frQOws= To: xfs Subject: =?utf-8?Q?Faites_des_=C3=A9conomies_de_chauffages_!_B=C3=A9n=C3=A9ficiez_?= =?utf-8?Q?d\'un_cr=C3=A9dit_d\'imp=C3=B4ts_pour_votre_po=C3=AAle_=C3=A0_g?= =?utf-8?Q?ranul=C3=A9s_!_=C3=89conomisez_jusqu\'=C3=A0_300=E2=82=AC_sur_v?= =?utf-8?Q?otre_facture_de_chauffage_!?= Date: Sun, 27 Sep 2015 06:20:32 +0200 X-ASG-Orig-Subj: =?utf-8?Q?Faites_des_=C3=A9conomies_de_chauffages_!_B=C3=A9n=C3=A9ficiez_?= =?utf-8?Q?d\'un_cr=C3=A9dit_d\'imp=C3=B4ts_pour_votre_po=C3=AAle_=C3=A0_g?= =?utf-8?Q?ranul=C3=A9s_!_=C3=89conomisez_jusqu\'=C3=A0_300=E2=82=AC_sur_v?= =?utf-8?Q?otre_facture_de_chauffage_!?= From: POELE A GRANULE Reply-to: POELE A GRANULE <2kx_dhh.h57.1db@audienceoneline.com> X-campaign_id: 884450290924205_2 X-uid_id_m: eGZzQG9zcy5zZ2kuY29t=25 List-Unsubscribe: Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Part1_e88ce6faa156c61ecb7e3a2fca68aec6" X-Barracuda-Connect: smtp-a16.wesszing.com[82.97.40.200] X-Barracuda-Start-Time: 1443327727 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.17 X-Barracuda-Spam-Status: No, SCORE=0.17 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_IMAGE_RATIO_04, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22933 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.17 HTML_IMAGE_RATIO_04 BODY: HTML has a low ratio of text to image area 0.00 HTML_MESSAGE BODY: HTML included in message --Part1_e88ce6faa156c61ecb7e3a2fca68aec6 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: quoted-printable Pour visualiser et se d=C3=A9sabonner ce message, =20 Veuillez, copier puis coller, l'adresse URL compl=C3=A8te ci-dessous dans= la barre d'adresse de votre navigateur et appuyer sur la touche "Entr=C3=A9e= " de votre clavier. - - - - - - - - - - - - - - - - -=20 http://app.audienceoneline.com/v/?camp=3D884450290924205_2&ms=3DeGZzQG9zc= y5zZ2kuY29t - - - - - - - - - - - - - - - - -=20 --Part1_e88ce6faa156c61ecb7e3a2fca68aec6 Content-Type: text/html; charset = "utf-8" Content-Transfer-Encoding: quoted-printable Faites des =C3=A9conomies de chauffages ! B=C3=A9n=C3=A9ficiez d\\= \'un cr=C3=A9dit d\\\'imp=C3=B4ts pour votre po=C3=AAle =C3=A0 granul=C3=A9= s ! =C3=89conomisez jusqu\\\'=C3=A0 300=E2=82=AC sur votre facture de cha= uffage !

Si cet email ne s&rsqu= o;affiche pas correctement, suivez ce lien.

= Étude gratuite et personnalisée
< /table>
= = =
=20 =
= 3D"Poêle = Poêle à granulés =20
= 3D"Poêle
<= table class=3D"row" style=3D"border-spacing: 0; border-collapse: collapse= ; width: 100%; position: relative; display: block; padding: 0px;">
<= /tr>
=

Le poêle à = granulés est la version moderne du poêle à bois tradi= tionnel. C'est un appareil garant= issant un chauffage optimal, semblable au chauffage au bois et sans les c= ontraintes qui lui incombent. Son utilisation facile et son fort rendement lui prédisent un= bel avenir. =

=
=
=
= Obtenir gratuitement un= devis ! =20
<= /td>

=
=

= = = En 2015, profitez de nombreux avantages ! =20 =

=
=20 =

Crédit d&rsqu= o;impôt

Déduisez 30 % de= l’installation sur votre prochaine declaration = 		= =

Prime éne= rgie

Recevez de 100 à= ; 1 000€ en chèque prime énergie = =20 		= =

&Eacu= te;conomique

Jusqu' à 300€ d'économie annuelle sur votre chauffage = =
3D"_pspacer4"

Pour se désabonner : Suivez ce= lien.
Si ce message vous a causé un quelconque dé= rangement, nous vous prions de nous en excuser.

--Part1_e88ce6faa156c61ecb7e3a2fca68aec6-- From information@insided484.eu Mon Sep 28 08:20:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 0A8877F37 for ; Mon, 28 Sep 2015 08:20:48 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id E24DE304062 for ; Mon, 28 Sep 2015 06:20:44 -0700 (PDT) X-ASG-Debug-ID: 1443446438-04cbb033b313da90001-NocioJ Received: from vps.unique55.eu (vps.unique55.eu [185.13.38.200]) by cuda.sgi.com with ESMTP id wvYeh1rGUllbGYKG (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 06:20:39 -0700 (PDT) X-Barracuda-Envelope-From: information@insided484.eu X-Barracuda-Apparent-Source-IP: 185.13.38.200 Received: from [127.0.0.1] (unknown [91.236.239.116]) (Authenticated sender: mail@insided484.eu) by vps.unique55.eu (Postfix) with ESMTPA id 970F225E9E for ; Mon, 28 Sep 2015 13:20:37 +0000 (UTC) Date: Mon, 28 Sep 2015 13:20:37 +0000 From: Sokool To: xfs@oss.sgi.com Reply-to: Sokool User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/6.0; Microsoft Outlook 15.0.4420) MIME-Version: 1.0 Subject: Catalogue des Abris de Piscine SOKOOL Content-Type: multipart/alternative; boundary="------------080508090304070408050407" X-ASG-Orig-Subj: Catalogue des Abris de Piscine SOKOOL X-Barracuda-Connect: vps.unique55.eu[185.13.38.200] X-Barracuda-Start-Time: 1443446439 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.14 X-Barracuda-Spam-Status: No, SCORE=0.14 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE, MISSING_MID, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22976 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 MISSING_MID Missing Message-Id: header 0.00 NO_REAL_NAME From: does not include a real name 0.00 HTML_MESSAGE BODY: HTML included in message Message-Id: <20150928132044.8D505106C844@cuda.sgi.com> This is a multi-part message in MIME format. --------------080508090304070408050407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Catalogue des Abris de Piscine SOKOOL Avec SOKOOL, le leader français de l'abri téléscopique sur mesure, vous profiterez pleinement des plaisirs de votre piscine toute l'année. SOKOOL, c'est deux usines en France, et des techniciens professionnels à votre écoute. Avec 30 d'expérience dans la fabrication des abris de piscine, SOKOOL c'est votre garantie d'être satisfait. Voici le lien pour obtenir gratuitement le catalogue SOKOOL. Merci pour votre écoute. L'équipe SOKOOL. 01.73.79.07.63 Pour retirer votre adresse email, c'est la --------------080508090304070408050407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Catalogue des Abris de Piscine SOKOOL

Avec SOKOOL, le leader français de l'abri téléscopique sur mesure,
vous profiterez pleinement des plaisirs de votre piscine toute l'année.

SOKOOL, c'est deux usines en France, et des techniciens professionnels à votre écoute.
Avec 30 d'expérience dans la fabrication des abris de piscine, SOKOOL c'est votre garantie d'être satisfait.

Voici le lien pour obtenir gratuitement le catalogue SOKOOL.

Merci pour votre écoute.

L'équipe SOKOOL.
01.73.79.07.63

Pour retirer votre adresse email, c'est la

 

 

 

--------------080508090304070408050407-- From sandeen@sandeen.net Mon Sep 28 10:00:51 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 349827F37 for ; Mon, 28 Sep 2015 10:00:51 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 231C48F8052 for ; Mon, 28 Sep 2015 08:00:47 -0700 (PDT) X-ASG-Debug-ID: 1443452445-04cb6c6b051272e0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id uiYC6MehXuV8AhET for ; Mon, 28 Sep 2015 08:00:45 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 23D6E6BAE239 for ; Mon, 28 Sep 2015 10:00:45 -0500 (CDT) Subject: Re: [PATCH 0/7 v8] xfs: stats in sysfs To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/7 v8] xfs: stats in sysfs References: <1443223380-18870-1-git-send-email-billodo@redhat.com> From: Eric Sandeen X-Enigmail-Draft-Status: N1110 Message-ID: <5609561C.5040508@sandeen.net> Date: Mon, 28 Sep 2015 10:00:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1443223380-18870-1-git-send-email-billodo@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1443452445 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22978 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/25/15 6:22 PM, Bill O'Donnell wrote: > > Hello- > > Following is the next iteration of the series to add xfs stats to > sysfs. This iteration adds patches 6 and 7 to complete the incorporation > of sysfs/kobject into xfsstats, including working global and per-fs stats. Hi Bill - as I mentioned on IRC, it looks like a lot of the patches in this series fix up review comments for *prior* patches; i.e. Patch X implements a change X, and got review comments when originally submitted. Then Patch Y introduces change Y, but also fixes up comments in Patch X. When you get review comments, they really need to be fixed up in that patch, not later in the patch series. This is for two reasons; for one, we really want each committed patch to be correct stylistically and functionally. And two, it simplifies review of the series; one doesn't need to look forward in the series to find fixes for prior patches, and each patch contains only its own functional changes, not unrelated fixups for prior patches. So for example, if you have a patch which is fixing whitespace on code introduced in a previous patch, it's in the wrong patch. Or for a more concrete example, in patch 5 you do: for_each_possible_cpu(cpu) - val += *(((__u32 *)&per_cpu(xfsstats, cpu) + idx)); + val += *(((__u32 *)&per_cpu(*stats, cpu) + idx)); return val; and then in patch 6 you do: for_each_possible_cpu(cpu) - val += *(((__u32 *)&per_cpu(*stats, cpu) + idx)); return val; But this is unrelated to the purpose of patch 6; it should just be fixed up in a modified patch 5, i.e. for_each_possible_cpu(cpu) - val += *(((__u32 *)&per_cpu(xfsstats, cpu) + idx)); + val += *(((__u32 *)per_cpu_ptr(stats, cpu) + idx)); return val; So I'll restrict review comments to the actual end product, rather than patch by patch, because it's tough to review patch X when it has issues whichi are fixed up by patch X+1 or X+2 or ... :) If you have any questions about all this, please let me know. Thanks, -Eric > ----------history--------------- > v8: (add patches 6 and 7) > -patch 6: per-filesystem stats in sysfs. > Implement per-filesystem stats objects in sysfs. Stats objects are > instantiated when an xfs filesystem is mounted and deleted on unmount. > With this patch, the stats directory is created and populated with > the familiar stats and stats_clear files. > Example: > /sys/fs/xfs/sda9/stats/stats > /sys/fs/xfs/sda9/stats/stats_clear > > With this patch, the individual counts within the new per-fs > stats file(s) remain at zero. Functions that use the the macros > to increment, decrement, and add-to the per-fs stats counts will > be covered in the next patch (7). > > Also, this patch includes some minor fixups for style issues in > patch 5. > > > -patch 7: per-filesystem stats counter implementation > Modify the stats counting macros and the callers > to those macros to properly increment, decrement, and add-to > the xfs stats counts. The counts for global and per-fs stats > are correctly advanced, and cleared by writing a "1" to the > corresponding clear file. > > global counts: /sys/fs/xfs/stats/stats > per-fs counts: /sys/fs/xfs/sda*/stats/stats > > global clear: /sys/fs/xfs/stats/stats_clear > per-fs clear: /sys/fs/xfs/sda*/stats/stats_clear > > > v7: > add patch 5/5: incorporate sysfs/kobject in xfsstats: handlers > take kobjects. Allocate & deallocate per-fs stats structures > and set up the sysfs entries for them. Add kobject and a pointer > to a per-cpu struct xfsstats. Modify the macros that manipulate > the stats accordingly. > > v6: > -add patch 4/4: move to_xlog(kobject) to the relevant show/store > operations. This keeps the xfs_sysfs_object_show/store functions > generic. Also, with the change, there can be some cleanup of the > show/store function arguments. > > v5: > -optimization of sysfs_ops function. > -style fixups > > v4: > -whitespace fixup of patch 1 > -add patch 4 (sysfs ops consolidation - dbg, stats, log) > > v3: > -style fixups and removal of extraneous printk. > > v2: > -style fixups. > v1: > -------------------------------- > > We already have per-fs information in /sys, so it makes sense to > have per-fs stats there too. The series moves existing > global stats infrastructure to /sys and reuses that code to > create per-fs stats in /sys. > > Patch 1 handles the bring-up and tear down of xfs/stats directory > structure in sysfs when an fs is mounted. The directory contains > the stats file and the stats_clear file. The stats file contents mimic > those of /proc/fs/xfs/stat. The stats_clear file is empty, and much > like the current stat_clear command, handles the zeroing of the stats > file when a "1" is echoed to the stats_clear file. > > Patch 2 creates the symlink for stats from procfs to sysfs. > > Patch 3 removes the now unused portions of procfs for stat. > > Patch 4 consolidates the sysfs ops for dbg, stats, log. > > Patch 5 allocates and deallocates per-fs stats structures and > sets up the sysfs entries for them. Add kobject and a pointer > to a per-cpu struct xfsstats. Modify the macros that manipulate > the stats accordingly. > > Patch 6 implements per-filesystem stats objects in sysfs. Stats > objects are instantiated when an xfs filesystem is mounted and > deleted on unmount. > > Patch 7 modifies the stats counting macros and the callers > to those macros to properly increment, decrement, and add-to > the xfs stats counts. The counts for global and per-fs stats > are correctly advanced, and cleared by writing a "1" to the > corresponding clear file. > > Once again, comments and questions are welcome. > > Thanks- > Bill > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From sandeen@sandeen.net Mon Sep 28 10:02:01 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 038B37F37 for ; Mon, 28 Sep 2015 10:02:01 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id E515E30404E for ; Mon, 28 Sep 2015 08:01:57 -0700 (PDT) X-ASG-Debug-ID: 1443452516-04cbb033b3141620001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id immG6iyFBvPhjzRe for ; Mon, 28 Sep 2015 08:01:56 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 236E56BAE239 for ; Mon, 28 Sep 2015 10:01:56 -0500 (CDT) Subject: Re: [PATCH 0/7 v8] xfs: stats in sysfs To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 0/7 v8] xfs: stats in sysfs References: <1443223380-18870-1-git-send-email-billodo@redhat.com> <5609561C.5040508@sandeen.net> From: Eric Sandeen Message-ID: <56095663.6080609@sandeen.net> Date: Mon, 28 Sep 2015 10:01:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5609561C.5040508@sandeen.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1443452516 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22979 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- oops, lost a line, should have been: On 9/28/15 10:00 AM, Eric Sandeen wrote: > Or for a more concrete example, in patch 5 you do: > for_each_possible_cpu(cpu) > - val += *(((__u32 *)&per_cpu(xfsstats, cpu) + idx)); > + val += *(((__u32 *)&per_cpu(*stats, cpu) + idx)); > return val; > > and then in patch 6 you do: > > for_each_possible_cpu(cpu) > - val += *(((__u32 *)&per_cpu(*stats, cpu) + idx)); > + val += *(((__u32 *)per_cpu_ptr(stats, cpu) + idx)); > > return val; > > But this is unrelated to the purpose of patch 6; it should just be fixed > up in a modified patch 5, i.e. > > for_each_possible_cpu(cpu) > - val += *(((__u32 *)&per_cpu(xfsstats, cpu) + idx)); > + val += *(((__u32 *)per_cpu_ptr(stats, cpu) + idx)); > return val; From billodo@redhat.com Mon Sep 28 10:06:56 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E515F7F37 for ; Mon, 28 Sep 2015 10:06:55 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 7DF2AAC007 for ; Mon, 28 Sep 2015 08:06:52 -0700 (PDT) X-ASG-Debug-ID: 1443452810-04bdf04622130e30001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 8C55oMswkbo1jBnz (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 08:06:51 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id C7DA3A19BB; Mon, 28 Sep 2015 15:06:50 +0000 (UTC) Received: from redhat.com (vpn-55-26.rdu2.redhat.com [10.10.55.26]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SF6m1j023675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Sep 2015 11:06:50 -0400 Date: Mon, 28 Sep 2015 10:06:48 -0500 From: "Bill O'Donnell" To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH 0/7 v8] xfs: stats in sysfs Message-ID: <20150928150647.GA17514@redhat.com> X-ASG-Orig-Subj: Re: [PATCH 0/7 v8] xfs: stats in sysfs References: <1443223380-18870-1-git-send-email-billodo@redhat.com> <5609561C.5040508@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5609561C.5040508@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443452811 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Mon, Sep 28, 2015 at 10:00:44AM -0500, Eric Sandeen wrote: > On 9/25/15 6:22 PM, Bill O'Donnell wrote: > > > > Hello- > > > > Following is the next iteration of the series to add xfs stats to > > sysfs. This iteration adds patches 6 and 7 to complete the incorporation > > of sysfs/kobject into xfsstats, including working global and per-fs stats. > > Hi Bill - as I mentioned on IRC, it looks like a lot of the patches in this > series fix up review comments for *prior* patches; i.e. Patch X implements > a change X, and got review comments when originally submitted. > > Then Patch Y introduces change Y, but also fixes up comments in Patch X. > > When you get review comments, they really need to be fixed up in that > patch, not later in the patch series. This is for two reasons; for one, > we really want each committed patch to be correct stylistically and > functionally. And two, it simplifies review of the series; one doesn't > need to look forward in the series to find fixes for prior patches, and > each patch contains only its own functional changes, not unrelated fixups > for prior patches. > > So for example, if you have a patch which is fixing whitespace on code > introduced in a previous patch, it's in the wrong patch. > > Or for a more concrete example, in patch 5 you do: > > for_each_possible_cpu(cpu) > - val += *(((__u32 *)&per_cpu(xfsstats, cpu) + idx)); > + val += *(((__u32 *)&per_cpu(*stats, cpu) + idx)); > return val; > > and then in patch 6 you do: > > for_each_possible_cpu(cpu) > - val += *(((__u32 *)&per_cpu(*stats, cpu) + idx)); > > return val; > > But this is unrelated to the purpose of patch 6; it should just be fixed > up in a modified patch 5, i.e. > > for_each_possible_cpu(cpu) > - val += *(((__u32 *)&per_cpu(xfsstats, cpu) + idx)); > + val += *(((__u32 *)per_cpu_ptr(stats, cpu) + idx)); > return val; > > So I'll restrict review comments to the actual end product, rather than > patch by patch, because it's tough to review patch X when it has issues > whichi are fixed up by patch X+1 or X+2 or ... :) > > If you have any questions about all this, please let me know. I'm doing another iteration of the series, and it will reflect your comments and advice. Thanks- Bill > > Thanks, > -Eric > > > > > ----------history--------------- > > v8: (add patches 6 and 7) > > -patch 6: per-filesystem stats in sysfs. > > Implement per-filesystem stats objects in sysfs. Stats objects are > > instantiated when an xfs filesystem is mounted and deleted on unmount. > > With this patch, the stats directory is created and populated with > > the familiar stats and stats_clear files. > > Example: > > /sys/fs/xfs/sda9/stats/stats > > /sys/fs/xfs/sda9/stats/stats_clear > > > > With this patch, the individual counts within the new per-fs > > stats file(s) remain at zero. Functions that use the the macros > > to increment, decrement, and add-to the per-fs stats counts will > > be covered in the next patch (7). > > > > Also, this patch includes some minor fixups for style issues in > > patch 5. > > > > > > -patch 7: per-filesystem stats counter implementation > > Modify the stats counting macros and the callers > > to those macros to properly increment, decrement, and add-to > > the xfs stats counts. The counts for global and per-fs stats > > are correctly advanced, and cleared by writing a "1" to the > > corresponding clear file. > > > > global counts: /sys/fs/xfs/stats/stats > > per-fs counts: /sys/fs/xfs/sda*/stats/stats > > > > global clear: /sys/fs/xfs/stats/stats_clear > > per-fs clear: /sys/fs/xfs/sda*/stats/stats_clear > > > > > > v7: > > add patch 5/5: incorporate sysfs/kobject in xfsstats: handlers > > take kobjects. Allocate & deallocate per-fs stats structures > > and set up the sysfs entries for them. Add kobject and a pointer > > to a per-cpu struct xfsstats. Modify the macros that manipulate > > the stats accordingly. > > > > v6: > > -add patch 4/4: move to_xlog(kobject) to the relevant show/store > > operations. This keeps the xfs_sysfs_object_show/store functions > > generic. Also, with the change, there can be some cleanup of the > > show/store function arguments. > > > > v5: > > -optimization of sysfs_ops function. > > -style fixups > > > > v4: > > -whitespace fixup of patch 1 > > -add patch 4 (sysfs ops consolidation - dbg, stats, log) > > > > v3: > > -style fixups and removal of extraneous printk. > > > > v2: > > -style fixups. > > v1: > > -------------------------------- > > > > We already have per-fs information in /sys, so it makes sense to > > have per-fs stats there too. The series moves existing > > global stats infrastructure to /sys and reuses that code to > > create per-fs stats in /sys. > > > > Patch 1 handles the bring-up and tear down of xfs/stats directory > > structure in sysfs when an fs is mounted. The directory contains > > the stats file and the stats_clear file. The stats file contents mimic > > those of /proc/fs/xfs/stat. The stats_clear file is empty, and much > > like the current stat_clear command, handles the zeroing of the stats > > file when a "1" is echoed to the stats_clear file. > > > > Patch 2 creates the symlink for stats from procfs to sysfs. > > > > Patch 3 removes the now unused portions of procfs for stat. > > > > Patch 4 consolidates the sysfs ops for dbg, stats, log. > > > > Patch 5 allocates and deallocates per-fs stats structures and > > sets up the sysfs entries for them. Add kobject and a pointer > > to a per-cpu struct xfsstats. Modify the macros that manipulate > > the stats accordingly. > > > > Patch 6 implements per-filesystem stats objects in sysfs. Stats > > objects are instantiated when an xfs filesystem is mounted and > > deleted on unmount. > > > > Patch 7 modifies the stats counting macros and the callers > > to those macros to properly increment, decrement, and add-to > > the xfs stats counts. The counts for global and per-fs stats > > are correctly advanced, and cleared by writing a "1" to the > > corresponding clear file. > > > > Once again, comments and questions are welcome. > > > > Thanks- > > Bill > > > > _______________________________________________ > > xfs mailing list > > xfs@oss.sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Mon Sep 28 10:30:37 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 547A97F37 for ; Mon, 28 Sep 2015 10:30:37 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 2FFC2304048 for ; Mon, 28 Sep 2015 08:30:37 -0700 (PDT) X-ASG-Debug-ID: 1443454235-04cb6c6b061283e0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id gucOSBkvpDyqayNt for ; Mon, 28 Sep 2015 08:30:35 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 3366F70F6B09 for ; Mon, 28 Sep 2015 10:30:35 -0500 (CDT) From: Eric Sandeen Subject: Re: [PATCH 7/7] xfs: per-filesystem stats counter implementation To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 7/7] xfs: per-filesystem stats counter implementation References: <1443223380-18870-1-git-send-email-billodo@redhat.com> <1443223380-18870-8-git-send-email-billodo@redhat.com> X-Enigmail-Draft-Status: N1110 Message-ID: <56095D1A.60809@sandeen.net> Date: Mon, 28 Sep 2015 10:30:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1443223380-18870-8-git-send-email-billodo@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1443454235 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22979 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/25/15 6:23 PM, Bill O'Donnell wrote: > This patch modifies the stats counting macros and the callers > to those macros to properly increment, decrement, and add-to > the xfs stats counts. The counts for global and per-fs stats > are correctly advanced, and cleared by writing a "1" to the > corresponding clear file. > > global counts: /sys/fs/xfs/stats/stats > per-fs counts: /sys/fs/xfs/sda*/stats/stats > > global clear: /sys/fs/xfs/stats/stats_clear > per-fs clear: /sys/fs/xfs/sda*/stats/stats_clear > > Signed-off-by: Bill O'Donnell > --- > diff --git a/fs/xfs/libxfs/xfs_btree.h b/fs/xfs/libxfs/xfs_btree.h > index 8f18bab..e42d969 100644 > --- a/fs/xfs/libxfs/xfs_btree.h > +++ b/fs/xfs/libxfs/xfs_btree.h > @@ -84,22 +84,23 @@ union xfs_btree_rec { > /* > * Generic stats interface > */ > -#define __XFS_BTREE_STATS_INC(type, stat) \ > - XFS_STATS_INC(xs_ ## type ## _2_ ## stat) > -#define XFS_BTREE_STATS_INC(cur, stat) \ > +#define __XFS_BTREE_STATS_INC(mp, type, stat) \ > + XFS_STATS_INC(mp, xs_ ## type ## _2_ ## stat) > +#define XFS_BTREE_STATS_INC(cur, stat) \ > do { \ > + struct xfs_mount *mp = cur->bc_mp; \ > switch (cur->bc_btnum) { \ > - case XFS_BTNUM_BNO: __XFS_BTREE_STATS_INC(abtb, stat); break; \ > - case XFS_BTNUM_CNT: __XFS_BTREE_STATS_INC(abtc, stat); break; \ > - case XFS_BTNUM_BMAP: __XFS_BTREE_STATS_INC(bmbt, stat); break; \ > - case XFS_BTNUM_INO: __XFS_BTREE_STATS_INC(ibt, stat); break; \ > - case XFS_BTNUM_FINO: __XFS_BTREE_STATS_INC(fibt, stat); break; \ > + case XFS_BTNUM_BNO: __XFS_BTREE_STATS_INC(mp, abtb, stat); break; \ > + case XFS_BTNUM_CNT: __XFS_BTREE_STATS_INC(mp, abtc, stat); break; \ > + case XFS_BTNUM_BMAP: __XFS_BTREE_STATS_INC(mp, bmbt, stat); break; \ > + case XFS_BTNUM_INO: __XFS_BTREE_STATS_INC(mp, ibt, stat); break; \ > + case XFS_BTNUM_FINO: __XFS_BTREE_STATS_INC(mp, fibt, stat); break; \ > case XFS_BTNUM_MAX: ASSERT(0); /* fucking gcc */ ; break; \ > } \ > } while (0) > > #define __XFS_BTREE_STATS_ADD(type, stat, val) \ > - XFS_STATS_ADD(xs_ ## type ## _2_ ## stat, val) > + XFS_STATS_ADD(cur->bc_mp, xs_ ## type ## _2_ ## stat, val) Where does "cur" come from? XFS_BTREE_STATS_ADD should grab mp from cur & pass it to __XFS_BTREE_STATS_ADD like XFS_BTREE_STATS_INC did, otherwise you're relying on the macro being called from somewhere with a local variable named "cur" - macros referencing local vars @ the callpoint are a bad idea. > #define XFS_BTREE_STATS_ADD(cur, stat, val) \ > do { \ > switch (cur->bc_btnum) { \ > @@ -108,7 +109,7 @@ do { \ > case XFS_BTNUM_BMAP: __XFS_BTREE_STATS_ADD(bmbt, stat, val); break; \ > case XFS_BTNUM_INO: __XFS_BTREE_STATS_ADD(ibt, stat, val); break; \ > case XFS_BTNUM_FINO: __XFS_BTREE_STATS_ADD(fibt, stat, val); break; \ > - case XFS_BTNUM_MAX: ASSERT(0); /* fucking gcc */ ; break; \ > + case XFS_BTNUM_MAX: ASSERT(0); /* fucking gcc */ ; break; \ > } \ > } while (0) > > diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > index d5b3704..d3c8da3 100644 > --- a/fs/xfs/xfs_stats.c > +++ b/fs/xfs/xfs_stats.c > @@ -122,11 +122,9 @@ static int xqm_proc_show(struct seq_file *m, void *v) > { > /* maximum; incore; ratio free to inuse; freelist */ > seq_printf(m, "%d\t%d\t%d\t%u\n", > - 0, > - counter_val(xfsstats.xs_stats, XFSSTAT_END_XQMSTAT), > - 0, > - counter_val(xfsstats.xs_stats, > - XFSSTAT_END_XQMSTAT + 1)); > + 0, counter_val(xfsstats.xs_stats, XFSSTAT_END_XQMSTAT), > + 0, counter_val(xfsstats.xs_stats, > + XFSSTAT_END_XQMSTAT + 1)); unrelated whitespace stuff; if it needs to be reformatted, do it in the patch that introduced the formatting you don't like. > return 0; > } > > diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h > index 00afc13..7e84702 100644 > --- a/fs/xfs/xfs_stats.h > +++ b/fs/xfs/xfs_stats.h > @@ -224,10 +224,25 @@ struct xfs_mount; > * We don't disable preempt, not too worried about poking the > * wrong CPU's stat for now (also aggregated before reporting). > */ > -#define XFS_STATS_INC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v++) > -#define XFS_STATS_DEC(v) (per_cpu(*xfsstats.xs_stats, current_cpu()).v--) > -#define XFS_STATS_ADD(v, inc) (per_cpu(*xfsstats.xs_stats, current_cpu()).v \ > - += (inc)) > +#define XFS_STATS_INC(mp, v) { per_cpu_ptr(xfsstats.xs_stats, \ > + current_cpu())->v++; \ > + per_cpu_ptr( \ > + mp->m_stats.xs_stats, \ > + current_cpu())->v++; } > + kind of odd style here; I'd do: +#define XFS_STATS_INC(mp, v) \ +do { \ + per_cpu_ptr(xfsstats.xs_stats, current_cpu())->v++; \ + per_cpu_ptr(mp->m_stats.xs_stats, current_cpu())->v++; \ +} while (0) (that do { } while (0) idiom is odd, and I think it has fallen out of favor, but it's how the other multiline stats macros work - see XFS_BTREE_STATS_ADD for example) But honestly, maybe this should turn into a static inline. I guess we have plenty of multiline macros already... and really, those per_cpu()'s should have been made per_cpu_ptr's in the patch which introduced the xfsstats.xs_stats usage. > +#define XFS_STATS_DEC(mp, v) { per_cpu_ptr(xfsstats.xs_stats, \ > + current_cpu())->v++; \ > + per_cpu_ptr( \ > + mp->m_stats.xs_stats, \ > + current_cpu())->v--; } > + > +#define XFS_STATS_ADD(mp, v, inc) { per_cpu_ptr(xfsstats.xs_stats, \ > + current_cpu())->v \ > + += (inc); \ > + per_cpu_ptr( \ > + mp->m_stats.xs_stats, \ > + current_cpu())->v \ > + += (inc); } (here too of course) -Eric From sandeen@sandeen.net Mon Sep 28 10:37:47 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 94D7D7F37 for ; Mon, 28 Sep 2015 10:37:47 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 812388F8054 for ; Mon, 28 Sep 2015 08:37:44 -0700 (PDT) X-ASG-Debug-ID: 1443454662-04cbb033b1142a30001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id zhxEUHk1YAEVo5OW for ; Mon, 28 Sep 2015 08:37:42 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id EFC3C70F6B09 for ; Mon, 28 Sep 2015 10:37:41 -0500 (CDT) From: Eric Sandeen Subject: Re: [PATCH 6/7] xfs: per-filesystem stats in sysfs. To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 6/7] xfs: per-filesystem stats in sysfs. References: <1443223380-18870-1-git-send-email-billodo@redhat.com> <1443223380-18870-7-git-send-email-billodo@redhat.com> X-Enigmail-Draft-Status: N1110 Message-ID: <56095EC5.102@sandeen.net> Date: Mon, 28 Sep 2015 10:37:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1443223380-18870-7-git-send-email-billodo@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1443454662 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22979 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/25/15 6:22 PM, Bill O'Donnell wrote: > This patch implements per-filesystem stats objects in sysfs. It > depends on the application of the previous patch series that > develops the infrastructure to support both xfs global stats and > xfs per-fs stats in sysfs. > > Stats objects are instantiated when an xfs filesystem is mounted > and deleted on unmount. With this patch, the stats directory is > created and populated with the familiar stats and stats_clear files. > Example: > /sys/fs/xfs/sda9/stats/stats > /sys/fs/xfs/sda9/stats/stats_clear > > With this patch, the individual counts within the new per-fs > stats file(s) remain at zero. Functions that use the the macros > to increment, decrement, and add-to the per-fs stats counts will > be covered in a separate new patch to follow this one. Note that > the counts within the global stats file (/sys/fs/xfs/stats/stats) > advance normally and can be cleared as it was prior to this patch. > > Signed-off-by: Bill O'Donnell > --- > fs/xfs/xfs_linux.h | 4 ++-- > fs/xfs/xfs_mount.c | 24 +++++++++++++++++++++++- > fs/xfs/xfs_mount.h | 1 + > fs/xfs/xfs_stats.c | 34 +++++++++++++++++++--------------- > fs/xfs/xfs_stats.h | 5 ++++- > fs/xfs/xfs_super.c | 21 ++++++++++++++++----- > fs/xfs/xfs_sysfs.c | 6 +++--- > 7 files changed, 68 insertions(+), 27 deletions(-) > diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c > index bf92e0c..5921d18 100644 > --- a/fs/xfs/xfs_mount.c > +++ b/fs/xfs/xfs_mount.c > @@ -791,11 +791,25 @@ xfs_mountfs( > goto out_free_dir; > } > > + /* > + * Allocate stats memory and create stats sysfs object. > + */ > + mp->m_stats.xs_stats = alloc_percpu(struct xfsstats); > + if (IS_ERR(mp->m_stats.xs_stats)) { > + error = PTR_ERR(mp->m_stats.xs_stats); > + goto out_free_perag; > + } alloc_percpu simply returns NULL on failure AFAIK, so looking for IS_ERR doesn't seem right. Also, I think the placement of this in the routine is a little odd; I'd move it up right under where we create the per-fs sysfs entry, i.e.: error = xfs_sysfs_init(&mp->m_kobj, &xfs_mp_ktype, NULL, mp->m_fsname); if (error) goto out; + /* + * Allocate stats memory and create stats sysfs object. + */ + mp->m_stats.xs_stats = alloc_percpu(struct xfsstats); + if (!mp->m_stats.xs_stats) { + error = -ENOMEM; + goto out_free_perag; + } ... etc ... so that all the sysfs gunk is in the same area. > + error = xfs_sysfs_init(&mp->m_stats.xs_kobj, &xfs_stats_ktype, > + &mp->m_kobj, > + "stats"); > + if (error) > + goto out_free_stats; > + > if (!sbp->sb_logblocks) { > xfs_warn(mp, "no log defined"); > XFS_ERROR_REPORT("xfs_mountfs", XFS_ERRLEVEL_LOW, mp); > error = -EFSCORRUPTED; > - goto out_free_perag; > + goto out_del_stats; > } > > /* > @@ -965,6 +979,10 @@ xfs_mountfs( > if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) > xfs_wait_buftarg(mp->m_logdev_targp); > xfs_wait_buftarg(mp->m_ddev_targp); > + out_del_stats: > + xfs_sysfs_del(&mp->m_stats.xs_kobj); > + out_free_stats: > + free_percpu(mp->m_stats.xs_stats); > out_free_perag: > xfs_free_perag(mp); > out_free_dir: > @@ -1047,6 +1065,10 @@ xfs_unmountfs( > xfs_warn(mp, "Unable to update superblock counters. " > "Freespace may not be correct on next mount."); > > + /* remove the stats kobject and free stats memory */ > + xfs_sysfs_del(&mp->m_stats.xs_kobj); > + free_percpu(mp->m_stats.xs_stats); > + > xfs_log_unmount(mp); > xfs_da_unmount(mp); > xfs_uuid_unmount(mp); > diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h > index 7999e91..8795272 100644 > --- a/fs/xfs/xfs_mount.h > +++ b/fs/xfs/xfs_mount.h > @@ -127,6 +127,7 @@ typedef struct xfs_mount { > int64_t m_low_space[XFS_LOWSP_MAX]; > /* low free space thresholds */ > struct xfs_kobj m_kobj; > + struct xstats m_stats; /* per-fs stats */ > > struct workqueue_struct *m_buf_workqueue; > struct workqueue_struct *m_data_workqueue; > diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c > index ab79973..d5b3704 100644 > --- a/fs/xfs/xfs_stats.c > +++ b/fs/xfs/xfs_stats.c > @@ -18,6 +18,11 @@ > #include "xfs.h" > #include > > +#include "xfs_format.h" > +#include "xfs_trans_resv.h" > +#include "xfs_mount.h" > +#include "xfs_sysfs.h" AFAICT, none of these includes are needed ... > @@ -1843,17 +1842,26 @@ init_xfs_fs(void) > } > > xfsstats.xs_stats = alloc_percpu(struct xfsstats); > + if (!xfsstats.xs_stats) { > + error = -ENOMEM; > + goto out_kset_unregister; > + } This error checking should be added when xs_stats is introduced in patch 5. > xfsstats.xs_kobj.kobject.kset = xfs_kset; > + if (!xfsstats.xs_kobj.kobject.kset) { > + error = -ENOMEM; > + goto out_free_stats; > + } > + this can't fail, you're just assigning one thing to another, no need for this test. We already tested for failure to allocate xfs_kset. > error = xfs_sysfs_init(&xfsstats.xs_kobj, &xfs_stats_ktype, NULL, > - "stats"); > + "stats"); if this is the alignment you want, do it in the patch that introduced it... > if (error) > - goto out_kset_unregister; > + goto out_free_stats; > > #ifdef DEBUG > xfs_dbg_kobj.kobject.kset = xfs_kset; > error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); > if (error) > - goto out_remove_stats; > + goto out_del_stats; > #endif > > error = xfs_qm_init(); > @@ -1870,8 +1878,10 @@ init_xfs_fs(void) > out_remove_dbg_kobj: > #ifdef DEBUG > xfs_sysfs_del(&xfs_dbg_kobj); > - out_remove_stats: > + out_del_stats: hm, why that name? If we have: out_remove_dbg_kobj: xfs_sysfs_del(&xfs_dbg_kobj); then we should have: out_remove_stats_kobj: xfs_sysfs_del(&xfsstats.xs_kobj); for consistency, I think. > diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h > index 672fe83..00afc13 100644 > --- a/fs/xfs/xfs_stats.h > +++ b/fs/xfs/xfs_stats.h > @@ -218,13 +218,16 @@ int xfs_stats_format(struct xfsstats __percpu *stats, char *buf); > void xfs_stats_clearall(struct xfsstats __percpu *stats); > extern struct xstats xfsstats; > > +struct xfs_mount; I don't think that's needed. -Eric > + > /* > * We don't disable preempt, not too worried about poking the > * wrong CPU's stat for now (also aggregated before reporting). > */ From sandeen@sandeen.net Mon Sep 28 10:40:41 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 9689F7F37 for ; Mon, 28 Sep 2015 10:40:41 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 83A128F8059 for ; Mon, 28 Sep 2015 08:40:41 -0700 (PDT) X-ASG-Debug-ID: 1443454839-04cbb033b3142c50001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id Z7mE6izjbDBtWaEF for ; Mon, 28 Sep 2015 08:40:39 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 9ED5D70F6B09 for ; Mon, 28 Sep 2015 10:40:39 -0500 (CDT) Subject: Re: [PATCH 5/7] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 5/7] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. References: <1443223380-18870-1-git-send-email-billodo@redhat.com> <1443223380-18870-6-git-send-email-billodo@redhat.com> From: Eric Sandeen Message-ID: <56095F77.7030403@sandeen.net> Date: Mon, 28 Sep 2015 10:40:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1443223380-18870-6-git-send-email-billodo@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1443454839 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22979 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/25/15 6:22 PM, Bill O'Donnell wrote: > This patch is the next step toward per-fs xfs stats. Allocate & > deallocate per-fs stats structures and set up the sysfs entries for them. > > Instead of a single global xfsstats structure, add kobject and a pointer > to a per-cpu struct xfsstats. Modify the macros that manipulate the stats > accordingly: XFS_STATS_INC, XFS_STATS_DEC, and XFS_STATS_ADD now access > xfsstats->xs_stats. > > The sysfs functions need to get from the kobject back to the xfsstats > structure which contains it, and pass the pointer to the ->xs_stats > percpu structure into the show & clear routines. > > > Signed-off-by: Bill O'Donnell > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > index 0dfc53b..23e5681 100644 > --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -61,7 +61,6 @@ static kmem_zone_t *xfs_ioend_zone; > mempool_t *xfs_ioend_pool; > > static struct kset *xfs_kset; /* top-level xfs sysfs dir */ > -static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ > #ifdef DEBUG > static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ > #endif > @@ -1802,6 +1801,7 @@ xfs_destroy_workqueues(void) > destroy_workqueue(xfs_alloc_wq); > } > > + > STATIC int __init > init_xfs_fs(void) > { > @@ -1842,8 +1842,9 @@ init_xfs_fs(void) > goto out_sysctl_unregister; > } > > - xfs_stats_kobj.kobject.kset = xfs_kset; > - error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, > + xfsstats.xs_stats = alloc_percpu(struct xfsstats); alloc_percpu can fail, so: if (!xfsstats.xs_stats) { error = -ENOMEM; goto out_kset_unregister ... } > + xfsstats.xs_kobj.kobject.kset = xfs_kset; > + error = xfs_sysfs_init(&xfsstats.xs_kobj, &xfs_stats_ktype, NULL, > "stats"); > if (error) > goto out_kset_unregister; If this fails, you need to free the percpu allocation, so this would be "goto out_free_stats" I think > @@ -1852,7 +1853,7 @@ init_xfs_fs(void) > xfs_dbg_kobj.kobject.kset = xfs_kset; > error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); > if (error) > - goto out_remove_stats_kobj; > + goto out_remove_stats; And this remains as out_remove_stats_kobj, I think. > #endif > > error = xfs_qm_init(); > @@ -1869,9 +1870,9 @@ init_xfs_fs(void) > out_remove_dbg_kobj: > #ifdef DEBUG > xfs_sysfs_del(&xfs_dbg_kobj); > - out_remove_stats_kobj: > + out_remove_stats: > #endif > - xfs_sysfs_del(&xfs_stats_kobj); > + free_percpu(xfsstats.xs_stats); hm, now nothing deletes the stats kobject? xfs_sysfs_del(&xfsstats.xs_kobj); but there should be another goto target ... there's one more thing to unwind (the percpu allocation) so you should end up with more unwind goto target (i.e. out_free_stats), but you still need the unwind target for the stats kobject sysfs deletion. something like: out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); out_remove_stats_kobj: #endif xfs_sysfs_del(&xfs_stats_kobj); out_free_stats: free_percpu(xfsstats.xs_stats); out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: but double-check me ;) > out_kset_unregister: > kset_unregister(xfs_kset); > out_sysctl_unregister: > @@ -1898,7 +1899,7 @@ exit_xfs_fs(void) > #ifdef DEBUG > xfs_sysfs_del(&xfs_dbg_kobj); > #endif > - xfs_sysfs_del(&xfs_stats_kobj); > + free_percpu(xfsstats.xs_stats); here as well, you still need to delete the stats kobject: xfs_sysfs_del(&xfsstats.xs_kobj); > kset_unregister(xfs_kset); > xfs_sysctl_unregister(); > xfs_cleanup_procfs(); -Eric From ibsupport@standardbank.co.za Mon Sep 28 10:49:19 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.4 required=5.0 tests=FILL_THIS_FORM_FRAUD_PHISH, HTML_MESSAGE,TVD_PH_BODY_ACCOUNTS_PRE,T_FILL_THIS_FORM_SHORT,T_HTML_ATTACH autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id BDC757F37 for ; Mon, 28 Sep 2015 10:49:19 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id A6CA88F8065 for ; Mon, 28 Sep 2015 08:49:19 -0700 (PDT) X-ASG-Debug-ID: 1443455353-04cb6c6b06128cd0001-NocioJ Received: from fw5a.wadns.net (fw5a.wadns.net [196.220.39.47]) by cuda.sgi.com with ESMTP id FQ2PrxCYMvKlDvQR (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 28 Sep 2015 08:49:15 -0700 (PDT) X-Barracuda-Envelope-From: ibsupport@standardbank.co.za X-Barracuda-Apparent-Source-IP: 196.220.39.47 Received: from mail09.glodns.net ([196.220.44.19] helo=mail9.glodns.net) by fw5a.wadns.net with esmtp (Exim 4.80) (envelope-from ) id 1ZgakX-000834-CG; Mon, 28 Sep 2015 17:53:57 +0200 Received: from UnknownHost [94.156.98.230] by mail9.glodns.net with SMTP; Mon, 28 Sep 2015 17:49:19 +0200 Content-Type: multipart/mixed; boundary="===============1955722031==" MIME-Version: 1.0 Subject: **** Deposit Slips Review Online*******!! To: Recipients X-ASG-Orig-Subj: **** Deposit Slips Review Online*******!! From: "IBSUPPORT@standardbank.co.za" Cc: You Date: Mon, 28 Sep 2015 18:46:28 +0300 X-Priority: 1 (High) X-Barracuda-Connect: fw5a.wadns.net[196.220.39.47] X-Barracuda-Start-Time: 1443455354 X-Barracuda-Encrypted: DHE-RSA-AES128-SHA X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Barracuda-BRTS-Evidence: 8d6b0da82e9c3bd6e08b81cb9867aebd-1626-txt X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-Spam-Score: 1.15 X-Barracuda-Spam-Status: No, SCORE=1.15 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MJ019, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, BSF_SC7_MJ5792, HTML_MESSAGE, MISSING_MID, STAR, STAR_NOMAG X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22980 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 MISSING_MID Missing Message-Id: header 0.10 STAR * 0.00 HTML_MESSAGE BODY: HTML included in message 0.25 BSF_SC7_MJ5792 Mismatched html tag text 0.25 BSF_SC0_MJ019 Custom Rule MJ019 0.40 STAR_NOMAG * 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Message-Id: <20150928154919.769931296088@cuda.sgi.com> You will not see this in a MIME-aware mail reader. --===============1955722031== Content-Type: multipart/alternative; boundary="===============1447896068==" MIME-Version: 1.0 --===============1447896068== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body Online Banking Support ***** Deposit Slips Review ******* Good Morn= ing Sir/Madam, Standard Bank Guarantee Admin Machine:- Re-confirm the= last Deposit Slip Review . Kindly confirm back if this is your last = Re-Confirmation of deposit slips that are personalized and preprinted with= your account number, name and address. The Receipt was Enveloped thi= s morning and was picked up this morning 8:46 AM, Monday ,29th September 20= 15 (GMT+2) Time in South Africa . Delivery Time : Tuesday 6:30 PM , U= PS Delivery vehicde Delivery time. Confirmed Ref : XMJ2-Standard Bank Autho= rization. Verify your Standard Bank Deposit slip & confirm the Delive= ry address by downloading Tthe deposit Slip Copy attached . * XMJ2-Standard= Bank Authorization. * Your satisfaction is our number one priority! = If you have any questions regarding your Standard Bank Account , please con= tact a Customer Service Representative promptly. We appreciate your= business ... ! Sincerely, Your friends at Standard Bank Account= Notice Department --------------------------------------------------= ------------------------------------------------- =A92014 Standard Bank= is a licensed financial services provider in terms of the Financial Adviso= ry and Intermediary Services Act and a registered credit provider in terms = of the National Credit Act, registration number NCRCP15. d ----------= ----------------------------------------------------------- Terms and C= onditions and Disclaimers, including Tax Disclaimers, located below apply t= o your participation in the eBucks Rewards Programme. --===============1447896068== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Description: Mail message body Online Banking Support =
    *****&n= bsp;Deposit Slips Review&= nbsp;*******
    Good Morning Sir/Madam,
 
    Standard Bank Guarant= ee Admin Machine:- Re-confirm the last Deposit Slip Review .
 
    Kindly confirm back i= f this is your last Re-Confirmation of  deposit slips that are persona= lized and preprinted with your account number, name and address.
 
    The Receipt was Envel= oped this morning and was picked up this morning 8:46 AM, Monday ,29th September 2015 (GMT+2) Time in South Africa .=
 
    Delivery Time : Tuesday = 6:30 PM&= nbsp;, UPS Delivery vehicde Delivery time. Confirmed Ref : XMJ2-Stan= dard Bank Authorization.
 
    Verify your Standard = Bank Deposit slip & confirm the Delivery address by downloading Tthe de= posit Slip Copy attached . * XMJ2-Standard Bank Authorization. *
 
    Your satisfaction is = our number one priority! If you have any questions regarding your Standard = Bank Account , please contact a Customer Service Representative promptly.
 
 
    We appreciate your bu= siness  ... !
 
    Sincerely,
    Your friends at Stand= ard Bank Account Notice Department
 
    ----------------------------= -----------------------------------------------------------------------
    =C2=A92014 Standard Bank is = a licensed financial services provider in terms of the Financial Advisory a= nd Intermediary Services Act and a registered credit provider in terms of t= he National Credit Act, registration number NCRCP15. d
 
    ----------------------------= -----------------------------------------
    Terms and Conditions and Dis= claimers, including Tax Disclaimers, located below apply to your participat= ion in the eBucks Rewards Programme.
--===============1447896068==-- --===============1955722031== MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="PDF-STANDARD-REVIEW-SLEP.htm" =EF=BB=BF Internet banking

Internet banking




Login


Please enter your password.

=

By logging on I acknowledge that I have read, understood and am bound by the version of the Electronic Banking Agreement that is posted on the website at the time of logging on. (Last updated: 27 September 2013)

Registration


Customer Care Line

South Africa
0860 123 000

International
+27 11 299 4701

Email
Send us an email




3D"Movingforwardtrademarklogo"

=C2=A9 2014 Standard bank is a licensed = financial services provider in terms of the Financial Advisory and Intermed= iary Services Act.

--===============1955722031==-- From darrick.wong@oracle.com Mon Sep 28 12:04:07 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 47DC57F37 for ; Mon, 28 Sep 2015 12:04:07 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 23AC28F804C for ; Mon, 28 Sep 2015 10:04:04 -0700 (PDT) X-ASG-Debug-ID: 1443459837-04cb6c6b0412b410001-NocioJ Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by cuda.sgi.com with ESMTP id zwTwnsavxIwhobGb (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 10:03:58 -0700 (PDT) X-Barracuda-Envelope-From: darrick.wong@oracle.com X-Barracuda-Apparent-Source-IP: 156.151.31.81 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8SH3quD019439 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Sep 2015 17:03:52 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8SH3q8n023232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Sep 2015 17:03:52 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8SH3phO018801; Mon, 28 Sep 2015 17:03:52 GMT Received: from localhost (/24.21.154.84) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Sep 2015 10:03:51 -0700 Date: Mon, 28 Sep 2015 10:03:50 -0700 From: "Darrick J. Wong" To: Dave Chinner Cc: xfs@oss.sgi.com Subject: Re: [PATCH 08/11] xfs_io: support reflinking and deduping file ranges Message-ID: <20150928170350.GA1600@birch.djwong.org> X-ASG-Orig-Subj: Re: [PATCH 08/11] xfs_io: support reflinking and deduping file ranges References: <20150826003220.23973.59731.stgit@birch.djwong.org> <20150826003311.23973.64761.stgit@birch.djwong.org> <20150922021755.GF19114@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150922021755.GF19114@dastard> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Barracuda-Connect: userp1040.oracle.com[156.151.31.81] X-Barracuda-Start-Time: 1443459838 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22982 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines On Tue, Sep 22, 2015 at 12:17:55PM +1000, Dave Chinner wrote: > On Tue, Aug 25, 2015 at 05:33:11PM -0700, Darrick J. Wong wrote: > > +static int > > +dedupe_f( > > + int argc, > > + char **argv) > > +{ > > + off64_t soffset, doffset; > > + long long count, total; > > + char s1[64], s2[64], ts[64]; > > Magic! > > > + char *infile; > > + int Cflag, qflag, wflag, Wflag; > > Urk. Variables that differ only by case! Yeah. I seriously hate those variable names, but they seemed to occur in other parts of io/. I'll stop considering awkward naming to be precedent and change these here to have sensible names. (FWIW I was just following pwrite.c's lead...) > > > + struct xfs_ioctl_file_extent_same_args *args = NULL; > > + struct xfs_ioctl_file_extent_same_info *info; > > verbosity--; I was trying to keep the XFS names as close to the BTRFS names as possible since they're the same feature, but since you later advocate for name changes I'll gladly change 'em to be less annoying and more visually distinct. :) > > > + size_t fsblocksize, fssectsize; > > + struct timeval t1, t2; > > + int c, fd = -1; > > + > > + Cflag = qflag = wflag = Wflag = 0; > > + init_cvtnum(&fsblocksize, &fssectsize); > > + > > + while ((c = getopt(argc, argv, "CqwW")) != EOF) { > > + switch (c) { > > + case 'C': > > + Cflag = 1; > > + break; > > + case 'q': > > + qflag = 1; > > + break; > > + case 'w': > > + wflag = 1; > > + break; > > + case 'W': > > + Wflag = 1; > > + break; > > + default: > > + return command_usage(&dedupe_cmd); > > + } > > + } > > + if (optind != argc - 4) > > + return command_usage(&dedupe_cmd); > > + infile = argv[optind]; > > + optind++; > > + soffset = cvtnum(fsblocksize, fssectsize, argv[optind]); > > + if (soffset < 0) { > > + printf(_("non-numeric src offset argument -- %s\n"), argv[optind]); > > + return 0; > > + } > > + optind++; > > + doffset = cvtnum(fsblocksize, fssectsize, argv[optind]); > > + if (doffset < 0) { > > + printf(_("non-numeric dest offset argument -- %s\n"), argv[optind]); > > + return 0; > > + } > > + optind++; > > + count = cvtnum(fsblocksize, fssectsize, argv[optind]); > > + if (count < 1) { > > + printf(_("non-positive length argument -- %s\n"), argv[optind]); > > + return 0; > > + } > > + > > + c = IO_READONLY; > > + fd = openfile(infile, NULL, c, 0); > > + if (fd < 0) > > + return 0; > > + > > + gettimeofday(&t1, NULL); > > + args = calloc(1, sizeof(struct xfs_ioctl_file_extent_same_args) + > > + sizeof(struct xfs_ioctl_file_extent_same_info)); > > + if (!args) > > + goto done; > > + info = (struct xfs_ioctl_file_extent_same_info *)(args + 1); > > + args->logical_offset = soffset; > > + args->length = count; > > + args->dest_count = 1; > > + info->fd = file->fd; > > + info->logical_offset = doffset; > > + do { > > + c = ioctl(fd, XFS_IOC_FILE_EXTENT_SAME, args); > > + if (c) > > + break; > > + args->logical_offset += info->bytes_deduped; > > + info->logical_offset += info->bytes_deduped; > > + args->length -= info->bytes_deduped; > > + } while (c == 0 && info->status == 0 && info->bytes_deduped > 0); > > What's "c"? it's actually a return value, and it's already been > handled if it's non zero. and there's nothing preventing > args->length from going negative. args->length is u64, so I'll bail out of the loop if bytes_deduped > length; that's probably a sign of badness going on. > > > + if (c) > > + perror(_("dedupe ioctl")); > > + if (info->status < 0) > > + printf("dedupe: %s\n", _(strerror(-info->status))); > > + if (info->status == XFS_SAME_DATA_DIFFERS) > > "same data differs"? Really? :P spoiled btrfs leftovers. :( > > > + printf(_("Extents did not match.\n")); > > And putting hte error messages outside the loop is going to be hard > to maintain. I'd much prefer to see this written as: > > while (args->length > 0) { > result = ioctl(fd, XFS_IOC_FILE_EXTENT_SAME, args); > if (result) { > perror("XFS_IOC_FILE_EXTENT_SAME"); > goto done; > } > if (info->status != 0) { > printf("dedupe: %s\n", _(strerror(-info->status))); > if (info->status == XFS_SAME_DATA_DIFFERS) > printf(_("Extents did not match.\n")); > goto done; > } > if (info->bytes_deduped == 0) > break; > > args->logical_offset += info->bytes_deduped; > info->logical_offset += info->bytes_deduped; > args->length -= info->bytes_deduped; > } > > Actually, I'd really lik eto see this bit factored out into a > separate function, so there's clear separation between arg parsing, > the operation and post-op cleanup. > > > + total = info->bytes_deduped; > > + c = 1; > > + if (Wflag) > > + fsync(file->fd); > > + if (wflag) > > + fdatasync(file->fd); > > So these flags are just for syncing. This does not need to be a part > of this function, because the user can simply do: > > xfs_io -c "dedupe ...." -c "fsync" ... > > if an fsync or fdatasync is required after dedupe. So kill those > options. Ok. I wonder why they're in pwrite.c... > > > > + if (qflag) > > + goto done; > > Urk. > > > + gettimeofday(&t2, NULL); > > + t2 = tsub(t2, t1); > > + > > + /* Finally, report back -- -C gives a parsable format */ > > + timestr(&t2, ts, sizeof(ts), Cflag ? VERBOSE_FIXED_TIME : 0); > > + if (!Cflag) { > > + cvtstr((double)total, s1, sizeof(s1)); > > + cvtstr(tdiv((double)total, t2), s2, sizeof(s2)); > > + printf(_("linked %lld/%lld bytes at offset %lld\n"), > > + total, count, (long long)doffset); > > + printf(_("%s, %d ops; %s (%s/sec and %.4f ops/sec)\n"), > > + s1, c, ts, s2, tdiv((double)c, t2)); > > + } else {/* bytes,ops,time,bytes/sec,ops/sec */ > > + printf("%lld,%d,%s,%.3f,%.3f\n", > > + total, c, ts, > > + tdiv((double)total, t2), tdiv((double)c, t2)); > > + } > > This must be common with other timing code. Factor it out? Yep. > > > +static void > > +reflink_help(void) > > +{ > > + printf(_( > > +"\n" > > +" Links a range of bytes (in block size increments) from a file into a range \n" > > +" of bytes in the open file. The two extent ranges need not contain identical\n" > > +" data. \n" > > +"\n" > > +" Example:\n" > > +" 'reflink some_file 0 4096 32768' - links 32768 bytes from some_file at \n" > > +" offset 0 to into the open file at \n" > > +" position 4096\n" > > +" 'reflink some_file' - links all bytes from some_file into the open file\n" > > +" at position 0\n" > > +"\n" > > +" Reflink a range of blocks from a given input file to the open file. Both\n" > > +" files share the same range of physical disk blocks; a write to the shared\n" > > +" range of either file should result in the write landing in a new block and\n" > > +" that range of the file being remapped (i.e. copy-on-write). Both files\n" > > +" must reside on the same filesystem.\n" > > +" -w -- call fdatasync(2) at the end (included in timing results)\n" > > +" -W -- call fsync(2) at the end (included in timing results)\n" > > +"\n")); > > +} > > FWIW, could these just be a single string like: > > " > Links a range of bytes (in block size increments) from a file into a range > of bytes in the open file. The two extent ranges need not contain identical > .... > \n")); > > So we don't have to mangle the entire layout if we modify the help > tet in future? Ok. > > > +static int > > +reflink_f( > > + int argc, > > + char **argv) > > +{ > > Same comments as the dedupe_f() function about factoring and > variable names and reusing "c" for a bunch of unrelated values. > > indeed, most of this is common with the dedupe_f function, so > perhaps it might be worth putting them in the same file and > factoring them appropriately to shared common elements? Sounds good. > > > diff --git a/libxfs/xfs_fs.h b/libxfs/xfs_fs.h > > index 89689c6..0c922ad 100644 > > --- a/libxfs/xfs_fs.h > > +++ b/libxfs/xfs_fs.h > > @@ -559,6 +559,42 @@ typedef struct xfs_swapext > > #define XFS_IOC_GOINGDOWN _IOR ('X', 125, __uint32_t) > > /* XFS_IOC_GETFSUUID ---------- deprecated 140 */ > > > > +/* reflink ioctls; these MUST match the btrfs ioctl definitions */ > > +struct xfs_ioctl_clone_range_args { > > + __s64 src_fd; > > + __u64 src_offset; > > + __u64 src_length; > > + __u64 dest_offset; > > +}; > > struct xfs_clone_args > > > + > > +#define XFS_SAME_DATA_DIFFERS 1 > > #define XFS_EXTENT_DATA_SAME 0 > #define XFS_EXTENT_DATA_DIFFERS 1 > > > +/* For extent-same ioctl */ > > +struct xfs_ioctl_file_extent_same_info { > > + __s64 fd; /* in - destination file */ > > + __u64 logical_offset; /* in - start of extent in destination */ > > + __u64 bytes_deduped; /* out - total # of bytes we were able > > + * to dedupe from this file */ > > + /* status of this dedupe operation: > > + * 0 if dedup succeeds > > + * < 0 for error > > + * == XFS_SAME_DATA_DIFFERS if data differs > > + */ > > + __s32 status; /* out - see above description */ > > + __u32 reserved; > > +}; > > struct xfs_extent_data_info > > > + > > +struct xfs_ioctl_file_extent_same_args { > > + __u64 logical_offset; /* in - start of extent in source */ > > + __u64 length; /* in - length of extent */ > > + __u16 dest_count; /* in - total elements in info array */ > > + __u16 reserved1; > > + __u32 reserved2; > > + struct xfs_ioctl_file_extent_same_info info[0]; > > +}; > > struct xfs_extent_data Yay, less ugly names! > > > + > > +#define XFS_IOC_CLONE _IOW (0x94, 9, int) > > +#define XFS_IOC_CLONE_RANGE _IOW (0x94, 13, struct xfs_ioctl_clone_range_args) > > +#define XFS_IOC_FILE_EXTENT_SAME _IOWR(0x94, 54, struct xfs_ioctl_file_extent_same_args) > > FWIW, these structure and ioctl definitions really need to be in a > separate patch as they need to be shared with the kernel code. Ok. libxfs/ changes in separate patches, got it. --D > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com From bfoster@redhat.com Mon Sep 28 13:38:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 70EEA7F37 for ; Mon, 28 Sep 2015 13:38:05 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 40E638F8068 for ; Mon, 28 Sep 2015 11:38:05 -0700 (PDT) X-ASG-Debug-ID: 1443465483-04bdf04627138c80001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id vA8rBBhzH1xbWKP9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 11:38:04 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id ADC02A145C for ; Mon, 28 Sep 2015 18:38:03 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SIc3Sp029241 for ; Mon, 28 Sep 2015 14:38:03 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id D55201202D2; Mon, 28 Sep 2015 14:38:01 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH 0/2] xfs: fix eof zeroing i_size race Date: Mon, 28 Sep 2015 14:37:59 -0400 X-ASG-Orig-Subj: [PATCH 0/2] xfs: fix eof zeroing i_size race Message-Id: <1443465481-63460-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443465484 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi all, This addresses an EOF zeroing race that's been reproduced by a somewhat obscure virtual machine workload on qcow2 vdisks with an increasing i_size. Patch 1 contains the fix and patch 2 just adds a tracepoint that helped identify the problem. Thoughts, reviews, flames appreciated. Brian Brian Foster (2): xfs: always drain dio before extending aio write submission xfs: add an xfs_zero_eof() tracepoint fs/xfs/xfs_file.c | 17 +++++++++++------ fs/xfs/xfs_trace.h | 1 + 2 files changed, 12 insertions(+), 6 deletions(-) -- 2.1.0 From bfoster@redhat.com Mon Sep 28 13:38:06 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 86ABE7F37 for ; Mon, 28 Sep 2015 13:38:06 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 07BDDAC005 for ; Mon, 28 Sep 2015 11:38:05 -0700 (PDT) X-ASG-Debug-ID: 1443465483-04cbb033b2148c50001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id voQO7A1NfmVyAFVw (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 11:38:04 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id AD54A80092 for ; Mon, 28 Sep 2015 18:38:03 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SIc3re014744 for ; Mon, 28 Sep 2015 14:38:03 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id E42611201A0; Mon, 28 Sep 2015 14:38:01 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH 1/2] xfs: always drain dio before extending aio write submission Date: Mon, 28 Sep 2015 14:38:00 -0400 X-ASG-Orig-Subj: [PATCH 1/2] xfs: always drain dio before extending aio write submission Message-Id: <1443465481-63460-2-git-send-email-bfoster@redhat.com> In-Reply-To: <1443465481-63460-1-git-send-email-bfoster@redhat.com> References: <1443465481-63460-1-git-send-email-bfoster@redhat.com> 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: 1443465484 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 XFS supports and typically allows concurrent asynchronous direct I/O submission to a single file. One exception to the rule is that file extending dio writes that start beyond the current EOF (e.g., potentially create a hole at EOF) require exclusive I/O access to the file. This is because such writes must zero any pre-existing blocks beyond EOF that are exposed by virtue of now residing within EOF as a result of the write about to be submitted. Before EOF zeroing can occur, the current file i_size must be stabilized to avoid data corruption. In this scenario, XFS upgrades the iolock to exclude any further I/O submission, waits on in-flight I/O to complete to ensure i_size is up to date (i_size is updated on dio write completion) and restarts the various checks against the state of the file. The problem is that this protection sequence is triggered only when the iolock is currently held shared. While this is true for async dio in most cases, the caller may upgrade the lock in advance based on arbitrary circumstances with respect to EOF zeroing. For example, the iolock is always acquired exclusively if the start offset is not block aligned. This means that even though the iolock is already held exclusive for such I/Os, pending I/O is not drained and thus EOF zeroing can occur based on an unstable i_size. This problem has been reproduced as guest data corruption in virtual machines with file-backed qcow2 virtual disks hosted on an XFS filesystem. The virtual disks must be configured with aio=native mode and the must not be truncated out to the maximum file size (as some virt managers will do). Update xfs_file_aio_write_checks() to unconditionally drain in-flight dio before EOF zeroing can occur. Rather than trigger the wait based on iolock state, use a new flag and upgrade the iolock when necessary. Note that this results in a full restart of the inode checks even when the iolock was already held exclusive when technically it is only required to recheck i_size. This should be a rare enough occurrence that it is preferable to keep the code simple rather than create an alternate restart jump target. Signed-off-by: Brian Foster --- fs/xfs/xfs_file.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index e78feb4..347b3e0 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -574,6 +574,7 @@ xfs_file_aio_write_checks( struct xfs_inode *ip = XFS_I(inode); ssize_t error = 0; size_t count = iov_iter_count(from); + bool drained_dio = false; restart: error = generic_write_checks(iocb, from); @@ -611,12 +612,13 @@ restart: bool zero = false; spin_unlock(&ip->i_flags_lock); - if (*iolock == XFS_IOLOCK_SHARED) { - xfs_rw_iunlock(ip, *iolock); - *iolock = XFS_IOLOCK_EXCL; - xfs_rw_ilock(ip, *iolock); - iov_iter_reexpand(from, count); - + if (!drained_dio) { + if (*iolock == XFS_IOLOCK_SHARED) { + xfs_rw_iunlock(ip, *iolock); + *iolock = XFS_IOLOCK_EXCL; + xfs_rw_ilock(ip, *iolock); + iov_iter_reexpand(from, count); + } /* * We now have an IO submission barrier in place, but * AIO can do EOF updates during IO completion and hence @@ -626,6 +628,7 @@ restart: * no-op. */ inode_dio_wait(inode); + drained_dio = true; goto restart; } error = xfs_zero_eof(ip, iocb->ki_pos, i_size_read(inode), &zero); -- 2.1.0 From bfoster@redhat.com Mon Sep 28 13:38:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id C345F7F56 for ; Mon, 28 Sep 2015 13:38:08 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 4D04EAC005 for ; Mon, 28 Sep 2015 11:38:05 -0700 (PDT) X-ASG-Debug-ID: 1443465483-04cbb033b3148c50001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id g5zKiTu0lOMXnyPy (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 11:38:04 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id AAABCAA8 for ; Mon, 28 Sep 2015 18:38:03 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SIc3t4018011 for ; Mon, 28 Sep 2015 14:38:03 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id F0F701203DF; Mon, 28 Sep 2015 14:38:01 -0400 (EDT) From: Brian Foster To: xfs@oss.sgi.com Subject: [PATCH 2/2] xfs: add an xfs_zero_eof() tracepoint Date: Mon, 28 Sep 2015 14:38:01 -0400 X-ASG-Orig-Subj: [PATCH 2/2] xfs: add an xfs_zero_eof() tracepoint Message-Id: <1443465481-63460-3-git-send-email-bfoster@redhat.com> In-Reply-To: <1443465481-63460-1-git-send-email-bfoster@redhat.com> References: <1443465481-63460-1-git-send-email-bfoster@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443465484 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Add a tracepoint in xfs_zero_eof() to facilitate tracking and debugging EOF zeroing events. This has proven useful in the context of other direct I/O tracepoints to ensure EOF zeroing occurs within appropriate file ranges. Signed-off-by: Brian Foster --- fs/xfs/xfs_file.c | 2 ++ fs/xfs/xfs_trace.h | 1 + 2 files changed, 3 insertions(+) diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index 347b3e0..541dcfb 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -482,6 +482,8 @@ xfs_zero_eof( ASSERT(xfs_isilocked(ip, XFS_IOLOCK_EXCL)); ASSERT(offset > isize); + trace_xfs_zero_eof(ip, isize, offset - isize); + /* * First handle zeroing the block on which isize resides. * diff --git a/fs/xfs/xfs_trace.h b/fs/xfs/xfs_trace.h index 5ed36b1..957f5cc 100644 --- a/fs/xfs/xfs_trace.h +++ b/fs/xfs/xfs_trace.h @@ -1312,6 +1312,7 @@ DEFINE_SIMPLE_IO_EVENT(xfs_delalloc_enospc); DEFINE_SIMPLE_IO_EVENT(xfs_unwritten_convert); DEFINE_SIMPLE_IO_EVENT(xfs_get_blocks_notfound); DEFINE_SIMPLE_IO_EVENT(xfs_setfilesize); +DEFINE_SIMPLE_IO_EVENT(xfs_zero_eof); DECLARE_EVENT_CLASS(xfs_itrunc_class, TP_PROTO(struct xfs_inode *ip, xfs_fsize_t new_size), -- 2.1.0 From scanner@rnad.co.za Mon Sep 28 16:06:02 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=FREEMAIL_FORGED_REPLYTO autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 90CCA7F37 for ; Mon, 28 Sep 2015 16:06:02 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 81F818F8052 for ; Mon, 28 Sep 2015 14:05:59 -0700 (PDT) X-ASG-Debug-ID: 1443474354-04cbb033b214d6f0001-NocioJ Received: from mail.rnad.co.za (mta.rnad.co.za [41.79.39.241]) by cuda.sgi.com with ESMTP id LqO3ZniR3zsu8AOp (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 14:05:56 -0700 (PDT) X-Barracuda-Envelope-From: scanner@rnad.co.za X-Barracuda-Apparent-Source-IP: 41.79.39.241 Received: from localhost (localhost [127.0.0.1]) by mail.rnad.co.za (Postfix) with ESMTP id 123034E05C3; Mon, 28 Sep 2015 23:05:51 +0200 (SAST) Received: from mail.rnad.co.za ([127.0.0.1]) by localhost (mail.rnad.co.za [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id m8CLvlpF42Ry; Mon, 28 Sep 2015 23:05:50 +0200 (SAST) Received: from localhost (localhost [127.0.0.1]) by mail.rnad.co.za (Postfix) with ESMTP id 320584E062B; Mon, 28 Sep 2015 23:05:49 +0200 (SAST) X-Virus-Scanned: amavisd-new at rnad.co.za Received: from mail.rnad.co.za ([127.0.0.1]) by localhost (mail.rnad.co.za [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Es1FQNWDFWaa; Mon, 28 Sep 2015 23:05:47 +0200 (SAST) Received: from mail.rnad.co.za (mail.rnad.co.za [192.168.0.2]) by mail.rnad.co.za (Postfix) with ESMTP id 7F49A4E055D; Mon, 28 Sep 2015 23:05:45 +0200 (SAST) Date: Mon, 28 Sep 2015 23:05:45 +0200 (SAST) From: Rachel Raquel Reply-To: Rachel Raquel To: rwrach Message-ID: <1785722354.887890.1443474345457.JavaMail.zimbra@rnad.co.za> Subject: =?utf-8?Q?where_are_you=3F=E2=80=8F?= MIME-Version: 1.0 X-ASG-Orig-Subj: =?utf-8?Q?where_are_you=3F=E2=80=8F?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [212.52.159.74] X-Mailer: Zimbra 8.6.0_GA_1178 (ZimbraWebClient - FF30 (Win)/8.6.0_GA_1178) Thread-Topic: where are =?utf-8?B?eW91P+KAjw==?= Thread-Index: 4NmYhG/1wWnuB6Pf8XF09i3BRGd5lw== X-Barracuda-Connect: mta.rnad.co.za[41.79.39.241] X-Barracuda-Start-Time: 1443474355 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-Spam-Score: 0.22 X-Barracuda-Spam-Status: No, SCORE=0.22 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC7_SA298e, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22989 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.20 BSF_SC7_SA298e Custom Rule SA298e can i see you is very important? This is not a joke! Rachel From billodo@redhat.com Mon Sep 28 16:33:18 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 2FD307F3F for ; Mon, 28 Sep 2015 16:33:18 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id C0638AC007 for ; Mon, 28 Sep 2015 14:33:17 -0700 (PDT) X-ASG-Debug-ID: 1443475996-04bdf0462213de10001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id f7hVsuDAiREaYIdr (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 14:33:16 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id A13EEA37E2 for ; Mon, 28 Sep 2015 21:33:16 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-26.rdu2.redhat.com [10.10.55.26]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SLXDo6005461 for ; Mon, 28 Sep 2015 17:33:16 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 3/7] xfs: remove unused procfs code Date: Mon, 28 Sep 2015 16:33:04 -0500 X-ASG-Orig-Subj: [PATCH 3/7] xfs: remove unused procfs code Message-Id: <1443475988-15251-4-git-send-email-billodo@redhat.com> In-Reply-To: <1443475988-15251-1-git-send-email-billodo@redhat.com> References: <1443475988-15251-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443475996 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch removes the now unused procfs code that was xfs stat specific. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 74 ------------------------------------------------------ 1 file changed, 74 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index afd19e1..dc6ca67 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -112,80 +112,6 @@ void xfs_stats_clearall(void) } } -static int xfs_stat_proc_show(struct seq_file *m, void *v) -{ - int i, j; - __uint64_t xs_xstrat_bytes = 0; - __uint64_t xs_write_bytes = 0; - __uint64_t xs_read_bytes = 0; - - static const struct xstats_entry { - char *desc; - int endpoint; - } xstats[] = { - { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, - { "abt", XFSSTAT_END_ALLOC_BTREE }, - { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, - { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, - { "dir", XFSSTAT_END_DIRECTORY_OPS }, - { "trans", XFSSTAT_END_TRANSACTIONS }, - { "ig", XFSSTAT_END_INODE_OPS }, - { "log", XFSSTAT_END_LOG_OPS }, - { "push_ail", XFSSTAT_END_TAIL_PUSHING }, - { "xstrat", XFSSTAT_END_WRITE_CONVERT }, - { "rw", XFSSTAT_END_READ_WRITE_OPS }, - { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, - { "icluster", XFSSTAT_END_INODE_CLUSTER }, - { "vnodes", XFSSTAT_END_VNODE_OPS }, - { "buf", XFSSTAT_END_BUF }, - { "abtb2", XFSSTAT_END_ABTB_V2 }, - { "abtc2", XFSSTAT_END_ABTC_V2 }, - { "bmbt2", XFSSTAT_END_BMBT_V2 }, - { "ibt2", XFSSTAT_END_IBT_V2 }, - { "fibt2", XFSSTAT_END_FIBT_V2 }, - /* we print both series of quota information together */ - { "qm", XFSSTAT_END_QM }, - }; - - /* Loop over all stats groups */ - for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { - seq_printf(m, "%s", xstats[i].desc); - /* inner loop does each group */ - for (; j < xstats[i].endpoint; j++) - seq_printf(m, " %u", counter_val(j)); - seq_putc(m, '\n'); - } - /* extra precision counters */ - for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; - } - - seq_printf(m, "xpc %Lu %Lu %Lu\n", - xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); - seq_printf(m, "debug %u\n", -#if defined(DEBUG) - 1); -#else - 0); -#endif - return 0; -} - -static int xfs_stat_proc_open(struct inode *inode, struct file *file) -{ - return single_open(file, xfs_stat_proc_show, NULL); -} - -static const struct file_operations xfs_stat_proc_fops = { - .owner = THIS_MODULE, - .open = xfs_stat_proc_open, - .read = seq_read, - .llseek = seq_lseek, - .release = single_release, -}; - /* legacy quota interfaces */ #ifdef CONFIG_XFS_QUOTA static int xqm_proc_show(struct seq_file *m, void *v) -- 2.4.3 From billodo@redhat.com Mon Sep 28 16:33:18 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 0A1B77F37 for ; Mon, 28 Sep 2015 16:33:18 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 7F017AC005 for ; Mon, 28 Sep 2015 14:33:17 -0700 (PDT) X-ASG-Debug-ID: 1443475995-04cb6c6b06132bd0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id ARJ8YLR5BWGUl3O9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 14:33:15 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 1A8D6AB864 for ; Mon, 28 Sep 2015 21:33:15 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-26.rdu2.redhat.com [10.10.55.26]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SLXDo4005461 for ; Mon, 28 Sep 2015 17:33:14 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 1/7] xfs: create global stats and stats_clear in sysfs Date: Mon, 28 Sep 2015 16:33:02 -0500 X-ASG-Orig-Subj: [PATCH 1/7] xfs: create global stats and stats_clear in sysfs Message-Id: <1443475988-15251-2-git-send-email-billodo@redhat.com> In-Reply-To: <1443475988-15251-1-git-send-email-billodo@redhat.com> References: <1443475988-15251-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443475995 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Currently, xfs global stats are in procfs. This patch introduces (replicates) the global stats in sysfs. Additionally a stats_clear file is introduced in sysfs. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_stats.h | 2 ++ fs/xfs/xfs_super.c | 20 +++++++++---- fs/xfs/xfs_sysctl.c | 15 ++-------- fs/xfs/xfs_sysfs.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_sysfs.h | 1 + 6 files changed, 179 insertions(+), 17 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index f224038..0d6ec33 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -29,6 +29,89 @@ static int counter_val(int idx) return val; } +int xfs_stats_format(char *buf) +{ + int i, j; + int len = 0; + __uint64_t xs_xstrat_bytes = 0; + __uint64_t xs_write_bytes = 0; + __uint64_t xs_read_bytes = 0; + + static const struct xstats_entry { + char *desc; + int endpoint; + } xstats[] = { + { "extent_alloc", XFSSTAT_END_EXTENT_ALLOC }, + { "abt", XFSSTAT_END_ALLOC_BTREE }, + { "blk_map", XFSSTAT_END_BLOCK_MAPPING }, + { "bmbt", XFSSTAT_END_BLOCK_MAP_BTREE }, + { "dir", XFSSTAT_END_DIRECTORY_OPS }, + { "trans", XFSSTAT_END_TRANSACTIONS }, + { "ig", XFSSTAT_END_INODE_OPS }, + { "log", XFSSTAT_END_LOG_OPS }, + { "push_ail", XFSSTAT_END_TAIL_PUSHING }, + { "xstrat", XFSSTAT_END_WRITE_CONVERT }, + { "rw", XFSSTAT_END_READ_WRITE_OPS }, + { "attr", XFSSTAT_END_ATTRIBUTE_OPS }, + { "icluster", XFSSTAT_END_INODE_CLUSTER }, + { "vnodes", XFSSTAT_END_VNODE_OPS }, + { "buf", XFSSTAT_END_BUF }, + { "abtb2", XFSSTAT_END_ABTB_V2 }, + { "abtc2", XFSSTAT_END_ABTC_V2 }, + { "bmbt2", XFSSTAT_END_BMBT_V2 }, + { "ibt2", XFSSTAT_END_IBT_V2 }, + { "fibt2", XFSSTAT_END_FIBT_V2 }, + /* we print both series of quota information together */ + { "qm", XFSSTAT_END_QM }, + }; + + /* Loop over all stats groups */ + + for (i = j = 0; i < ARRAY_SIZE(xstats); i++) { + len += snprintf(buf + len, PATH_MAX - len, "%s", + xstats[i].desc); + /* inner loop does each group */ + for (; j < xstats[i].endpoint; j++) + len += snprintf(buf + len, PATH_MAX - len, " %u", + counter_val(j)); + len += snprintf(buf + len, PATH_MAX - len, "\n"); + } + /* extra precision counters */ + for_each_possible_cpu(i) { + xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; + xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; + xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; + } + + len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", + xs_xstrat_bytes, xs_write_bytes, xs_read_bytes); + len += snprintf(buf+len, PATH_MAX-len, "debug %u\n", +#if defined(DEBUG) + 1); +#else + 0); +#endif + + return len; +} + +void xfs_stats_clearall(void) +{ + int c; + __uint32_t vn_active; + + xfs_notice(NULL, "Clearing xfsstats"); + for_each_possible_cpu(c) { + preempt_disable(); + /* save vn_active, it's a universal truth! */ + vn_active = per_cpu(xfsstats, c).vn_active; + memset(&per_cpu(xfsstats, c), 0, + sizeof(struct xfsstats)); + per_cpu(xfsstats, c).vn_active = vn_active; + preempt_enable(); + } +} + static int xfs_stat_proc_show(struct seq_file *m, void *v) { int i, j; diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index c8f238b..18807b5 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -18,6 +18,8 @@ #ifndef __XFS_STATS_H__ #define __XFS_STATS_H__ +int xfs_stats_format(char *buf); +void xfs_stats_clearall(void); #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 904f637..0dfc53b 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -61,6 +61,7 @@ static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; static struct kset *xfs_kset; /* top-level xfs sysfs dir */ +static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ #ifdef DEBUG static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ #endif @@ -1838,19 +1839,25 @@ init_xfs_fs(void) xfs_kset = kset_create_and_add("xfs", NULL, fs_kobj); if (!xfs_kset) { error = -ENOMEM; - goto out_sysctl_unregister;; + goto out_sysctl_unregister; } + xfs_stats_kobj.kobject.kset = xfs_kset; + error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, + "stats"); + if (error) + goto out_kset_unregister; + #ifdef DEBUG xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_kset_unregister; + goto out_remove_stats_kobj; #endif error = xfs_qm_init(); if (error) - goto out_remove_kobj; + goto out_remove_dbg_kobj; error = register_filesystem(&xfs_fs_type); if (error) @@ -1859,11 +1866,13 @@ init_xfs_fs(void) out_qm_exit: xfs_qm_exit(); - out_remove_kobj: + out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_kset_unregister: + out_remove_stats_kobj: #endif + xfs_sysfs_del(&xfs_stats_kobj); + out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: xfs_sysctl_unregister(); @@ -1889,6 +1898,7 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif + xfs_sysfs_del(&xfs_stats_kobj); kset_unregister(xfs_kset); xfs_sysctl_unregister(); xfs_cleanup_procfs(); diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c index a0c8067..5defabb 100644 --- a/fs/xfs/xfs_sysctl.c +++ b/fs/xfs/xfs_sysctl.c @@ -19,6 +19,7 @@ #include #include #include "xfs_error.h" +#include "xfs_stats.h" static struct ctl_table_header *xfs_table_header; @@ -31,22 +32,12 @@ xfs_stats_clear_proc_handler( size_t *lenp, loff_t *ppos) { - int c, ret, *valp = ctl->data; - __uint32_t vn_active; + int ret, *valp = ctl->data; ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); if (!ret && write && *valp) { - xfs_notice(NULL, "Clearing xfsstats"); - for_each_possible_cpu(c) { - preempt_disable(); - /* save vn_active, it's a universal truth! */ - vn_active = per_cpu(xfsstats, c).vn_active; - memset(&per_cpu(xfsstats, c), 0, - sizeof(struct xfsstats)); - per_cpu(xfsstats, c).vn_active = vn_active; - preempt_enable(); - } + xfs_stats_clearall(); xfs_stats_clear = 0; } diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index aa03670..a094e20 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -21,6 +21,7 @@ #include "xfs_log_format.h" #include "xfs_log.h" #include "xfs_log_priv.h" +#include "xfs_stats.h" struct xfs_sysfs_attr { struct attribute attr; @@ -38,6 +39,8 @@ to_attr(struct attribute *attr) static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RW(name) #define XFS_SYSFS_ATTR_RO(name) \ static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_RO(name) +#define XFS_SYSFS_ATTR_WO(name) \ + static struct xfs_sysfs_attr xfs_sysfs_attr_##name = __ATTR_WO(name) #define ATTR_LIST(name) &xfs_sysfs_attr_##name.attr @@ -125,6 +128,78 @@ struct kobj_type xfs_dbg_ktype = { #endif /* DEBUG */ + +/* stats */ + +STATIC ssize_t +stats_show( + char *buf, + void *data) +{ + return xfs_stats_format(buf); +} +XFS_SYSFS_ATTR_RO(stats); + +STATIC ssize_t +stats_clear_store( + const char *buf, + size_t count, + void *data) +{ + int ret; + int val; + + ret = kstrtoint(buf, 0, &val); + if (ret) + return ret; + + if (val != 1) + return -EINVAL; + xfs_stats_clearall(); + return count; +} +XFS_SYSFS_ATTR_WO(stats_clear); + +static struct attribute *xfs_stats_attrs[] = { + ATTR_LIST(stats), + ATTR_LIST(stats_clear), + NULL, +}; + +STATIC ssize_t +xfs_stats_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; +} + +STATIC ssize_t +xfs_stats_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; +} + +static struct sysfs_ops xfs_stats_ops = { + .show = xfs_stats_show, + .store = xfs_stats_store, +}; + +struct kobj_type xfs_stats_ktype = { + .release = xfs_sysfs_release, + .sysfs_ops = &xfs_stats_ops, + .default_attrs = xfs_stats_attrs, +}; + /* xlog */ STATIC ssize_t diff --git a/fs/xfs/xfs_sysfs.h b/fs/xfs/xfs_sysfs.h index 240eee3..be692e5 100644 --- a/fs/xfs/xfs_sysfs.h +++ b/fs/xfs/xfs_sysfs.h @@ -22,6 +22,7 @@ extern struct kobj_type xfs_mp_ktype; /* xfs_mount */ extern struct kobj_type xfs_dbg_ktype; /* debug */ extern struct kobj_type xfs_log_ktype; /* xlog */ +extern struct kobj_type xfs_stats_ktype; /* stats */ static inline struct xfs_kobj * to_kobj(struct kobject *kobject) -- 2.4.3 From billodo@redhat.com Mon Sep 28 16:33:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 2FD257F37 for ; Mon, 28 Sep 2015 16:33:20 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id A4054AC003 for ; Mon, 28 Sep 2015 14:33:16 -0700 (PDT) X-ASG-Debug-ID: 1443475994-04cb6c6b07132bd0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id jczrNLnVoYEMkSdY (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 14:33:15 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 844FCAB123 for ; Mon, 28 Sep 2015 21:33:14 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-26.rdu2.redhat.com [10.10.55.26]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SLXDo3005461 for ; Mon, 28 Sep 2015 17:33:14 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 0/7 v9] xfs: stats in sysfs Date: Mon, 28 Sep 2015 16:33:01 -0500 X-ASG-Orig-Subj: [PATCH 0/7 v9] xfs: stats in sysfs Message-Id: <1443475988-15251-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443475995 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hello- Following is the next iteration of the series to add xfs stats to sysfs. ----------history--------------- v9: -adjust individual patch content, so that fixes actually correspond to reviews accordingly. -fix xfs_btree.h XFS_BTREE_STATS_ADD macro error made in patch 7. -fix xfs_stats.h macro style errors made in patch 7 v8: (add patches 6 and 7) -patch 6: per-filesystem stats in sysfs. Implement per-filesystem stats objects in sysfs. Stats objects are instantiated when an xfs filesystem is mounted and deleted on unmount. With this patch, the stats directory is created and populated with the familiar stats and stats_clear files. Example: /sys/fs/xfs/sda9/stats/stats /sys/fs/xfs/sda9/stats/stats_clear With this patch, the individual counts within the new per-fs stats file(s) remain at zero. Functions that use the the macros to increment, decrement, and add-to the per-fs stats counts will be covered in the next patch (7). -patch 7: per-filesystem stats counter implementation Modify the stats counting macros and the callers to those macros to properly increment, decrement, and add-to the xfs stats counts. The counts for global and per-fs stats are correctly advanced, and cleared by writing a "1" to the corresponding clear file. global counts: /sys/fs/xfs/stats/stats per-fs counts: /sys/fs/xfs/sda*/stats/stats global clear: /sys/fs/xfs/stats/stats_clear per-fs clear: /sys/fs/xfs/sda*/stats/stats_clear v7: add patch 5/5: incorporate sysfs/kobject in xfsstats: handlers take kobjects. Allocate & deallocate per-fs stats structures and set up the sysfs entries for them. Add kobject and a pointer to a per-cpu struct xfsstats. Modify the macros that manipulate the stats accordingly. v6: -move to_xlog(kobject) to the relevant show/store operations. This keeps the xfs_sysfs_object_show/store functions generic. Also, with the change, there can be some cleanup of the show/store function arguments. v5: -optimization of sysfs_ops function. -style fixups v4: -add patch 4 (sysfs ops consolidation - dbg, stats, log) v3: -style fixups. v2: -style fixups. v1: -------------------------------- We already have per-fs information in /sys, so it makes sense to have per-fs stats there too. The series moves existing global stats infrastructure to /sys and reuses that code to create per-fs stats in /sys. Patch 1 handles the bring-up and tear down of xfs/stats directory structure in sysfs when an fs is mounted. The directory contains the stats file and the stats_clear file. The stats file contents mimic those of /proc/fs/xfs/stat. The stats_clear file is empty, and much like the current stat_clear command, handles the zeroing of the stats file when a "1" is echoed to the stats_clear file. Patch 2 creates the symlink for stats from procfs to sysfs. Patch 3 removes the now unused portions of procfs for stat. Patch 4 consolidates the sysfs ops for dbg, stats, log. Patch 5 allocates and deallocates per-fs stats structures and sets up the sysfs entries for them. Add kobject and a pointer to a per-cpu struct xfsstats. Modify the macros that manipulate Patch 6 implements per-filesystem stats objects in sysfs. Stats objects are instantiated when an xfs filesystem is mounted and deleted on unmount. Patch 7 modifies the stats counting macros and the callers to those macros to properly increment, decrement, and add-to the xfs stats counts. The counts for global and per-fs stats are correctly advanced, and cleared by writing a "1" to the corresponding clear file. Once again, comments and questions are welcome. Thanks- Bill From billodo@redhat.com Mon Sep 28 16:33:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 362217F51 for ; Mon, 28 Sep 2015 16:33:20 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id AA752AC005 for ; Mon, 28 Sep 2015 14:33:19 -0700 (PDT) X-ASG-Debug-ID: 1443475997-04cb6c6b05132bd0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id T11Jw8SQbjF15Tgo (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 14:33:17 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 67208C0798E0 for ; Mon, 28 Sep 2015 21:33:17 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-26.rdu2.redhat.com [10.10.55.26]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SLXDo7005461 for ; Mon, 28 Sep 2015 17:33:16 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 4/7] xfs: consolidate sysfs ops (dbg, stats, log) Date: Mon, 28 Sep 2015 16:33:05 -0500 X-ASG-Orig-Subj: [PATCH 4/7] xfs: consolidate sysfs ops (dbg, stats, log) Message-Id: <1443475988-15251-5-git-send-email-billodo@redhat.com> In-Reply-To: <1443475988-15251-1-git-send-email-billodo@redhat.com> References: <1443475988-15251-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443475997 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the series to move xfs global stats from procfs to sysfs, this patch consolidates the sysfs ops functions and removes redundancy. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_sysfs.c | 182 +++++++++++++++++++---------------------------------- 1 file changed, 63 insertions(+), 119 deletions(-) diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index a094e20..ab4850b 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -25,8 +25,9 @@ struct xfs_sysfs_attr { struct attribute attr; - ssize_t (*show)(char *buf, void *data); - ssize_t (*store)(const char *buf, size_t count, void *data); + ssize_t (*show)(struct kobject *kobject, char *buf); + ssize_t (*store)(struct kobject *kobject, const char *buf, + size_t count); }; static inline struct xfs_sysfs_attr * @@ -54,14 +55,42 @@ struct kobj_type xfs_mp_ktype = { .release = xfs_sysfs_release, }; +STATIC ssize_t +xfs_sysfs_object_show( + struct kobject *kobject, + struct attribute *attr, + char *buf) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->show ? xfs_attr->show(kobject, buf) : 0; +} + +STATIC ssize_t +xfs_sysfs_object_store( + struct kobject *kobject, + struct attribute *attr, + const char *buf, + size_t count) +{ + struct xfs_sysfs_attr *xfs_attr = to_attr(attr); + + return xfs_attr->store ? xfs_attr->store(kobject, buf, count) : 0; +} + +static const struct sysfs_ops xfs_sysfs_ops = { + .show = xfs_sysfs_object_show, + .store = xfs_sysfs_object_store, +}; + #ifdef DEBUG /* debug */ STATIC ssize_t log_recovery_delay_store( + struct kobject *kobject, const char *buf, - size_t count, - void *data) + size_t count) { int ret; int val; @@ -80,8 +109,8 @@ log_recovery_delay_store( STATIC ssize_t log_recovery_delay_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { return snprintf(buf, PAGE_SIZE, "%d\n", xfs_globals.log_recovery_delay); } @@ -92,49 +121,20 @@ static struct attribute *xfs_dbg_attrs[] = { NULL, }; -STATIC ssize_t -xfs_dbg_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; -} - -STATIC ssize_t -xfs_dbg_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; -} - -static struct sysfs_ops xfs_dbg_ops = { - .show = xfs_dbg_show, - .store = xfs_dbg_store, -}; - struct kobj_type xfs_dbg_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_dbg_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_dbg_attrs, }; #endif /* DEBUG */ - /* stats */ STATIC ssize_t stats_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { return xfs_stats_format(buf); } @@ -142,9 +142,9 @@ XFS_SYSFS_ATTR_RO(stats); STATIC ssize_t stats_clear_store( + struct kobject *kobject, const char *buf, - size_t count, - void *data) + size_t count) { int ret; int val; @@ -166,50 +166,30 @@ static struct attribute *xfs_stats_attrs[] = { NULL, }; -STATIC ssize_t -xfs_stats_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, NULL) : 0; -} - -STATIC ssize_t -xfs_stats_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, NULL) : 0; -} - -static struct sysfs_ops xfs_stats_ops = { - .show = xfs_stats_show, - .store = xfs_stats_store, -}; - struct kobj_type xfs_stats_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_stats_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_stats_attrs, }; /* xlog */ +static inline struct xlog * +to_xlog(struct kobject *kobject) +{ + struct xfs_kobj *kobj = to_kobj(kobject); + + return container_of(kobj, struct xlog, l_kobj); +} + STATIC ssize_t log_head_lsn_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { - struct xlog *log = data; int cycle; int block; + struct xlog *log = to_xlog(kobject); spin_lock(&log->l_icloglock); cycle = log->l_curr_cycle; @@ -222,12 +202,12 @@ XFS_SYSFS_ATTR_RO(log_head_lsn); STATIC ssize_t log_tail_lsn_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { - struct xlog *log = data; int cycle; int block; + struct xlog *log = to_xlog(kobject); xlog_crack_atomic_lsn(&log->l_tail_lsn, &cycle, &block); return snprintf(buf, PAGE_SIZE, "%d:%d\n", cycle, block); @@ -236,12 +216,13 @@ XFS_SYSFS_ATTR_RO(log_tail_lsn); STATIC ssize_t reserve_grant_head_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) + { - struct xlog *log = data; int cycle; int bytes; + struct xlog *log = to_xlog(kobject); xlog_crack_grant_head(&log->l_reserve_head.grant, &cycle, &bytes); return snprintf(buf, PAGE_SIZE, "%d:%d\n", cycle, bytes); @@ -250,12 +231,12 @@ XFS_SYSFS_ATTR_RO(reserve_grant_head); STATIC ssize_t write_grant_head_show( - char *buf, - void *data) + struct kobject *kobject, + char *buf) { - struct xlog *log = data; int cycle; int bytes; + struct xlog *log = to_xlog(kobject); xlog_crack_grant_head(&log->l_write_head.grant, &cycle, &bytes); return snprintf(buf, PAGE_SIZE, "%d:%d\n", cycle, bytes); @@ -270,45 +251,8 @@ static struct attribute *xfs_log_attrs[] = { NULL, }; -static inline struct xlog * -to_xlog(struct kobject *kobject) -{ - struct xfs_kobj *kobj = to_kobj(kobject); - return container_of(kobj, struct xlog, l_kobj); -} - -STATIC ssize_t -xfs_log_show( - struct kobject *kobject, - struct attribute *attr, - char *buf) -{ - struct xlog *log = to_xlog(kobject); - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->show ? xfs_attr->show(buf, log) : 0; -} - -STATIC ssize_t -xfs_log_store( - struct kobject *kobject, - struct attribute *attr, - const char *buf, - size_t count) -{ - struct xlog *log = to_xlog(kobject); - struct xfs_sysfs_attr *xfs_attr = to_attr(attr); - - return xfs_attr->store ? xfs_attr->store(buf, count, log) : 0; -} - -static struct sysfs_ops xfs_log_ops = { - .show = xfs_log_show, - .store = xfs_log_store, -}; - struct kobj_type xfs_log_ktype = { .release = xfs_sysfs_release, - .sysfs_ops = &xfs_log_ops, + .sysfs_ops = &xfs_sysfs_ops, .default_attrs = xfs_log_attrs, }; -- 2.4.3 From billodo@redhat.com Mon Sep 28 16:33:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 5D60B29DF6 for ; Mon, 28 Sep 2015 16:33:20 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id ED648AC008 for ; Mon, 28 Sep 2015 14:33:16 -0700 (PDT) X-ASG-Debug-ID: 1443475995-04bdf0462613de10001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 2vAEBaf98ez2d96G (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 14:33:16 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id DCA12AD026 for ; Mon, 28 Sep 2015 21:33:15 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-26.rdu2.redhat.com [10.10.55.26]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SLXDo5005461 for ; Mon, 28 Sep 2015 17:33:15 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 2/7] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Date: Mon, 28 Sep 2015 16:33:03 -0500 X-ASG-Orig-Subj: [PATCH 2/7] xfs: create symlink proc/fs/xfs/stat to sys/fs/xfs/stats Message-Id: <1443475988-15251-3-git-send-email-billodo@redhat.com> In-Reply-To: <1443475988-15251-1-git-send-email-billodo@redhat.com> References: <1443475988-15251-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443475996 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 As a part of the work to move xfs global stats from procfs to sysfs, this patch creates the symlink from proc/fs/xfs/stat to sys/fs/xfs/stats. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_stats.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 0d6ec33..afd19e1 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -244,9 +244,10 @@ xfs_init_procfs(void) if (!proc_mkdir("fs/xfs", NULL)) goto out; - if (!proc_create("fs/xfs/stat", 0, NULL, - &xfs_stat_proc_fops)) + if (!proc_symlink("fs/xfs/stat", NULL, + "/sys/fs/xfs/stats/stats")) goto out_remove_xfs_dir; + #ifdef CONFIG_XFS_QUOTA if (!proc_create("fs/xfs/xqmstat", 0, NULL, &xqmstat_proc_fops)) -- 2.4.3 From billodo@redhat.com Mon Sep 28 16:33:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6CEB129DFE for ; Mon, 28 Sep 2015 16:33:20 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 5F8588F8052 for ; Mon, 28 Sep 2015 14:33:20 -0700 (PDT) X-ASG-Debug-ID: 1443475998-04cb6c6b04132bd0001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id xae41r22A5pTrQDf (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 14:33:18 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 2E467C0798E1 for ; Mon, 28 Sep 2015 21:33:18 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-26.rdu2.redhat.com [10.10.55.26]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SLXDo8005461 for ; Mon, 28 Sep 2015 17:33:17 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 5/7] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. Date: Mon, 28 Sep 2015 16:33:06 -0500 X-ASG-Orig-Subj: [PATCH 5/7] xfs: incorporate sysfs/kobject in xfsstats: handlers take kobjects. Message-Id: <1443475988-15251-6-git-send-email-billodo@redhat.com> In-Reply-To: <1443475988-15251-1-git-send-email-billodo@redhat.com> References: <1443475988-15251-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443475998 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 This patch is the next step toward per-fs xfs stats. The patch makes the show and clear routines able to handle any stats structure associated with a kobject. Instead of a single global xfsstats structure, add kobject and a pointer to a per-cpu struct xfsstats. Modify the macros that manipulate the stats accordingly: XFS_STATS_INC, XFS_STATS_DEC, and XFS_STATS_ADD now access xfsstats->xs_stats. The sysfs functions need to get from the kobject back to the xfsstats structure which contains it, and pass the pointer to the ->xs_stats percpu structure into the show & clear routines. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_linux.h | 7 +++++++ fs/xfs/xfs_stats.c | 34 ++++++++++++++++------------------ fs/xfs/xfs_stats.h | 22 +++++++++++----------- fs/xfs/xfs_super.c | 29 +++++++++++++++++++++-------- fs/xfs/xfs_sysctl.c | 2 +- fs/xfs/xfs_sysfs.c | 18 +++++++++++++++--- 6 files changed, 71 insertions(+), 41 deletions(-) diff --git a/fs/xfs/xfs_linux.h b/fs/xfs/xfs_linux.h index 85f883d..ec0e239 100644 --- a/fs/xfs/xfs_linux.h +++ b/fs/xfs/xfs_linux.h @@ -171,6 +171,13 @@ struct xfs_kobj { struct completion complete; }; +struct xstats { + struct xfsstats __percpu *xs_stats; + struct xfs_kobj xs_kobj; +}; + +extern struct xstats xfsstats; + /* Kernel uid/gid conversion. These are used to convert to/from the on disk * uid_t/gid_t types to the kuid_t/kgid_t types that the kernel uses internally. * The conversion here is type only, the value will remain the same since we diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index dc6ca67..3f9fc05 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -18,18 +18,18 @@ #include "xfs.h" #include -DEFINE_PER_CPU(struct xfsstats, xfsstats); +struct xstats xfsstats; -static int counter_val(int idx) +static int counter_val(struct xfsstats __percpu *stats, int idx) { int val = 0, cpu; for_each_possible_cpu(cpu) - val += *(((__u32 *)&per_cpu(xfsstats, cpu) + idx)); + val += *(((__u32 *)per_cpu_ptr(stats, cpu) + idx)); return val; } -int xfs_stats_format(char *buf) +int xfs_stats_format(struct xfsstats __percpu *stats, char *buf) { int i, j; int len = 0; @@ -73,14 +73,14 @@ int xfs_stats_format(char *buf) /* inner loop does each group */ for (; j < xstats[i].endpoint; j++) len += snprintf(buf + len, PATH_MAX - len, " %u", - counter_val(j)); + counter_val(stats, j)); len += snprintf(buf + len, PATH_MAX - len, "\n"); } /* extra precision counters */ for_each_possible_cpu(i) { - xs_xstrat_bytes += per_cpu(xfsstats, i).xs_xstrat_bytes; - xs_write_bytes += per_cpu(xfsstats, i).xs_write_bytes; - xs_read_bytes += per_cpu(xfsstats, i).xs_read_bytes; + xs_xstrat_bytes += per_cpu_ptr(stats, i)->xs_xstrat_bytes; + xs_write_bytes += per_cpu_ptr(stats, i)->xs_write_bytes; + xs_read_bytes += per_cpu_ptr(stats, i)->xs_read_bytes; } len += snprintf(buf+len, PATH_MAX-len, "xpc %Lu %Lu %Lu\n", @@ -95,7 +95,7 @@ int xfs_stats_format(char *buf) return len; } -void xfs_stats_clearall(void) +void xfs_stats_clearall(struct xfsstats __percpu *stats) { int c; __uint32_t vn_active; @@ -104,10 +104,9 @@ void xfs_stats_clearall(void) for_each_possible_cpu(c) { preempt_disable(); /* save vn_active, it's a universal truth! */ - vn_active = per_cpu(xfsstats, c).vn_active; - memset(&per_cpu(xfsstats, c), 0, - sizeof(struct xfsstats)); - per_cpu(xfsstats, c).vn_active = vn_active; + vn_active = per_cpu_ptr(stats, c)->vn_active; + memset(per_cpu_ptr(stats, c), 0, sizeof(*stats)); + per_cpu_ptr(stats, c)->vn_active = vn_active; preempt_enable(); } } @@ -118,10 +117,9 @@ static int xqm_proc_show(struct seq_file *m, void *v) { /* maximum; incore; ratio free to inuse; freelist */ seq_printf(m, "%d\t%d\t%d\t%u\n", - 0, - counter_val(XFSSTAT_END_XQMSTAT), - 0, - counter_val(XFSSTAT_END_XQMSTAT + 1)); + 0, counter_val(xfsstats.xs_stats, XFSSTAT_END_XQMSTAT), + 0, counter_val(xfsstats.xs_stats, + XFSSTAT_END_XQMSTAT + 1)); return 0; } @@ -145,7 +143,7 @@ static int xqmstat_proc_show(struct seq_file *m, void *v) seq_printf(m, "qm"); for (j = XFSSTAT_END_IBT_V2; j < XFSSTAT_END_XQMSTAT; j++) - seq_printf(m, " %u", counter_val(j)); + seq_printf(m, " %u", counter_val(xfsstats.xs_stats, j)); seq_putc(m, '\n'); return 0; } diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index 18807b5..211e36f 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -18,9 +18,6 @@ #ifndef __XFS_STATS_H__ #define __XFS_STATS_H__ -int xfs_stats_format(char *buf); -void xfs_stats_clearall(void); - #if defined(CONFIG_PROC_FS) && !defined(XFS_STATS_OFF) #include @@ -217,15 +214,18 @@ struct xfsstats { __uint64_t xs_read_bytes; }; -DECLARE_PER_CPU(struct xfsstats, xfsstats); +int xfs_stats_format(struct xfsstats __percpu *stats, char *buf); +void xfs_stats_clearall(struct xfsstats __percpu *stats); +extern struct xstats xfsstats; -/* - * We don't disable preempt, not too worried about poking the - * wrong CPU's stat for now (also aggregated before reporting). - */ -#define XFS_STATS_INC(v) (per_cpu(xfsstats, current_cpu()).v++) -#define XFS_STATS_DEC(v) (per_cpu(xfsstats, current_cpu()).v--) -#define XFS_STATS_ADD(v, inc) (per_cpu(xfsstats, current_cpu()).v += (inc)) +#define XFS_STATS_INC(v) \ + per_cpu_ptr(xfsstats.xs_stats, current_cpu())->v++; + +#define XFS_STATS_DEC(v) \ + per_cpu_ptr(xfsstats.xs_stats, current_cpu())->v--; + +#define XFS_STATS_ADD(v, inc) \ + per_cpu_ptr(xfsstats.xs_stats, current_cpu())->v += (inc); extern int xfs_init_procfs(void); extern void xfs_cleanup_procfs(void); diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 0dfc53b..5901336 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -61,7 +61,6 @@ static kmem_zone_t *xfs_ioend_zone; mempool_t *xfs_ioend_pool; static struct kset *xfs_kset; /* top-level xfs sysfs dir */ -static struct xfs_kobj xfs_stats_kobj; /* global stats sysfs attrs */ #ifdef DEBUG static struct xfs_kobj xfs_dbg_kobj; /* global debug sysfs attrs */ #endif @@ -1842,17 +1841,28 @@ init_xfs_fs(void) goto out_sysctl_unregister; } - xfs_stats_kobj.kobject.kset = xfs_kset; - error = xfs_sysfs_init(&xfs_stats_kobj, &xfs_stats_ktype, NULL, + xfsstats.xs_stats = alloc_percpu(struct xfsstats); + if (!xfsstats.xs_stats) { + error = -ENOMEM; + goto out_kset_unregister; + } + + xfsstats.xs_kobj.kobject.kset = xfs_kset; + if (!xfsstats.xs_kobj.kobject.kset) { + error = -ENOMEM; + goto out_free_stats; + } + + error = xfs_sysfs_init(&xfsstats.xs_kobj, &xfs_stats_ktype, NULL, "stats"); if (error) - goto out_kset_unregister; + goto out_free_stats; #ifdef DEBUG xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_remove_stats_kobj; + goto out_del_stats; #endif error = xfs_qm_init(); @@ -1869,9 +1879,11 @@ init_xfs_fs(void) out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_remove_stats_kobj: + out_del_stats: #endif - xfs_sysfs_del(&xfs_stats_kobj); + xfs_sysfs_del(&xfsstats.xs_kobj); + out_free_stats: + free_percpu(xfsstats.xs_stats); out_kset_unregister: kset_unregister(xfs_kset); out_sysctl_unregister: @@ -1898,7 +1910,8 @@ exit_xfs_fs(void) #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); #endif - xfs_sysfs_del(&xfs_stats_kobj); + xfs_sysfs_del(&xfsstats.xs_kobj); + free_percpu(xfsstats.xs_stats); kset_unregister(xfs_kset); xfs_sysctl_unregister(); xfs_cleanup_procfs(); diff --git a/fs/xfs/xfs_sysctl.c b/fs/xfs/xfs_sysctl.c index 5defabb..aed74d3 100644 --- a/fs/xfs/xfs_sysctl.c +++ b/fs/xfs/xfs_sysctl.c @@ -37,7 +37,7 @@ xfs_stats_clear_proc_handler( ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); if (!ret && write && *valp) { - xfs_stats_clearall(); + xfs_stats_clearall(xfsstats.xs_stats); xfs_stats_clear = 0; } diff --git a/fs/xfs/xfs_sysfs.c b/fs/xfs/xfs_sysfs.c index ab4850b..6fe4b67 100644 --- a/fs/xfs/xfs_sysfs.c +++ b/fs/xfs/xfs_sysfs.c @@ -131,12 +131,22 @@ struct kobj_type xfs_dbg_ktype = { /* stats */ +static inline struct xstats * +to_xstats(struct kobject *kobject) +{ + struct xfs_kobj *kobj = to_kobj(kobject); + + return container_of(kobj, struct xstats, xs_kobj); +} + STATIC ssize_t stats_show( struct kobject *kobject, - char *buf) + char *buf) { - return xfs_stats_format(buf); + struct xstats *stats = to_xstats(kobject); + + return xfs_stats_format(stats->xs_stats, buf); } XFS_SYSFS_ATTR_RO(stats); @@ -148,6 +158,7 @@ stats_clear_store( { int ret; int val; + struct xstats *stats = to_xstats(kobject); ret = kstrtoint(buf, 0, &val); if (ret) @@ -155,7 +166,8 @@ stats_clear_store( if (val != 1) return -EINVAL; - xfs_stats_clearall(); + + xfs_stats_clearall(stats->xs_stats); return count; } XFS_SYSFS_ATTR_WO(stats_clear); -- 2.4.3 From billodo@redhat.com Mon Sep 28 16:33:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A806929E06 for ; Mon, 28 Sep 2015 16:33:20 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 42A2BAC002 for ; Mon, 28 Sep 2015 14:33:20 -0700 (PDT) X-ASG-Debug-ID: 1443475999-04bdf0462813de20001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id DDfq6fOOcra1ldjz (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 14:33:19 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E9DDDC0A1479 for ; Mon, 28 Sep 2015 21:33:18 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-26.rdu2.redhat.com [10.10.55.26]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SLXDo9005461 for ; Mon, 28 Sep 2015 17:33:18 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 6/7] xfs: per-filesystem stats in sysfs. Date: Mon, 28 Sep 2015 16:33:07 -0500 X-ASG-Orig-Subj: [PATCH 6/7] xfs: per-filesystem stats in sysfs. Message-Id: <1443475988-15251-7-git-send-email-billodo@redhat.com> In-Reply-To: <1443475988-15251-1-git-send-email-billodo@redhat.com> References: <1443475988-15251-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443475999 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 This patch implements per-filesystem stats objects in sysfs. It depends on the application of the previous patch series that develops the infrastructure to support both xfs global stats and xfs per-fs stats in sysfs. Stats objects are instantiated when an xfs filesystem is mounted and deleted on unmount. With this patch, the stats directory is created and populated with the familiar stats and stats_clear files. Example: /sys/fs/xfs/sda9/stats/stats /sys/fs/xfs/sda9/stats/stats_clear With this patch, the individual counts within the new per-fs stats file(s) remain at zero. Functions that use the the macros to increment, decrement, and add-to the per-fs stats counts will be covered in a separate new patch to follow this one. Note that the counts within the global stats file (/sys/fs/xfs/stats/stats) advance normally and can be cleared as it was prior to this patch. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_mount.c | 24 +++++++++++++++++++++++- fs/xfs/xfs_mount.h | 1 + fs/xfs/xfs_stats.c | 5 +++++ fs/xfs/xfs_super.c | 12 ++++-------- 4 files changed, 33 insertions(+), 9 deletions(-) diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index bf92e0c..89ac1bd 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -693,9 +693,23 @@ xfs_mountfs( if (error) goto out; + /* + * Allocate stats memory and create stats sysfs object. + */ + mp->m_stats.xs_stats = alloc_percpu(struct xfsstats); + if (!mp->m_stats.xs_stats) { + error = PTR_ERR(mp->m_stats.xs_stats); + goto out_remove_sysfs; + } + error = xfs_sysfs_init(&mp->m_stats.xs_kobj, &xfs_stats_ktype, + &mp->m_kobj, + "stats"); + if (error) + goto out_free_stats; + error = xfs_uuid_mount(mp); if (error) - goto out_remove_sysfs; + goto out_del_stats; /* * Set the minimum read and write sizes @@ -971,6 +985,10 @@ xfs_mountfs( xfs_da_unmount(mp); out_remove_uuid: xfs_uuid_unmount(mp); + out_del_stats: + xfs_sysfs_del(&mp->m_stats.xs_kobj); + out_free_stats: + free_percpu(mp->m_stats.xs_stats); out_remove_sysfs: xfs_sysfs_del(&mp->m_kobj); out: @@ -1047,6 +1065,10 @@ xfs_unmountfs( xfs_warn(mp, "Unable to update superblock counters. " "Freespace may not be correct on next mount."); + /* remove the stats kobject and free stats memory */ + xfs_sysfs_del(&mp->m_stats.xs_kobj); + free_percpu(mp->m_stats.xs_stats); + xfs_log_unmount(mp); xfs_da_unmount(mp); xfs_uuid_unmount(mp); diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 7999e91..8795272 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -127,6 +127,7 @@ typedef struct xfs_mount { int64_t m_low_space[XFS_LOWSP_MAX]; /* low free space thresholds */ struct xfs_kobj m_kobj; + struct xstats m_stats; /* per-fs stats */ struct workqueue_struct *m_buf_workqueue; struct workqueue_struct *m_data_workqueue; diff --git a/fs/xfs/xfs_stats.c b/fs/xfs/xfs_stats.c index 3f9fc05..ef888bb 100644 --- a/fs/xfs/xfs_stats.c +++ b/fs/xfs/xfs_stats.c @@ -18,6 +18,11 @@ #include "xfs.h" #include +//#include "xfs_format.h" +//#include "xfs_trans_resv.h" +//#include "xfs_mount.h" +//#include "xfs_sysfs.h" + struct xstats xfsstats; static int counter_val(struct xfsstats __percpu *stats, int idx) diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 5901336..68d4976 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1841,18 +1841,14 @@ init_xfs_fs(void) goto out_sysctl_unregister; } + xfsstats.xs_kobj.kobject.kset = xfs_kset; + xfsstats.xs_stats = alloc_percpu(struct xfsstats); if (!xfsstats.xs_stats) { error = -ENOMEM; goto out_kset_unregister; } - xfsstats.xs_kobj.kobject.kset = xfs_kset; - if (!xfsstats.xs_kobj.kobject.kset) { - error = -ENOMEM; - goto out_free_stats; - } - error = xfs_sysfs_init(&xfsstats.xs_kobj, &xfs_stats_ktype, NULL, "stats"); if (error) @@ -1862,7 +1858,7 @@ init_xfs_fs(void) xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_del_stats; + goto out_remove_stats_obj; #endif error = xfs_qm_init(); @@ -1879,7 +1875,7 @@ init_xfs_fs(void) out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_del_stats: + out_remove_stats_obj: #endif xfs_sysfs_del(&xfsstats.xs_kobj); out_free_stats: -- 2.4.3 From billodo@redhat.com Mon Sep 28 16:33:23 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id D4D0729E09 for ; Mon, 28 Sep 2015 16:33:23 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 9AF97304051 for ; Mon, 28 Sep 2015 14:33:23 -0700 (PDT) X-ASG-Debug-ID: 1443475999-04bdf0462713de20001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id K65WHItHQRyIL0RZ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 14:33:19 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id AE76C8EA2F for ; Mon, 28 Sep 2015 21:33:19 +0000 (UTC) Received: from localhost.localdomain.com (vpn-55-26.rdu2.redhat.com [10.10.55.26]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SLXDoA005461 for ; Mon, 28 Sep 2015 17:33:19 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 7/7] xfs: per-filesystem stats counter implementation Date: Mon, 28 Sep 2015 16:33:08 -0500 X-ASG-Orig-Subj: [PATCH 7/7] xfs: per-filesystem stats counter implementation Message-Id: <1443475988-15251-8-git-send-email-billodo@redhat.com> In-Reply-To: <1443475988-15251-1-git-send-email-billodo@redhat.com> References: <1443475988-15251-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443475999 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 This patch modifies the stats counting macros and the callers to those macros to properly increment, decrement, and add-to the xfs stats counts. The counts for global and per-fs stats are correctly advanced, and cleared by writing a "1" to the corresponding clear file. global counts: /sys/fs/xfs/stats/stats per-fs counts: /sys/fs/xfs/sda*/stats/stats global clear: /sys/fs/xfs/stats/stats_clear per-fs clear: /sys/fs/xfs/sda*/stats/stats_clear Signed-off-by: Bill O'Donnell --- fs/xfs/libxfs/xfs_alloc.c | 8 ++++---- fs/xfs/libxfs/xfs_attr.c | 6 +++--- fs/xfs/libxfs/xfs_bmap.c | 20 ++++++++++---------- fs/xfs/libxfs/xfs_btree.h | 34 ++++++++++++++++++---------------- fs/xfs/libxfs/xfs_dir2.c | 6 +++--- fs/xfs/xfs_attr_list.c | 2 +- fs/xfs/xfs_buf.c | 18 +++++++++--------- fs/xfs/xfs_dir2_readdir.c | 2 +- fs/xfs/xfs_dquot.c | 12 ++++++------ fs/xfs/xfs_file.c | 12 ++++++------ fs/xfs/xfs_icache.c | 18 +++++++++--------- fs/xfs/xfs_inode.c | 6 +++--- fs/xfs/xfs_ioctl.c | 2 +- fs/xfs/xfs_iomap.c | 4 ++-- fs/xfs/xfs_iops.c | 4 ++-- fs/xfs/xfs_log.c | 22 +++++++++++----------- fs/xfs/xfs_qm.c | 14 +++++++------- fs/xfs/xfs_stats.h | 21 +++++++++++++++------ fs/xfs/xfs_super.c | 6 +++--- fs/xfs/xfs_trans.c | 6 +++--- fs/xfs/xfs_trans_ail.c | 12 ++++++------ 21 files changed, 123 insertions(+), 112 deletions(-) diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c index ffad7f2..9b5da7e3 100644 --- a/fs/xfs/libxfs/xfs_alloc.c +++ b/fs/xfs/libxfs/xfs_alloc.c @@ -651,8 +651,8 @@ xfs_alloc_ag_vextent( -((long)(args->len))); } - XFS_STATS_INC(xs_allocx); - XFS_STATS_ADD(xs_allocb, args->len); + XFS_STATS_INC(args->mp, xs_allocx); + XFS_STATS_ADD(args->mp, xs_allocb, args->len); return error; } @@ -1808,8 +1808,8 @@ xfs_free_ag_extent( if (!isfl) xfs_trans_mod_sb(tp, XFS_TRANS_SB_FDBLOCKS, (long)len); - XFS_STATS_INC(xs_freex); - XFS_STATS_ADD(xs_freeb, len); + XFS_STATS_INC(mp, xs_freex); + XFS_STATS_ADD(mp, xs_freeb, len); trace_xfs_free_extent(mp, agno, bno, len, isfl, haveleft, haveright); diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c index ff06557..f949818 100644 --- a/fs/xfs/libxfs/xfs_attr.c +++ b/fs/xfs/libxfs/xfs_attr.c @@ -125,7 +125,7 @@ xfs_attr_get( uint lock_mode; int error; - XFS_STATS_INC(xs_attr_get); + XFS_STATS_INC(ip->i_mount, xs_attr_get); if (XFS_FORCED_SHUTDOWN(ip->i_mount)) return -EIO; @@ -209,7 +209,7 @@ xfs_attr_set( int rsvd = (flags & ATTR_ROOT) != 0; int error, err2, committed, local; - XFS_STATS_INC(xs_attr_set); + XFS_STATS_INC(mp, xs_attr_set); if (XFS_FORCED_SHUTDOWN(dp->i_mount)) return -EIO; @@ -412,7 +412,7 @@ xfs_attr_remove( xfs_fsblock_t firstblock; int error; - XFS_STATS_INC(xs_attr_remove); + XFS_STATS_INC(mp, xs_attr_remove); if (XFS_FORCED_SHUTDOWN(dp->i_mount)) return -EIO; diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c index 8e2010d..5256fe5 100644 --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -1435,7 +1435,7 @@ xfs_bmap_search_extents( xfs_ifork_t *ifp; /* inode fork pointer */ xfs_bmbt_rec_host_t *ep; /* extent record pointer */ - XFS_STATS_INC(xs_look_exlist); + XFS_STATS_INC(ip->i_mount, xs_look_exlist); ifp = XFS_IFORK_PTR(ip, fork); ep = xfs_bmap_search_multi_extents(ifp, bno, eofp, lastxp, gotp, prevp); @@ -1732,7 +1732,7 @@ xfs_bmap_add_extent_delay_real( ASSERT(!bma->cur || (bma->cur->bc_private.b.flags & XFS_BTCUR_BPRV_WASDEL)); - XFS_STATS_INC(xs_add_exlist); + XFS_STATS_INC(mp, xs_add_exlist); #define LEFT r[0] #define RIGHT r[1] @@ -2286,7 +2286,7 @@ xfs_bmap_add_extent_unwritten_real( ASSERT(*idx <= ifp->if_bytes / sizeof(struct xfs_bmbt_rec)); ASSERT(!isnullstartblock(new->br_startblock)); - XFS_STATS_INC(xs_add_exlist); + XFS_STATS_INC(mp, xs_add_exlist); #define LEFT r[0] #define RIGHT r[1] @@ -2946,7 +2946,7 @@ xfs_bmap_add_extent_hole_real( ASSERT(!bma->cur || !(bma->cur->bc_private.b.flags & XFS_BTCUR_BPRV_WASDEL)); - XFS_STATS_INC(xs_add_exlist); + XFS_STATS_INC(mp, xs_add_exlist); state = 0; if (whichfork == XFS_ATTR_FORK) @@ -4036,7 +4036,7 @@ xfs_bmapi_read( if (XFS_FORCED_SHUTDOWN(mp)) return -EIO; - XFS_STATS_INC(xs_blk_mapr); + XFS_STATS_INC(mp, xs_blk_mapr); ifp = XFS_IFORK_PTR(ip, whichfork); @@ -4221,7 +4221,7 @@ xfs_bmapi_delay( if (XFS_FORCED_SHUTDOWN(mp)) return -EIO; - XFS_STATS_INC(xs_blk_mapw); + XFS_STATS_INC(mp, xs_blk_mapw); if (!(ifp->if_flags & XFS_IFEXTENTS)) { error = xfs_iread_extents(NULL, ip, XFS_DATA_FORK); @@ -4525,7 +4525,7 @@ xfs_bmapi_write( ifp = XFS_IFORK_PTR(ip, whichfork); - XFS_STATS_INC(xs_blk_mapw); + XFS_STATS_INC(mp, xs_blk_mapw); if (*firstblock == NULLFSBLOCK) { if (XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_BTREE) @@ -4718,12 +4718,12 @@ xfs_bmap_del_extent( xfs_filblks_t temp2; /* for indirect length calculations */ int state = 0; - XFS_STATS_INC(xs_del_exlist); + mp = ip->i_mount; + XFS_STATS_INC(mp, xs_del_exlist); if (whichfork == XFS_ATTR_FORK) state |= BMAP_ATTRFORK; - mp = ip->i_mount; ifp = XFS_IFORK_PTR(ip, whichfork); ASSERT((*idx >= 0) && (*idx < ifp->if_bytes / (uint)sizeof(xfs_bmbt_rec_t))); @@ -5070,7 +5070,7 @@ xfs_bunmapi( *done = 1; return 0; } - XFS_STATS_INC(xs_blk_unmap); + XFS_STATS_INC(mp, xs_blk_unmap); isrt = (whichfork == XFS_DATA_FORK) && XFS_IS_REALTIME_INODE(ip); start = bno; bno = start + len - 1; diff --git a/fs/xfs/libxfs/xfs_btree.h b/fs/xfs/libxfs/xfs_btree.h index 8f18bab..ec72825 100644 --- a/fs/xfs/libxfs/xfs_btree.h +++ b/fs/xfs/libxfs/xfs_btree.h @@ -84,31 +84,33 @@ union xfs_btree_rec { /* * Generic stats interface */ -#define __XFS_BTREE_STATS_INC(type, stat) \ - XFS_STATS_INC(xs_ ## type ## _2_ ## stat) -#define XFS_BTREE_STATS_INC(cur, stat) \ +#define __XFS_BTREE_STATS_INC(mp, type, stat) \ + XFS_STATS_INC(mp, xs_ ## type ## _2_ ## stat) +#define XFS_BTREE_STATS_INC(cur, stat) \ do { \ + struct xfs_mount *mp = cur->bc_mp; \ switch (cur->bc_btnum) { \ - case XFS_BTNUM_BNO: __XFS_BTREE_STATS_INC(abtb, stat); break; \ - case XFS_BTNUM_CNT: __XFS_BTREE_STATS_INC(abtc, stat); break; \ - case XFS_BTNUM_BMAP: __XFS_BTREE_STATS_INC(bmbt, stat); break; \ - case XFS_BTNUM_INO: __XFS_BTREE_STATS_INC(ibt, stat); break; \ - case XFS_BTNUM_FINO: __XFS_BTREE_STATS_INC(fibt, stat); break; \ + case XFS_BTNUM_BNO: __XFS_BTREE_STATS_INC(mp, abtb, stat); break; \ + case XFS_BTNUM_CNT: __XFS_BTREE_STATS_INC(mp, abtc, stat); break; \ + case XFS_BTNUM_BMAP: __XFS_BTREE_STATS_INC(mp, bmbt, stat); break; \ + case XFS_BTNUM_INO: __XFS_BTREE_STATS_INC(mp, ibt, stat); break; \ + case XFS_BTNUM_FINO: __XFS_BTREE_STATS_INC(mp, fibt, stat); break; \ case XFS_BTNUM_MAX: ASSERT(0); /* fucking gcc */ ; break; \ } \ } while (0) -#define __XFS_BTREE_STATS_ADD(type, stat, val) \ - XFS_STATS_ADD(xs_ ## type ## _2_ ## stat, val) +#define __XFS_BTREE_STATS_ADD(mp, type, stat, val) \ + XFS_STATS_ADD(mp, xs_ ## type ## _2_ ## stat, val) #define XFS_BTREE_STATS_ADD(cur, stat, val) \ do { \ + struct xfs_mount *mp = cur->bc_mp; \ switch (cur->bc_btnum) { \ - case XFS_BTNUM_BNO: __XFS_BTREE_STATS_ADD(abtb, stat, val); break; \ - case XFS_BTNUM_CNT: __XFS_BTREE_STATS_ADD(abtc, stat, val); break; \ - case XFS_BTNUM_BMAP: __XFS_BTREE_STATS_ADD(bmbt, stat, val); break; \ - case XFS_BTNUM_INO: __XFS_BTREE_STATS_ADD(ibt, stat, val); break; \ - case XFS_BTNUM_FINO: __XFS_BTREE_STATS_ADD(fibt, stat, val); break; \ - case XFS_BTNUM_MAX: ASSERT(0); /* fucking gcc */ ; break; \ + case XFS_BTNUM_BNO: __XFS_BTREE_STATS_ADD(mp, abtb, stat, val); break; \ + case XFS_BTNUM_CNT: __XFS_BTREE_STATS_ADD(mp, abtc, stat, val); break; \ + case XFS_BTNUM_BMAP: __XFS_BTREE_STATS_ADD(mp, bmbt, stat, val); break; \ + case XFS_BTNUM_INO: __XFS_BTREE_STATS_ADD(mp, ibt, stat, val); break; \ + case XFS_BTNUM_FINO: __XFS_BTREE_STATS_ADD(mp, fibt, stat, val); break; \ + case XFS_BTNUM_MAX: ASSERT(0); /* fucking gcc */ ; break; \ } \ } while (0) diff --git a/fs/xfs/libxfs/xfs_dir2.c b/fs/xfs/libxfs/xfs_dir2.c index 9de401d..2fb53a5 100644 --- a/fs/xfs/libxfs/xfs_dir2.c +++ b/fs/xfs/libxfs/xfs_dir2.c @@ -271,7 +271,7 @@ xfs_dir_createname( rval = xfs_dir_ino_validate(tp->t_mountp, inum); if (rval) return rval; - XFS_STATS_INC(xs_dir_create); + XFS_STATS_INC(dp->i_mount, xs_dir_create); } args = kmem_zalloc(sizeof(*args), KM_SLEEP | KM_NOFS); @@ -365,7 +365,7 @@ xfs_dir_lookup( int lock_mode; ASSERT(S_ISDIR(dp->i_d.di_mode)); - XFS_STATS_INC(xs_dir_lookup); + XFS_STATS_INC(dp->i_mount, xs_dir_lookup); /* * We need to use KM_NOFS here so that lockdep will not throw false @@ -444,7 +444,7 @@ xfs_dir_removename( int v; /* type-checking value */ ASSERT(S_ISDIR(dp->i_d.di_mode)); - XFS_STATS_INC(xs_dir_remove); + XFS_STATS_INC(dp->i_mount, xs_dir_remove); args = kmem_zalloc(sizeof(*args), KM_SLEEP | KM_NOFS); if (!args) diff --git a/fs/xfs/xfs_attr_list.c b/fs/xfs/xfs_attr_list.c index 65fb37a..0ef7c2e 100644 --- a/fs/xfs/xfs_attr_list.c +++ b/fs/xfs/xfs_attr_list.c @@ -511,7 +511,7 @@ xfs_attr_list_int( xfs_inode_t *dp = context->dp; uint lock_mode; - XFS_STATS_INC(xs_attr_list); + XFS_STATS_INC(dp->i_mount, xs_attr_list); if (XFS_FORCED_SHUTDOWN(dp->i_mount)) return -EIO; diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index 8ecffb3..90815c2 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -201,7 +201,7 @@ _xfs_buf_alloc( atomic_set(&bp->b_pin_count, 0); init_waitqueue_head(&bp->b_waiters); - XFS_STATS_INC(xb_create); + XFS_STATS_INC(target->bt_mount, xb_create); trace_xfs_buf_init(bp, _RET_IP_); return bp; @@ -357,12 +357,12 @@ retry: "possible memory allocation deadlock in %s (mode:0x%x)", __func__, gfp_mask); - XFS_STATS_INC(xb_page_retries); + XFS_STATS_INC(bp->b_target->bt_mount, xb_page_retries); congestion_wait(BLK_RW_ASYNC, HZ/50); goto retry; } - XFS_STATS_INC(xb_page_found); + XFS_STATS_INC(bp->b_target->bt_mount, xb_page_found); nbytes = min_t(size_t, size, PAGE_SIZE - offset); size -= nbytes; @@ -516,7 +516,7 @@ _xfs_buf_find( new_bp->b_pag = pag; spin_unlock(&pag->pag_buf_lock); } else { - XFS_STATS_INC(xb_miss_locked); + XFS_STATS_INC(btp->bt_mount, xb_miss_locked); spin_unlock(&pag->pag_buf_lock); xfs_perag_put(pag); } @@ -529,11 +529,11 @@ found: if (!xfs_buf_trylock(bp)) { if (flags & XBF_TRYLOCK) { xfs_buf_rele(bp); - XFS_STATS_INC(xb_busy_locked); + XFS_STATS_INC(btp->bt_mount, xb_busy_locked); return NULL; } xfs_buf_lock(bp); - XFS_STATS_INC(xb_get_locked_waited); + XFS_STATS_INC(btp->bt_mount, xb_get_locked_waited); } /* @@ -549,7 +549,7 @@ found: } trace_xfs_buf_find(bp, flags, _RET_IP_); - XFS_STATS_INC(xb_get_locked); + XFS_STATS_INC(btp->bt_mount, xb_get_locked); return bp; } @@ -603,7 +603,7 @@ found: } } - XFS_STATS_INC(xb_get); + XFS_STATS_INC(target->bt_mount, xb_get); trace_xfs_buf_get(bp, flags, _RET_IP_); return bp; } @@ -643,7 +643,7 @@ xfs_buf_read_map( trace_xfs_buf_read(bp, flags, _RET_IP_); if (!XFS_BUF_ISDONE(bp)) { - XFS_STATS_INC(xb_get_read); + XFS_STATS_INC(target->bt_mount, xb_get_read); bp->b_ops = ops; _xfs_buf_read(bp, flags); } else if (flags & XBF_ASYNC) { diff --git a/fs/xfs/xfs_dir2_readdir.c b/fs/xfs/xfs_dir2_readdir.c index a989a9c..642d55d 100644 --- a/fs/xfs/xfs_dir2_readdir.c +++ b/fs/xfs/xfs_dir2_readdir.c @@ -666,7 +666,7 @@ xfs_readdir( return -EIO; ASSERT(S_ISDIR(dp->i_d.di_mode)); - XFS_STATS_INC(xs_dir_getdents); + XFS_STATS_INC(dp->i_mount, xs_dir_getdents); args.dp = dp; args.geo = dp->i_mount->m_dir_geo; diff --git a/fs/xfs/xfs_dquot.c b/fs/xfs/xfs_dquot.c index 30cb3af..c801a0b 100644 --- a/fs/xfs/xfs_dquot.c +++ b/fs/xfs/xfs_dquot.c @@ -77,7 +77,7 @@ xfs_qm_dqdestroy( mutex_destroy(&dqp->q_qlock); kmem_zone_free(xfs_qm_dqzone, dqp); - XFS_STATS_DEC(xs_qm_dquot); + XFS_STATS_DEC(dqp->q_mount, xs_qm_dquot); } /* @@ -605,7 +605,7 @@ xfs_qm_dqread( break; } - XFS_STATS_INC(xs_qm_dquot); + XFS_STATS_INC(dqp->q_mount, xs_qm_dquot); trace_xfs_dqread(dqp); @@ -747,12 +747,12 @@ restart: mutex_unlock(&qi->qi_tree_lock); trace_xfs_dqget_hit(dqp); - XFS_STATS_INC(xs_qm_dqcachehits); + XFS_STATS_INC(dqp->q_mount, xs_qm_dqcachehits); *O_dqpp = dqp; return 0; } mutex_unlock(&qi->qi_tree_lock); - XFS_STATS_INC(xs_qm_dqcachemisses); + XFS_STATS_INC(dqp->q_mount, xs_qm_dqcachemisses); /* * Dquot cache miss. We don't want to keep the inode lock across @@ -806,7 +806,7 @@ restart: mutex_unlock(&qi->qi_tree_lock); trace_xfs_dqget_dup(dqp); xfs_qm_dqdestroy(dqp); - XFS_STATS_INC(xs_qm_dquot_dups); + XFS_STATS_INC(dqp->q_mount, xs_qm_dquot_dups); goto restart; } @@ -846,7 +846,7 @@ xfs_qm_dqput( trace_xfs_dqput_free(dqp); if (list_lru_add(&qi->qi_lru, &dqp->q_lru)) - XFS_STATS_INC(xs_qm_dquot_unused); + XFS_STATS_INC(dqp->q_mount, xs_qm_dquot_unused); } xfs_dqunlock(dqp); } diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index e78feb4..088e509 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -287,7 +287,7 @@ xfs_file_read_iter( xfs_fsize_t n; loff_t pos = iocb->ki_pos; - XFS_STATS_INC(xs_read_calls); + XFS_STATS_INC(mp, xs_read_calls); if (unlikely(iocb->ki_flags & IOCB_DIRECT)) ioflags |= XFS_IO_ISDIRECT; @@ -365,7 +365,7 @@ xfs_file_read_iter( ret = generic_file_read_iter(iocb, to); if (ret > 0) - XFS_STATS_ADD(xs_read_bytes, ret); + XFS_STATS_ADD(mp, xs_read_bytes, ret); xfs_rw_iunlock(ip, XFS_IOLOCK_SHARED); return ret; @@ -383,7 +383,7 @@ xfs_file_splice_read( int ioflags = 0; ssize_t ret; - XFS_STATS_INC(xs_read_calls); + XFS_STATS_INC(ip->i_mount, xs_read_calls); if (infilp->f_mode & FMODE_NOCMTIME) ioflags |= XFS_IO_INVIS; @@ -401,7 +401,7 @@ xfs_file_splice_read( else ret = generic_file_splice_read(infilp, ppos, pipe, count, flags); if (ret > 0) - XFS_STATS_ADD(xs_read_bytes, ret); + XFS_STATS_ADD(ip->i_mount, xs_read_bytes, ret); xfs_rw_iunlock(ip, XFS_IOLOCK_SHARED); return ret; @@ -867,7 +867,7 @@ xfs_file_write_iter( ssize_t ret; size_t ocount = iov_iter_count(from); - XFS_STATS_INC(xs_write_calls); + XFS_STATS_INC(ip->i_mount, xs_write_calls); if (ocount == 0) return 0; @@ -883,7 +883,7 @@ xfs_file_write_iter( if (ret > 0) { ssize_t err; - XFS_STATS_ADD(xs_write_bytes, ret); + XFS_STATS_ADD(ip->i_mount, xs_write_bytes, ret); /* Handle various SYNC-type writes */ err = generic_write_sync(file, iocb->ki_pos - ret, ret); diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index 0a326bd..d7a490f 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -63,7 +63,7 @@ xfs_inode_alloc( return NULL; } - XFS_STATS_INC(vn_active); + XFS_STATS_INC(mp, vn_active); ASSERT(atomic_read(&ip->i_pincount) == 0); ASSERT(!spin_is_locked(&ip->i_flags_lock)); ASSERT(!xfs_isiflocked(ip)); @@ -129,7 +129,7 @@ xfs_inode_free( /* asserts to verify all state is correct here */ ASSERT(atomic_read(&ip->i_pincount) == 0); ASSERT(!xfs_isiflocked(ip)); - XFS_STATS_DEC(vn_active); + XFS_STATS_DEC(ip->i_mount, vn_active); call_rcu(&VFS_I(ip)->i_rcu, xfs_inode_free_callback); } @@ -159,7 +159,7 @@ xfs_iget_cache_hit( spin_lock(&ip->i_flags_lock); if (ip->i_ino != ino) { trace_xfs_iget_skip(ip); - XFS_STATS_INC(xs_ig_frecycle); + XFS_STATS_INC(mp, xs_ig_frecycle); error = -EAGAIN; goto out_error; } @@ -177,7 +177,7 @@ xfs_iget_cache_hit( */ if (ip->i_flags & (XFS_INEW|XFS_IRECLAIM)) { trace_xfs_iget_skip(ip); - XFS_STATS_INC(xs_ig_frecycle); + XFS_STATS_INC(mp, xs_ig_frecycle); error = -EAGAIN; goto out_error; } @@ -259,7 +259,7 @@ xfs_iget_cache_hit( xfs_ilock(ip, lock_flags); xfs_iflags_clear(ip, XFS_ISTALE | XFS_IDONTCACHE); - XFS_STATS_INC(xs_ig_found); + XFS_STATS_INC(mp, xs_ig_found); return 0; @@ -342,7 +342,7 @@ xfs_iget_cache_miss( error = radix_tree_insert(&pag->pag_ici_root, agino, ip); if (unlikely(error)) { WARN_ON(error != -EEXIST); - XFS_STATS_INC(xs_ig_dup); + XFS_STATS_INC(mp, xs_ig_dup); error = -EAGAIN; goto out_preload_end; } @@ -412,7 +412,7 @@ xfs_iget( if (!ino || XFS_INO_TO_AGNO(mp, ino) >= mp->m_sb.sb_agcount) return -EINVAL; - XFS_STATS_INC(xs_ig_attempts); + XFS_STATS_INC(mp, xs_ig_attempts); /* get the perag structure and ensure that it's inode capable */ pag = xfs_perag_get(mp, XFS_INO_TO_AGNO(mp, ino)); @@ -429,7 +429,7 @@ again: goto out_error_or_again; } else { rcu_read_unlock(); - XFS_STATS_INC(xs_ig_missed); + XFS_STATS_INC(mp, xs_ig_missed); error = xfs_iget_cache_miss(mp, pag, tp, ino, &ip, flags, lock_flags); @@ -965,7 +965,7 @@ reclaim: xfs_ifunlock(ip); xfs_iunlock(ip, XFS_ILOCK_EXCL); - XFS_STATS_INC(xs_ig_reclaims); + XFS_STATS_INC(ip->i_mount, xs_ig_reclaims); /* * Remove the inode from the per-AG radix tree. * diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index dc40a6d..a0f2bae 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -3271,8 +3271,8 @@ xfs_iflush_cluster( } if (clcount) { - XFS_STATS_INC(xs_icluster_flushcnt); - XFS_STATS_ADD(xs_icluster_flushinode, clcount); + XFS_STATS_INC(mp, xs_icluster_flushcnt); + XFS_STATS_ADD(mp, xs_icluster_flushinode, clcount); } out_free: @@ -3345,7 +3345,7 @@ xfs_iflush( struct xfs_dinode *dip; int error; - XFS_STATS_INC(xs_iflush_count); + XFS_STATS_INC(mp, xs_iflush_count); ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)); ASSERT(xfs_isiflocked(ip)); diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c index ea7d85a..b67a130 100644 --- a/fs/xfs/xfs_ioctl.c +++ b/fs/xfs/xfs_ioctl.c @@ -1028,7 +1028,7 @@ xfs_ioctl_setattr_xflags( xfs_diflags_to_linux(ip); xfs_trans_ichgtime(tp, ip, XFS_ICHGTIME_CHG); xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - XFS_STATS_INC(xs_ig_attrchg); + XFS_STATS_INC(mp, xs_ig_attrchg); return 0; } diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 1f86033..dca69c6 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -670,7 +670,7 @@ xfs_iomap_write_allocate( count_fsb = imap->br_blockcount; map_start_fsb = imap->br_startoff; - XFS_STATS_ADD(xs_xstrat_bytes, XFS_FSB_TO_B(mp, count_fsb)); + XFS_STATS_ADD(mp, xs_xstrat_bytes, XFS_FSB_TO_B(mp, count_fsb)); while (count_fsb != 0) { /* @@ -777,7 +777,7 @@ xfs_iomap_write_allocate( if ((offset_fsb >= imap->br_startoff) && (offset_fsb < (imap->br_startoff + imap->br_blockcount))) { - XFS_STATS_INC(xs_xstrat_quick); + XFS_STATS_INC(mp, xs_xstrat_quick); return 0; } diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c index 8294132..245268a 100644 --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -695,7 +695,7 @@ xfs_setattr_nonsize( xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - XFS_STATS_INC(xs_ig_attrchg); + XFS_STATS_INC(mp, xs_ig_attrchg); if (mp->m_flags & XFS_MOUNT_WSYNC) xfs_trans_set_sync(tp); @@ -922,7 +922,7 @@ xfs_setattr_size( xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - XFS_STATS_INC(xs_ig_attrchg); + XFS_STATS_INC(mp, xs_ig_attrchg); if (mp->m_flags & XFS_MOUNT_WSYNC) xfs_trans_set_sync(tp); diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index aaadee0..4012523 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -268,7 +268,7 @@ xlog_grant_head_wait( __set_current_state(TASK_UNINTERRUPTIBLE); spin_unlock(&head->lock); - XFS_STATS_INC(xs_sleep_logspace); + XFS_STATS_INC(log->l_mp, xs_sleep_logspace); trace_xfs_log_grant_sleep(log, tic); schedule(); @@ -379,7 +379,7 @@ xfs_log_regrant( if (XLOG_FORCED_SHUTDOWN(log)) return -EIO; - XFS_STATS_INC(xs_try_logspace); + XFS_STATS_INC(mp, xs_try_logspace); /* * This is a new transaction on the ticket, so we need to change the @@ -448,7 +448,7 @@ xfs_log_reserve( if (XLOG_FORCED_SHUTDOWN(log)) return -EIO; - XFS_STATS_INC(xs_try_logspace); + XFS_STATS_INC(mp, xs_try_logspace); ASSERT(*ticp == NULL); tic = xlog_ticket_alloc(log, unit_bytes, cnt, client, permanent, @@ -1768,7 +1768,7 @@ xlog_sync( int v2 = xfs_sb_version_haslogv2(&log->l_mp->m_sb); int size; - XFS_STATS_INC(xs_log_writes); + XFS_STATS_INC(log->l_mp, xs_log_writes); ASSERT(atomic_read(&iclog->ic_refcnt) == 0); /* Add for LR header */ @@ -1805,7 +1805,7 @@ xlog_sync( bp = iclog->ic_bp; XFS_BUF_SET_ADDR(bp, BLOCK_LSN(be64_to_cpu(iclog->ic_header.h_lsn))); - XFS_STATS_ADD(xs_log_blocks, BTOBB(count)); + XFS_STATS_ADD(log->l_mp, xs_log_blocks, BTOBB(count)); /* Do we need to split this write into 2 parts? */ if (XFS_BUF_ADDR(bp) + BTOBB(count) > log->l_logBBsize) { @@ -2913,7 +2913,7 @@ restart: iclog = log->l_iclog; if (iclog->ic_state != XLOG_STATE_ACTIVE) { - XFS_STATS_INC(xs_log_noiclogs); + XFS_STATS_INC(log->l_mp, xs_log_noiclogs); /* Wait for log writes to have flushed */ xlog_wait(&log->l_flush_wait, &log->l_icloglock); @@ -3212,7 +3212,7 @@ _xfs_log_force( struct xlog_in_core *iclog; xfs_lsn_t lsn; - XFS_STATS_INC(xs_log_force); + XFS_STATS_INC(mp, xs_log_force); xlog_cil_force(log); @@ -3297,7 +3297,7 @@ maybe_sleep: spin_unlock(&log->l_icloglock); return -EIO; } - XFS_STATS_INC(xs_log_force_sleep); + XFS_STATS_INC(mp, xs_log_force_sleep); xlog_wait(&iclog->ic_force_wait, &log->l_icloglock); /* * No need to grab the log lock here since we're @@ -3362,7 +3362,7 @@ _xfs_log_force_lsn( ASSERT(lsn != 0); - XFS_STATS_INC(xs_log_force); + XFS_STATS_INC(mp, xs_log_force); lsn = xlog_cil_force_lsn(log, lsn); if (lsn == NULLCOMMITLSN) @@ -3411,7 +3411,7 @@ try_again: (XLOG_STATE_WANT_SYNC | XLOG_STATE_SYNCING))) { ASSERT(!(iclog->ic_state & XLOG_STATE_IOERROR)); - XFS_STATS_INC(xs_log_force_sleep); + XFS_STATS_INC(mp, xs_log_force_sleep); xlog_wait(&iclog->ic_prev->ic_write_wait, &log->l_icloglock); @@ -3441,7 +3441,7 @@ try_again: spin_unlock(&log->l_icloglock); return -EIO; } - XFS_STATS_INC(xs_log_force_sleep); + XFS_STATS_INC(mp, xs_log_force_sleep); xlog_wait(&iclog->ic_force_wait, &log->l_icloglock); /* * No need to grab the log lock here since we're diff --git a/fs/xfs/xfs_qm.c b/fs/xfs/xfs_qm.c index eac9549..7af7648 100644 --- a/fs/xfs/xfs_qm.c +++ b/fs/xfs/xfs_qm.c @@ -184,7 +184,7 @@ xfs_qm_dqpurge( */ ASSERT(!list_empty(&dqp->q_lru)); list_lru_del(&qi->qi_lru, &dqp->q_lru); - XFS_STATS_DEC(xs_qm_dquot_unused); + XFS_STATS_DEC(mp, xs_qm_dquot_unused); xfs_qm_dqdestroy(dqp); return 0; @@ -448,11 +448,11 @@ xfs_qm_dquot_isolate( */ if (dqp->q_nrefs) { xfs_dqunlock(dqp); - XFS_STATS_INC(xs_qm_dqwants); + XFS_STATS_INC(dqp->q_mount, xs_qm_dqwants); trace_xfs_dqreclaim_want(dqp); list_lru_isolate(lru, &dqp->q_lru); - XFS_STATS_DEC(xs_qm_dquot_unused); + XFS_STATS_DEC(dqp->q_mount, xs_qm_dquot_unused); return LRU_REMOVED; } @@ -496,19 +496,19 @@ xfs_qm_dquot_isolate( ASSERT(dqp->q_nrefs == 0); list_lru_isolate_move(lru, &dqp->q_lru, &isol->dispose); - XFS_STATS_DEC(xs_qm_dquot_unused); + XFS_STATS_DEC(dqp->q_mount, xs_qm_dquot_unused); trace_xfs_dqreclaim_done(dqp); - XFS_STATS_INC(xs_qm_dqreclaims); + XFS_STATS_INC(dqp->q_mount, xs_qm_dqreclaims); return LRU_REMOVED; out_miss_busy: trace_xfs_dqreclaim_busy(dqp); - XFS_STATS_INC(xs_qm_dqreclaim_misses); + XFS_STATS_INC(dqp->q_mount, xs_qm_dqreclaim_misses); return LRU_SKIP; out_unlock_dirty: trace_xfs_dqreclaim_busy(dqp); - XFS_STATS_INC(xs_qm_dqreclaim_misses); + XFS_STATS_INC(dqp->q_mount, xs_qm_dqreclaim_misses); xfs_dqunlock(dqp); spin_lock(lru_lock); return LRU_RETRY; diff --git a/fs/xfs/xfs_stats.h b/fs/xfs/xfs_stats.h index 211e36f..2ab82c5 100644 --- a/fs/xfs/xfs_stats.h +++ b/fs/xfs/xfs_stats.h @@ -218,14 +218,23 @@ int xfs_stats_format(struct xfsstats __percpu *stats, char *buf); void xfs_stats_clearall(struct xfsstats __percpu *stats); extern struct xstats xfsstats; -#define XFS_STATS_INC(v) \ - per_cpu_ptr(xfsstats.xs_stats, current_cpu())->v++; +#define XFS_STATS_INC(mp, v) \ +do { \ + per_cpu_ptr(xfsstats.xs_stats, current_cpu())->v++; \ + per_cpu_ptr(mp->m_stats.xs_stats, current_cpu())->v++; \ +} while (0) -#define XFS_STATS_DEC(v) \ - per_cpu_ptr(xfsstats.xs_stats, current_cpu())->v--; +#define XFS_STATS_DEC(mp, v) \ +do { \ + per_cpu_ptr(xfsstats.xs_stats, current_cpu())->v--; \ + per_cpu_ptr(mp->m_stats.xs_stats, current_cpu())->v--; \ +} while (0) -#define XFS_STATS_ADD(v, inc) \ - per_cpu_ptr(xfsstats.xs_stats, current_cpu())->v += (inc); +#define XFS_STATS_ADD(mp, v, inc) \ +do { \ + per_cpu_ptr(xfsstats.xs_stats, current_cpu())->v += (inc); \ + per_cpu_ptr(mp->m_stats.xs_stats, current_cpu())->v += (inc); \ +} while (0) extern int xfs_init_procfs(void); extern void xfs_cleanup_procfs(void); diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 68d4976..6c3cdd8 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -922,7 +922,7 @@ xfs_fs_destroy_inode( trace_xfs_destroy_inode(ip); - XFS_STATS_INC(vn_reclaim); + XFS_STATS_INC(ip->i_mount, vn_reclaim); ASSERT(XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0); @@ -983,8 +983,8 @@ xfs_fs_evict_inode( truncate_inode_pages_final(&inode->i_data); clear_inode(inode); - XFS_STATS_INC(vn_rele); - XFS_STATS_INC(vn_remove); + XFS_STATS_INC(ip->i_mount, vn_rele); + XFS_STATS_INC(ip->i_mount, vn_remove); xfs_inactive(ip); } diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c index a0ab1da..748b16a 100644 --- a/fs/xfs/xfs_trans.c +++ b/fs/xfs/xfs_trans.c @@ -930,9 +930,9 @@ __xfs_trans_commit( */ if (sync) { error = _xfs_log_force_lsn(mp, commit_lsn, XFS_LOG_SYNC, NULL); - XFS_STATS_INC(xs_trans_sync); + XFS_STATS_INC(mp, xs_trans_sync); } else { - XFS_STATS_INC(xs_trans_async); + XFS_STATS_INC(mp, xs_trans_async); } return error; @@ -955,7 +955,7 @@ out_unreserve: xfs_trans_free_items(tp, NULLCOMMITLSN, !!error); xfs_trans_free(tp); - XFS_STATS_INC(xs_trans_empty); + XFS_STATS_INC(mp, xs_trans_empty); return error; } diff --git a/fs/xfs/xfs_trans_ail.c b/fs/xfs/xfs_trans_ail.c index 1098cf4..4f18fd9 100644 --- a/fs/xfs/xfs_trans_ail.c +++ b/fs/xfs/xfs_trans_ail.c @@ -349,7 +349,7 @@ xfsaild_push( xfs_ail_min_lsn(ailp))) { ailp->xa_log_flush = 0; - XFS_STATS_INC(xs_push_ail_flush); + XFS_STATS_INC(mp, xs_push_ail_flush); xfs_log_force(mp, XFS_LOG_SYNC); } @@ -371,7 +371,7 @@ xfsaild_push( goto out_done; } - XFS_STATS_INC(xs_push_ail); + XFS_STATS_INC(mp, xs_push_ail); lsn = lip->li_lsn; while ((XFS_LSN_CMP(lip->li_lsn, target) <= 0)) { @@ -385,7 +385,7 @@ xfsaild_push( lock_result = lip->li_ops->iop_push(lip, &ailp->xa_buf_list); switch (lock_result) { case XFS_ITEM_SUCCESS: - XFS_STATS_INC(xs_push_ail_success); + XFS_STATS_INC(mp, xs_push_ail_success); trace_xfs_ail_push(lip); ailp->xa_last_pushed_lsn = lsn; @@ -403,7 +403,7 @@ xfsaild_push( * re-try the flushing relatively soon if most of the * AIL is beeing flushed. */ - XFS_STATS_INC(xs_push_ail_flushing); + XFS_STATS_INC(mp, xs_push_ail_flushing); trace_xfs_ail_flushing(lip); flushing++; @@ -411,14 +411,14 @@ xfsaild_push( break; case XFS_ITEM_PINNED: - XFS_STATS_INC(xs_push_ail_pinned); + XFS_STATS_INC(mp, xs_push_ail_pinned); trace_xfs_ail_pinned(lip); stuck++; ailp->xa_log_flush++; break; case XFS_ITEM_LOCKED: - XFS_STATS_INC(xs_push_ail_locked); + XFS_STATS_INC(mp, xs_push_ail_locked); trace_xfs_ail_locked(lip); stuck++; -- 2.4.3 From ambt@cgwa.com Mon Sep 28 17:09:46 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.2 required=5.0 tests=DEAR_SOMETHING,FREEMAIL_FROM, HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id ECA2F7F37 for ; Mon, 28 Sep 2015 17:09:46 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id D04D88F8035 for ; Mon, 28 Sep 2015 15:09:43 -0700 (PDT) X-ASG-Debug-ID: 1443478180-04cb6c6b04133a10001-NocioJ Received: from cgwa.com ([114.97.99.13]) by cuda.sgi.com with ESMTP id pFKxNlXjM7HF6ysZ for ; Mon, 28 Sep 2015 15:09:41 -0700 (PDT) X-Barracuda-Envelope-From: ambt@cgwa.com X-Barracuda-Apparent-Source-IP: 114.97.99.13 Received: from SKY-20150201SFT ([127.0.0.1]) by localhost via TCP with ESMTPA; Tue, 29 Sep 2015 06:09:27 +0800 MIME-Version: 1.0 From: Amos Sender: Amos To: xfs@oss.sgi.com Reply-To: Amos Date: 29 Sep 2015 06:09:27 +0800 Subject: =?utf-8?B?aGFyZHdhcmUgcHJvZHVjdHM=?= Content-Type: text/html; charset=utf-8 X-ASG-Orig-Subj: =?utf-8?B?aGFyZHdhcmUgcHJvZHVjdHM=?= Content-Transfer-Encoding: base64 X-Barracuda-Connect: UNKNOWN[114.97.99.13] X-Barracuda-Start-Time: 1443478181 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.74 X-Barracuda-Spam-Status: No, SCORE=0.74 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC5_MJ1963, HTML_MESSAGE, MIME_HTML_ONLY, MISSING_MID, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22992 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 MISSING_MID Missing Message-Id: header 0.00 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 Message-Id: <20150928220943.7D97F129608E@cuda.sgi.com> PGh0bWw+PGJvZHk+PFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05v cm1hbD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJp Zic7IEJBQ0tHUk9VTkQ6IHdoaXRlOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMThwdCIg bGFuZz1FTi1VUz48Rk9OVCBzaXplPTM+RGVhciBTaXIsPC9GT05UPjwvU1BBTj48U1BBTiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBi bGFjazsgRk9OVC1TSVpFOiAxOHB0IiBsYW5nPUVOLVVTPjxCUj48QlI+PEZPTlQgc2l6ZT0z PjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5EOiB3aGl0ZSI+SSBhbSBkZWxpZ2h0ZWQgdG8ga25v dyB5b3UuPC9TUEFOPjxCUj48QlI+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQ6IHdoaXRlIj5J IGtub3cgZnJvbSB1cyBpbXBvcnRlcnMgdXMgdGhhdCB5b3UgaGF2ZSBlbnF1aXJlZCBhYm91 dCBoYXJkd2FyZSBwcm9kdWN0cyxPdXIgY29tcGFueSBpcyBoYXJkd2FyZSBPRU0gTWFudWZh Y3R1cmVyLCBPdXIgZXhwb3J0aW5nIEhhcmR3YXJlIGZpdHRpbmcgaW5jbHVkaW5nIENOQyB0 dXJuaW5nIGFuZCBtaWxsaW5nIHByb2R1Y3RzLCBzdGFtcGluZyBwYXJ0cywgZmFzdGVuZXJz LCB6aW5jIGFuZCBhbHVtaW51bSBkaWUgY2FzdGluZywgcHVuY2hlZCBwYXJ0cyBlY3QuIElu IGZhY3QsIEp1c3Qgb25seSB5b3UgaGF2ZSBkcmF3aW5nIHdpdGggcHJvZHVjdHMsIHdlIGNh biBkby48L1NQQU4+PEJSPjxCUj48U1BBTiBzdHlsZT0iQkFDS0dST1VORDogd2hpdGUiPkkg d291bGQgYXBwcmVjaWF0ZSB5b3VyIGVhcmx5IHJlcGx5IGluIGFkdmFuY2UuPC9TUEFOPjxC Uj48QlI+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQ6IHdoaXRlIj5CZXN0IFJlZ2FyZHMsPC9T UEFOPjxCUj48QlI+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQ6IHdoaXRlIj5YaW5kYSBIYXJk d2FyZSBNYW51ZmFjdHVyZSBDby4sIExpbWl0ZWQ8L1NQQU4+PEJSPjxTUEFOIHN0eWxlPSJC QUNLR1JPVU5EOiB3aGl0ZSI+Q0VPOiBBbW9zPC9TUEFOPjwvRk9OVD48L1NQQU4+PC9QPjwv Ym9keT48L2h0bWw+ From darrick.wong@oracle.com Mon Sep 28 17:38:08 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 45ABB7F37 for ; Mon, 28 Sep 2015 17:38:08 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 38CD1304053 for ; Mon, 28 Sep 2015 15:38:05 -0700 (PDT) X-ASG-Debug-ID: 1443479883-04cbb033b3152da0001-NocioJ Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by cuda.sgi.com with ESMTP id ojS25SlE9fQhF8aU (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 15:38:03 -0700 (PDT) X-Barracuda-Envelope-From: darrick.wong@oracle.com X-Barracuda-Apparent-Source-IP: 141.146.126.69 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8SMc2BE018957 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Sep 2015 22:38:02 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8SMc2S8024739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Sep 2015 22:38:02 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8SMc21s002729; Mon, 28 Sep 2015 22:38:02 GMT Received: from localhost (/24.21.154.84) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Sep 2015 15:38:02 -0700 Date: Mon, 28 Sep 2015 15:38:01 -0700 From: "Darrick J. Wong" To: david@fromorbit.com Cc: fstests@vger.kernel.org, xfs@oss.sgi.com Subject: [PATCH] xfs: fix merge errors in fuzzer tests Message-ID: <20150928223801.GH10391@birch.djwong.org> X-ASG-Orig-Subj: [PATCH] xfs: fix merge errors in fuzzer tests MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Barracuda-Connect: aserp1040.oracle.com[141.146.126.69] X-Barracuda-Start-Time: 1443479883 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.22993 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines Fix some merge errors when the fuzzer tests went in. Signed-off-by: Darrick J. Wong --- tests/xfs/085.out | 2 -- tests/xfs/098.out | 1 - tests/xfs/099.out | 2 +- tests/xfs/100.out | 2 +- tests/xfs/101.out | 2 +- tests/xfs/102.out | 2 +- 6 files changed, 4 insertions(+), 7 deletions(-) diff --git a/tests/xfs/085.out b/tests/xfs/085.out index 6303081..ff3dccd 100644 --- a/tests/xfs/085.out +++ b/tests/xfs/085.out @@ -5,8 +5,6 @@ QA output created by 085 + check fs + corrupt image + mount image -+ modify files -broken: 1 + repair fs + mount image (2) + chattr -R -i diff --git a/tests/xfs/098.out b/tests/xfs/098.out index 84a2b4d..ef0554d 100644 --- a/tests/xfs/098.out +++ b/tests/xfs/098.out @@ -5,7 +5,6 @@ QA output created by 098 + check fs + corrupt image + mount image -broken: 1 + repair fs + mount image (2) + chattr -R -i diff --git a/tests/xfs/099.out b/tests/xfs/099.out index 4426859..773200b 100644 --- a/tests/xfs/099.out +++ b/tests/xfs/099.out @@ -1,4 +1,4 @@ -QA output created by 016 +QA output created by 099 + create scratch fs + mount fs image + make some files diff --git a/tests/xfs/100.out b/tests/xfs/100.out index 98d8dbc..97dba7c 100644 --- a/tests/xfs/100.out +++ b/tests/xfs/100.out @@ -1,4 +1,4 @@ -QA output created by 017 +QA output created by 100 + create scratch fs + mount fs image + make some files diff --git a/tests/xfs/101.out b/tests/xfs/101.out index 49430f7..22ca620 100644 --- a/tests/xfs/101.out +++ b/tests/xfs/101.out @@ -1,4 +1,4 @@ -QA output created by 018 +QA output created by 101 + create scratch fs + mount fs image + make some files diff --git a/tests/xfs/102.out b/tests/xfs/102.out index 58f493c..d8a8fa1 100644 --- a/tests/xfs/102.out +++ b/tests/xfs/102.out @@ -1,4 +1,4 @@ -QA output created by 019 +QA output created by 102 + create scratch fs + mount fs image + make some files From billodo@redhat.com Tue Sep 29 07:43:50 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 653A17F37 for ; Tue, 29 Sep 2015 07:43:50 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 50EF330405F for ; Tue, 29 Sep 2015 05:43:50 -0700 (PDT) X-ASG-Debug-ID: 1443530628-04cbb033b016e460001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id g1tNM0J6r4HE7u7v (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 29 Sep 2015 05:43:49 -0700 (PDT) X-Barracuda-Envelope-From: billodo@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 7848EC0A15E3 for ; Tue, 29 Sep 2015 12:43:48 +0000 (UTC) Received: from localhost.localdomain.com (vpn-60-201.rdu2.redhat.com [10.10.60.201]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8TChlfS020018 for ; Tue, 29 Sep 2015 08:43:48 -0400 From: "Bill O'Donnell" To: xfs@oss.sgi.com Subject: [PATCH 6/7] xfs: per-filesystem stats in sysfs. Date: Tue, 29 Sep 2015 07:43:47 -0500 X-ASG-Orig-Subj: [PATCH 6/7] xfs: per-filesystem stats in sysfs. Message-Id: <1443530627-22339-1-git-send-email-billodo@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443530629 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 This patch implements per-filesystem stats objects in sysfs. It depends on the application of the previous patch series that develops the infrastructure to support both xfs global stats and xfs per-fs stats in sysfs. Stats objects are instantiated when an xfs filesystem is mounted and deleted on unmount. With this patch, the stats directory is created and populated with the familiar stats and stats_clear files. Example: /sys/fs/xfs/sda9/stats/stats /sys/fs/xfs/sda9/stats/stats_clear With this patch, the individual counts within the new per-fs stats file(s) remain at zero. Functions that use the the macros to increment, decrement, and add-to the per-fs stats counts will be covered in a separate new patch to follow this one. Note that the counts within the global stats file (/sys/fs/xfs/stats/stats) advance normally and can be cleared as it was prior to this patch. Signed-off-by: Bill O'Donnell --- fs/xfs/xfs_mount.c | 24 +++++++++++++++++++++++- fs/xfs/xfs_mount.h | 1 + fs/xfs/xfs_super.c | 12 ++++-------- 3 files changed, 28 insertions(+), 9 deletions(-) diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index bf92e0c..89ac1bd 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -693,9 +693,23 @@ xfs_mountfs( if (error) goto out; + /* + * Allocate stats memory and create stats sysfs object. + */ + mp->m_stats.xs_stats = alloc_percpu(struct xfsstats); + if (!mp->m_stats.xs_stats) { + error = PTR_ERR(mp->m_stats.xs_stats); + goto out_remove_sysfs; + } + error = xfs_sysfs_init(&mp->m_stats.xs_kobj, &xfs_stats_ktype, + &mp->m_kobj, + "stats"); + if (error) + goto out_free_stats; + error = xfs_uuid_mount(mp); if (error) - goto out_remove_sysfs; + goto out_del_stats; /* * Set the minimum read and write sizes @@ -971,6 +985,10 @@ xfs_mountfs( xfs_da_unmount(mp); out_remove_uuid: xfs_uuid_unmount(mp); + out_del_stats: + xfs_sysfs_del(&mp->m_stats.xs_kobj); + out_free_stats: + free_percpu(mp->m_stats.xs_stats); out_remove_sysfs: xfs_sysfs_del(&mp->m_kobj); out: @@ -1047,6 +1065,10 @@ xfs_unmountfs( xfs_warn(mp, "Unable to update superblock counters. " "Freespace may not be correct on next mount."); + /* remove the stats kobject and free stats memory */ + xfs_sysfs_del(&mp->m_stats.xs_kobj); + free_percpu(mp->m_stats.xs_stats); + xfs_log_unmount(mp); xfs_da_unmount(mp); xfs_uuid_unmount(mp); diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 7999e91..8795272 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -127,6 +127,7 @@ typedef struct xfs_mount { int64_t m_low_space[XFS_LOWSP_MAX]; /* low free space thresholds */ struct xfs_kobj m_kobj; + struct xstats m_stats; /* per-fs stats */ struct workqueue_struct *m_buf_workqueue; struct workqueue_struct *m_data_workqueue; diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 5901336..68d4976 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1841,18 +1841,14 @@ init_xfs_fs(void) goto out_sysctl_unregister; } + xfsstats.xs_kobj.kobject.kset = xfs_kset; + xfsstats.xs_stats = alloc_percpu(struct xfsstats); if (!xfsstats.xs_stats) { error = -ENOMEM; goto out_kset_unregister; } - xfsstats.xs_kobj.kobject.kset = xfs_kset; - if (!xfsstats.xs_kobj.kobject.kset) { - error = -ENOMEM; - goto out_free_stats; - } - error = xfs_sysfs_init(&xfsstats.xs_kobj, &xfs_stats_ktype, NULL, "stats"); if (error) @@ -1862,7 +1858,7 @@ init_xfs_fs(void) xfs_dbg_kobj.kobject.kset = xfs_kset; error = xfs_sysfs_init(&xfs_dbg_kobj, &xfs_dbg_ktype, NULL, "debug"); if (error) - goto out_del_stats; + goto out_remove_stats_obj; #endif error = xfs_qm_init(); @@ -1879,7 +1875,7 @@ init_xfs_fs(void) out_remove_dbg_kobj: #ifdef DEBUG xfs_sysfs_del(&xfs_dbg_kobj); - out_del_stats: + out_remove_stats_obj: #endif xfs_sysfs_del(&xfsstats.xs_kobj); out_free_stats: -- 2.4.3 From angelo.dureghello@nomovok.com Tue Sep 29 08:33:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 650637F37 for ; Tue, 29 Sep 2015 08:33:05 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 450168F8040 for ; Tue, 29 Sep 2015 06:33:02 -0700 (PDT) X-ASG-Debug-ID: 1443533577-04bdf04626156070001-NocioJ Received: from mail.nomovok.com (mail.nomovok.com [83.150.122.238]) by cuda.sgi.com with ESMTP id TSYwy7j8EqDNDtNc (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Sep 2015 06:32:59 -0700 (PDT) X-Barracuda-Envelope-From: angelo.dureghello@nomovok.com X-Barracuda-Apparent-Source-IP: 83.150.122.238 Received: from [192.168.0.2] (unknown [95.233.233.211]) by mail.nomovok.com (Postfix) with ESMTPSA id F390BAE049 for ; Tue, 29 Sep 2015 16:32:56 +0300 (EEST) Message-ID: <560A9307.6080600@nomovok.com> Date: Tue, 29 Sep 2015 15:32:55 +0200 From: Angelo Dureghello User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: xfstests, xfs test 080 fails on arm 32bit Content-Type: text/plain; charset=utf-8; format=flowed X-ASG-Orig-Subj: xfstests, xfs test 080 fails on arm 32bit Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail.nomovok.com[83.150.122.238] X-Barracuda-Start-Time: 1443533578 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.23010 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Hi, executing this test on a 32bit arm. i get (i traced mmapping sizes): # ./start_xfs_test.sh QA output created by 080 [ 161.827446] XFS (mmcblk0p5): Mounting V4 Filesystem [ 162.357952] XFS (mmcblk0p5): Ending clean mount mmapping 512000000 mmapping 512000000 mmapping 512000000 mmapping 512000000 mmapping 512000000 mmapping 512000000 oio ( 3241) 15:18:17 --------------------- mmap() failed - 0xffffffff 12 doio ( 3241) 15:18:17 --------------------- mmap-read() request failed: Cannot allocate memory (12) Request number 15 fd 4 is file /media/p5/rwtest.file - open flags are 0 O_RDONLY, read done at file offset 978498 number of requests is 1, strides per request is 1 i/o byte count = 119505 memory alignment is unaligned syscall: mmap-read(NULL, 512000000, PROT_READ, MAP_SHARED, 4, 0) file is mmaped to: 0x0 file-mem=0xeee42, length=119505, buffer=0x484a6 doio ( 3241) 15:18:17 --------------------- doio(): operation 120 returned != 0 rwtest.sh : iogen reported errors (r=141) Is it possible the test was thought to pass on 64bit systems ? Best regards Angelo Dureghello -- Best regards, Angelo Dureghello From jtulak@redhat.com Tue Sep 29 11:04:26 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id D63CD7F37 for ; Tue, 29 Sep 2015 11:04:26 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id B4FE58F804C for ; Tue, 29 Sep 2015 09:04:23 -0700 (PDT) X-ASG-Debug-ID: 1443542657-04cbb033b0175d80001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 2bIRiFlOdCzYxUCK (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 29 Sep 2015 09:04:18 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id A537BB4C42; Tue, 29 Sep 2015 16:04:17 +0000 (UTC) Received: from jtulak-t430.brq.redhat.com (jtulak.brq.redhat.com [10.34.26.85]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8TG4FvM022119; Tue, 29 Sep 2015 12:04:16 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: david@fromorbit.com, Jan Tulak Subject: [PATCH 12/14 v2] xfsprogs: make fsr use mntinfo when there is no mntent Date: Tue, 29 Sep 2015 18:04:13 +0200 X-ASG-Orig-Subj: [PATCH 12/14 v2] xfsprogs: make fsr use mntinfo when there is no mntent Message-Id: <1443542653-10525-1-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-13-git-send-email-jtulak@redhat.com> References: <1442311164-12921-13-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443542658 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 UPDATE: - refactor ifdefs to platform_ functions For what fsr needs, mntinfo can be used instead of mntent on some platforms. Exctract the platform-specific code to platform headers. Signed-off-by: Jan Tulak --- fsr/Makefile | 8 ++++ fsr/xfs_fsr.c | 127 +++++++++++++++++++++++++++++++------------------- include/darwin.h | 64 +++++++++++++++++++++++++ include/freebsd.h | 32 +++++++++++++ include/gnukfreebsd.h | 31 ++++++++++++ include/irix.h | 32 +++++++++++++ include/linux.h | 31 ++++++++++++ 7 files changed, 276 insertions(+), 49 deletions(-) diff --git a/fsr/Makefile b/fsr/Makefile index a9d1bf6..d3521b2 100644 --- a/fsr/Makefile +++ b/fsr/Makefile @@ -9,6 +9,14 @@ LTCOMMAND = xfs_fsr CFILES = xfs_fsr.c LLDLIBS = $(LIBHANDLE) +ifeq ($(HAVE_GETMNTENT),yes) +LCFLAGS += -DHAVE_GETMNTENT +endif + +ifeq ($(HAVE_GETMNTINFO),yes) +LCFLAGS += -DHAVE_GETMNTINFO +endif + default: depend $(LTCOMMAND) include $(BUILDRULES) diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c index c8ef18f..d7087d4 100644 --- a/fsr/xfs_fsr.c +++ b/fsr/xfs_fsr.c @@ -32,10 +32,6 @@ #include #include -#ifdef HAVE_MNTENT -# include -#endif - #ifndef XFS_XFLAG_NODEFRAG #define XFS_XFLAG_NODEFRAG 0x00002000 /* src dependancy, remove later */ #endif @@ -174,60 +170,69 @@ aborter(int unused) exit(1); } + + /* * Check if the argument is either the device name or mountpoint of an XFS * filesystem. Note that we do not care about bind mounted regular files * here - the code that handles defragmentation of invidual files takes care * of that. */ + static char * -find_mountpoint(char *mtab, char *argname, struct stat64 *sb) +find_mountpoint_check(struct stat64 *sb, struct mntent *t, struct stat64 ms) { - struct mntent *t; - struct stat64 ms; - FILE *mtabp; - char *mntp = NULL; + if (S_ISDIR(sb->st_mode)) { /* mount point */ + if (stat64(t->mnt_dir, &ms) < 0) + return NULL; + if (sb->st_ino != ms.st_ino) + return NULL; + if (sb->st_dev != ms.st_dev) + return NULL; + if (strcmp(t->mnt_type, MNTTYPE_XFS) != 0) + return NULL; + } else { /* device */ + struct stat64 sb2; + + if (stat64(t->mnt_fsname, &ms) < 0) + return NULL; + if (sb->st_rdev != ms.st_rdev) + return NULL; + if (strcmp(t->mnt_type, MNTTYPE_XFS) != 0) + return NULL; - mtabp = setmntent(mtab, "r"); - if (!mtabp) { - fprintf(stderr, _("%s: cannot read %s\n"), - progname, mtab); - exit(1); + /* + * Make sure the mountpoint given by mtab is accessible + * before using it. + */ + if (stat64(t->mnt_dir, &sb2) < 0) + return NULL; } - while ((t = getmntent(mtabp))) { - if (S_ISDIR(sb->st_mode)) { /* mount point */ - if (stat64(t->mnt_dir, &ms) < 0) - continue; - if (sb->st_ino != ms.st_ino) - continue; - if (sb->st_dev != ms.st_dev) - continue; - if (strcmp(t->mnt_type, MNTTYPE_XFS) != 0) - continue; - } else { /* device */ - struct stat64 sb2; + return t->mnt_dir; - if (stat64(t->mnt_fsname, &ms) < 0) - continue; - if (sb->st_rdev != ms.st_rdev) - continue; - if (strcmp(t->mnt_type, MNTTYPE_XFS) != 0) - continue; +} - /* - * Make sure the mountpoint given by mtab is accessible - * before using it. - */ - if (stat64(t->mnt_dir, &sb2) < 0) - continue; - } +static char * +find_mountpoint(char *mtab, char *argname, struct stat64 *sb) +{ + struct mntent_cursor cursor; + struct stat64 ms; + struct mntent t = {}; + char *mntp = NULL; - mntp = t->mnt_dir; + if (platform_mntent_open(&cursor, mtab) != 0){ + fprintf(stderr, "Error: can't get mntent entries.\n"); + exit(1); + } + + while (platform_mntent_next(&cursor, &t) == 0) { + mntp = find_mountpoint_check(sb, &t, ms); + if (mntp == NULL) + continue; break; } - - endmntent(mtabp); + platform_mntent_close(&cursor); return mntp; } @@ -405,18 +410,11 @@ usage(int ret) static void initallfs(char *mtab) { - FILE *fp; struct mntent *mp; int mi; char *cp; struct stat64 sb; - fp = setmntent(mtab, "r"); - if (fp == NULL) { - fsrprintf(_("could not open mtab file: %s\n"), mtab); - exit(1); - } - /* malloc a number of descriptors, increased later if needed */ if (!(fsbase = (fsdesc_t *)malloc(fsbufsize * sizeof(fsdesc_t)))) { fsrprintf(_("out of memory: %s\n"), strerror(errno)); @@ -427,7 +425,36 @@ initallfs(char *mtab) /* find all rw xfs file systems */ mi = 0; fs = fsbase; + +#if defined(HAVE_GETMNTENT) + FILE *fp; + fp = setmntent(mtab, "r"); + if (fp == NULL) { + fsrprintf(_("could not open mtab file: %s\n"), mtab); + exit(1); + } + while ((mp = getmntent(fp))) { +#elif defined(HAVE_GETMNTINFO) + struct statfs *stats; + int error, i, count; + // because "t" is a pointer, but we don't need to use + // malloc for this usage + struct mntent mp_tmp; + mp = &mp_tmp; + error = 0; + if ((count = getmntinfo(&stats, 0)) < 0) { + fprintf(stderr, _("%s: getmntinfo() failed: %s\n"), + progname, strerror(errno)); + exit(1); + } + + for (i = 0; i < count; i++) { + mntinfo2mntent(&stats[i], mp); +#else +# error "How do I extract info about mounted filesystems on this platform?" +#endif + int rw = 0; if (strcmp(mp->mnt_type, MNTTYPE_XFS ) != 0 || @@ -479,7 +506,9 @@ initallfs(char *mtab) } numfs = mi; fsend = (fsbase + numfs); +#if defined(HAVE_GETMNTENT) endmntent(fp); +#endif if (numfs == 0) { fsrprintf(_("no rw xfs file systems in mtab: %s\n"), mtab); exit(0); diff --git a/include/darwin.h b/include/darwin.h index 288ad1f..fd9384d 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -33,6 +33,8 @@ #include #include #include +#include +#include #include #define __BYTE_ORDER BYTE_ORDER @@ -218,7 +220,69 @@ static inline int timer_gettime (timer_t timerid, struct itimerspec *value) /* FSR */ +# include +# include +#include +#include #define statvfs64 statfs #define _PATH_MOUNTED "/etc/mtab" +struct mntent +{ + char *mnt_fsname; + char *mnt_dir; + char *mnt_type; + char *mnt_opts; + int mnt_freq; + int mnt_passno; +}; + +static inline void mntinfo2mntent (struct statfs * stats, struct mntent * mnt) { + mnt->mnt_fsname = stats->f_mntfromname; + mnt->mnt_dir = stats->f_mntonname; + mnt->mnt_type = stats->f_fstypename; +} + + + +/** + * Abstraction of mountpoints. + */ +struct mntent_cursor { + FILE *mtabp; + struct statfs *stats; + int count; + int i; +}; + +/** + * OS X uses getmntinfo, which doesn't use a mtab file. So we just ignore it. + */ +static inline int platform_mntent_open(struct mntent_cursor * cursor, char *mtab) +{ + if ((cursor->count = getmntinfo(&cursor->stats, 0)) < 0) { + fprintf(stderr, "Error: getmntinfo() failed: %s\n", strerror(errno)); + return 1; + } + cursor->i = 0; + return 0; +} + +static inline int platform_mntent_next(struct mntent_cursor * cursor, struct mntent * t) +{ + if (cursor->i >= cursor->count){ + return 1; + } + mntinfo2mntent(&cursor->stats[cursor->i], t); + cursor->i++; + return 0; + +} + +static inline void platform_mntent_close(struct mntent_cursor * cursor) +{ + cursor->count = 0; + cursor->i = 0; +} + #endif /* __XFS_DARWIN_H__ */ diff --git a/include/freebsd.h b/include/freebsd.h index 902b940..6bc9e61 100644 --- a/include/freebsd.h +++ b/include/freebsd.h @@ -26,6 +26,7 @@ #include #include #include +#include #include #define __BYTE_ORDER BYTE_ORDER @@ -147,4 +148,35 @@ platform_discard_blocks(int fd, uint64_t start, uint64_t len) return 0; } +/** + * Abstraction of mountpoints. + */ +struct mntent_cursor { + FILE *mtabp; +}; + +static inline int platform_mntent_open(struct mntent_cursor * cursor, char *mtab) +{ + cursor->mtabp = setmntent(mtab, "r"); + if (!cursor->mtabp) { + fprintf(stderr, "Error: cannot read %s\n", mtab); + return 1; + } + return 0; +} + +static inline int platform_mntent_next(struct mntent_cursor * cursor, struct mntent * t) +{ + t = getmntent(cursor->mtabp); + if (t == NULL) + return 1; + return 0; +} + +static inline void platform_mntent_close(struct mntent_cursor * cursor) +{ + endmntent(cursor->mtabp); +} + + #endif /* __XFS_FREEBSD_H__ */ diff --git a/include/gnukfreebsd.h b/include/gnukfreebsd.h index 95c4c13..2740cae 100644 --- a/include/gnukfreebsd.h +++ b/include/gnukfreebsd.h @@ -31,6 +31,7 @@ #include #include #include +#include #define constpp char * const * @@ -126,4 +127,34 @@ platform_discard_blocks(int fd, uint64_t start, uint64_t len) return 0; } +/** + * Abstraction of mountpoints. + */ +struct mntent_cursor { + FILE *mtabp; +}; + +static inline int platform_mntent_open(struct mntent_cursor * cursor, char *mtab) +{ + cursor->mtabp = setmntent(mtab, "r"); + if (!cursor->mtabp) { + fprintf(stderr, "Error: cannot read %s\n", mtab); + return 1; + } + return 0; +} + +static inline int platform_mntent_next(struct mntent_cursor * cursor, struct mntent * t) +{ + t = getmntent(cursor->mtabp); + if (t == NULL) + return 1; + return 0; +} + +static inline void platform_mntent_close(struct mntent_cursor * cursor) +{ + endmntent(cursor->mtabp); +} + #endif /* __XFS_KFREEBSD_H__ */ diff --git a/include/irix.h b/include/irix.h index 28564c8..cb9cce0 100644 --- a/include/irix.h +++ b/include/irix.h @@ -37,6 +37,7 @@ #include #include #include +#include #define __int8_t char #define __int16_t short @@ -423,4 +424,35 @@ static __inline__ char * strsep(char **s, const char *ct) #define XFS_XFLAG_NODEFRAG 0x00002000 +/** + * Abstraction of mountpoints. + */ +struct mntent_cursor { + FILE *mtabp; +}; + +static inline int platform_mntent_open(struct mntent_cursor * cursor, char *mtab) +{ + cursor->mtabp = setmntent(mtab, "r"); + if (!cursor->mtabp) { + fprintf(stderr, "Error: cannot read %s\n", mtab); + return 1; + } + return 0; +} + +static inline int platform_mntent_next(struct mntent_cursor * cursor, struct mntent * t) +{ + t = getmntent(cursor->mtabp); + if (t == NULL) + return 1; + return 0; +} + +static inline void platform_mntent_close(struct mntent_cursor * cursor) +{ + endmntent(cursor->mtabp); +} + + #endif /* __XFS_IRIX_H__ */ diff --git a/include/linux.h b/include/linux.h index 8804c2d..437970b 100644 --- a/include/linux.h +++ b/include/linux.h @@ -30,6 +30,7 @@ #include #include #include +#include static __inline__ int xfsctl(const char *path, int fd, int cmd, void *p) { @@ -145,4 +146,34 @@ typedef __uint64_t xfs_ino_t; typedef __uint32_t xfs_dev_t; typedef __int64_t xfs_daddr_t; +/** + * Abstraction of mountpoints. + */ +struct mntent_cursor { + FILE *mtabp; +}; + +static inline int platform_mntent_open(struct mntent_cursor * cursor, char *mtab) +{ + cursor->mtabp = setmntent(mtab, "r"); + if (!cursor->mtabp) { + fprintf(stderr, "Error: cannot read %s\n", mtab); + return 1; + } + return 0; +} + +static inline int platform_mntent_next(struct mntent_cursor * cursor, struct mntent * t) +{ + t = getmntent(cursor->mtabp); + if (t == NULL) + return 1; + return 0; +} + +static inline void platform_mntent_close(struct mntent_cursor * cursor) +{ + endmntent(cursor->mtabp); +} + #endif /* __XFS_LINUX_H__ */ -- 2.4.3 From jtulak@redhat.com Tue Sep 29 11:07:59 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id ADD237F37 for ; Tue, 29 Sep 2015 11:07:59 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 5718C304048 for ; Tue, 29 Sep 2015 09:07:56 -0700 (PDT) X-ASG-Debug-ID: 1443542871-04bdf0462715b2b0001-NocioJ Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) by cuda.sgi.com with ESMTP id eFT9GUXBuGfl7JnC (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 29 Sep 2015 09:07:52 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-RBL-Trusted-Forwarder: 209.85.223.176 Received: by ioii196 with SMTP id i196so16021847ioi.3 for ; Tue, 29 Sep 2015 09:07:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Lh5gVCnvsApsLE3WAjZie6b6Sx8XIqoZG8J4uJfACkE=; b=fVYsaPZZjtCchMMdtcqFWeXfHKhyXAYeX8xVO36ILpIxJ1E9pAU8TPqqDY3dik8rk6 gFGa2Zn8TRr+CfARf2JsNWtlWml43Krh0HSa+Vilu0L0BOJb+kaNs8Xc+qYwWdU52N0u SlKUSgqmjsonGLVms2M6wgqlzy5AJNHGyHrYWk9VPdNV1ODTuTafzI5XUcs0EO7/acpO YueVjuA2XrEdmO0yce6gJAPYDMuQJbLq2exvSxjetY2oQxIIytyia7+6+8O49rEBumbW TcADTm+3nbF6ib6yPv7/lkqerHrlppzO2wUsM/Ggdqatewlqyl3hfHF0nRffiEe8z3ut G0gw== X-Gm-Message-State: ALoCoQl/eJIUS0NLxD8AZxQzazhg8hb0F9RRuz3Jw6VrXt5O35EAwgjZPK7YPlR0f0TfUcFGRZot X-Received: by 10.107.25.143 with SMTP id 137mr30598733ioz.52.1443542871668; Tue, 29 Sep 2015 09:07:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.64.15 with HTTP; Tue, 29 Sep 2015 09:07:32 -0700 (PDT) In-Reply-To: <20150924225338.GV19114@dastard> References: <1442311164-12921-1-git-send-email-jtulak@redhat.com> <1442311164-12921-13-git-send-email-jtulak@redhat.com> <20150923033655.GQ3902@dastard> <20150924225338.GV19114@dastard> From: Jan Tulak Date: Tue, 29 Sep 2015 18:07:32 +0200 Message-ID: Subject: Re: [PATCH 12/14] xfsprogs: make fsr use mntinfo when there is no mntent To: Dave Chinner X-ASG-Orig-Subj: Re: [PATCH 12/14] xfsprogs: make fsr use mntinfo when there is no mntent Cc: xfs-oss Content-Type: multipart/alternative; boundary=001a1140aa70158f1e0520e50483 X-Barracuda-Connect: mail-io0-f176.google.com[209.85.223.176] X-Barracuda-Start-Time: 1443542872 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.23015 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message --001a1140aa70158f1e0520e50483 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 25, 2015 at 12:53 AM, Dave Chinner wrote: > On Thu, Sep 24, 2015 at 04:38:49PM +0200, Jan Tulak wrote: > > On Wed, Sep 23, 2015 at 5:36 AM, Dave Chinner > wrote: > > > > > On Tue, Sep 15, 2015 at 11:59:22AM +0200, Jan Tulak wrote: > > > > @@ -202,6 +205,27 @@ find_mountpoint(char *mtab, char *argname, > struct > > > stat64 *sb) > > > > } > > > > > > > > while ((t =3D getmntent(mtabp))) { > > > > +#elif defined(HAVE_GETMNTINFO) > > > > + struct statfs *stats; > > > > + int error, i, count; > > > > + // because "t" is a pointer, but we don't need to use > > > > + // malloc for this usage > > > > + struct mntent t_tmp; > > > > + t =3D &t_tmp; > > > > + > > > > + > > > > + error =3D 0; > > > > + if ((count =3D getmntinfo(&stats, 0)) < 0) { > > > > + fprintf(stderr, _("%s: getmntinfo() failed: %s\n"), > > > > + progname, strerror(errno)); > > > > + return 0; > > > > + } > > > > + > > > > + for (i =3D 0; i < count; i++) { > > > > + mntinfo2mntent(&stats[i], t); > > > > +#else > > > > +# error "How do I extract info about mounted filesystems on this > > > platform?" > > > > +#endif > > > > > > No, please don't do that. Having a loop iterator split across two > > > separate defines is unmaintainable. Write two separate functions > > > with the different loop iterators, then factor the common bit out > > > of them into a single function. > > > > > > > > I did a little refactoring to solve it. What I would like to ask ab=E2= =80=8Bout > is > > this: > > When I can put ifdef just inside of a function like fnc(void) { #ifdef.= .. > > #else ... #endif }, with little to no code outside of the ifdef, is it > > better to put the ifdef outside, or keep it inside? > > The idea is that the "little differences" are put in functions that > end up in include/.h or libxfs/.c, so there are > no ifdefs in any of the application or library code. The build will > automatically include the correct function on the given platform, > and so the application code does not need such ifdefs at all. > > e.g. you could implement these functions to abstract the differences > away from xfs_fsr and any other code that iterates the mount table: > > struct mntent_cursor { > /* variables needed to track iteration of the mtab */ > }; > > platform_first_mntent() > platform_next_mntent() > platform_end_mntent() > > and so the code would look like: > > struct mntent_cursor cursor; > > mntent =3D platform_first_mntent(&cursor) > > do { > /* process mntent */ > } while (mntent =3D platform_next_mntent(&cursor, mntent)); > > platform_end_mntent(&cursor); > > This completely abstracts the differences related to the the mount > table traversal, and allows the aplication level code to be written > in a clean, easily maintainable fashion... > =E2=80=8BSo something like what I just posted? I added the same code that w= orks for Linux into other platforms other than OS X. =E2=80=8B =E2=80=8BBecause as it was there before, it either works on them, =E2=80= =8Bor no one care. And I really don't have an idea how to test it on Irix... :-) Cheers, Jan --=20 Jan Tulak jtulak@redhat.com / jan@tulak.me --001a1140aa70158f1e0520e50483 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Se= p 25, 2015 at 12:53 AM, Dave Chinner <david@fromorbit.com> wrote:
On Thu, Sep 24, 2015 at 04:38:49PM +0200, Jan Tulak wrote: > On Wed, Sep 23, 2015 at 5:36 AM, Dave Chinner <david@fromorbit.com> wrote:
>
> > On Tue, Sep 15, 2015 at 11:59:22AM +0200, Jan Tulak wrote:
> > > @@ -202,6 +205,27 @@ find_mountpoint(char *mtab, char *argna= me, struct
> > stat64 *sb)
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0while ((t =3D getmntent(mtabp))) {=
> > > +#elif defined(HAVE_GETMNTINFO)
> > > +=C2=A0 =C2=A0 =C2=A0struct statfs=C2=A0 =C2=A0*stats;
> > > +=C2=A0 =C2=A0 =C2=A0int error, i, count;
> > > +=C2=A0 =C2=A0 =C2=A0// because "t" is a pointer, = but we don't need to use
> > > +=C2=A0 =C2=A0 =C2=A0// malloc for this usage
> > > +=C2=A0 =C2=A0 =C2=A0struct mntent t_tmp;
> > > +=C2=A0 =C2=A0 =C2=A0t =3D &t_tmp;
> > > +
> > > +
> > > +=C2=A0 =C2=A0 =C2=A0error =3D 0;
> > > +=C2=A0 =C2=A0 =C2=A0if ((count =3D getmntinfo(&stats, 0= )) < 0) {
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fprintf(std= err, _("%s: getmntinfo() failed: %s\n"),
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0progname, strerror(errno)); > > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 0; > > > +=C2=A0 =C2=A0 =C2=A0}
> > > +
> > > +=C2=A0 =C2=A0 =C2=A0for (i =3D 0; i < count; i++) {
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mntinfo2mnt= ent(&stats[i], t);
> > > +#else
> > > +# error "How do I extract info about mounted filesyste= ms on this
> > platform?"
> > > +#endif
> >
> > No, please don't do that. Having a loop iterator split across= two
> > separate defines is unmaintainable. Write two separate functions<= br> > > with the different loop iterators, then factor the common bit out=
> > of them into a single function.
> >
> >
> I did a little refactoring to solve it. What I would like to ask ab=E2= =80=8Bout is
> this:
> When I can put ifdef just inside of a function like fnc(void) { #ifdef= ...
> #else ... #endif }, with little to no code outside of the ifdef, is it=
> better to put the ifdef outside, or keep it inside?

The idea is that the "little differences" are put in = functions that
end up in include/<platform>.h or libxfs/<platform>.c, so there= are
no ifdefs in any of the application or library code. The build will
automatically include the correct function on the given platform,
and so the application code does not need such ifdefs at all.

e.g. you could implement these functions to abstract the differences
away from xfs_fsr and any other code that iterates the mount table:

struct mntent_cursor {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* variables needed to track iteration of the m= tab */
};

platform_first_mntent()
platform_next_mntent()
platform_end_mntent()

and so the code would look like:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct mntent_cursor=C2=A0 =C2=A0 cursor;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 mntent =3D platform_first_mntent(&cursor)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 do {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* process mntent *= /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } while (mntent =3D platform_next_mntent(&c= ursor, mntent));

=C2=A0 =C2=A0 =C2=A0 =C2=A0 platform_end_mntent(&cursor);

This completely abstracts the differences related to the the mount
table traversal, and allows the aplication level code to be written
in a clean, easily maintainable fashion...

<= div>
=E2=80=8BSo something like what I just posted? I adde= d the same code that works for Linux into other platforms other than OS X. = =E2=80=8B
=C2=A0
=E2=80=8BBecause as it was there bef= ore, =C2=A0it either works on them, =E2=80=8Bor no one care. And I really d= on't have an idea how to test it on Irix... :-)

Cheers,
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;display:inline">Jan

--
--001a1140aa70158f1e0520e50483-- From akpm@linux-foundation.org Tue Sep 29 17:02:53 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id BAD687F37 for ; Tue, 29 Sep 2015 17:02:53 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id AB8AA8F8059 for ; Tue, 29 Sep 2015 15:02:50 -0700 (PDT) X-ASG-Debug-ID: 1443564167-04cbb033b317e5b0001-NocioJ Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) by cuda.sgi.com with ESMTP id S4RfU4CJJkFHA6Ro (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 29 Sep 2015 15:02:48 -0700 (PDT) X-Barracuda-Envelope-From: akpm@linux-foundation.org X-Barracuda-Apparent-Source-IP: 140.211.169.12 Received: from akpm3.mtv.corp.google.com (unknown [216.239.45.65]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 46AC1C70; Tue, 29 Sep 2015 22:02:47 +0000 (UTC) Date: Tue, 29 Sep 2015 15:02:46 -0700 From: Andrew Morton To: mhocko@kernel.org Cc: , Dave Chinner , "Theodore Ts'o" , Ming Lei , Andreas Dilger , Oleg Drokin , Al Viro , Christoph Hellwig , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, Michal Hocko Subject: Re: [PATCH] mm, fs: Obey gfp_mapping for add_to_page_cache Message-Id: <20150929150246.286cc6013bce3eec170376aa@linux-foundation.org> X-ASG-Orig-Subj: Re: [PATCH] mm, fs: Obey gfp_mapping for add_to_page_cache In-Reply-To: <1443193461-31402-1-git-send-email-mhocko@kernel.org> References: <1443193461-31402-1-git-send-email-mhocko@kernel.org> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail.linuxfoundation.org[140.211.169.12] X-Barracuda-Start-Time: 1443564168 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.23026 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header On Fri, 25 Sep 2015 17:04:21 +0200 mhocko@kernel.org wrote: > From: Michal Hocko > > 6afdb859b710 ("mm: do not ignore mapping_gfp_mask in page cache > allocation paths) has caught some users of hardcoded GFP_KERNEL > used in the page cache allocation paths. This, however, wasn't complete > and there were others which went unnoticed. > > Dave Chinner has reported the following deadlock for xfs on loop device: > : With the recent merge of the loop device changes, I'm now seeing > : XFS deadlock on my single CPU, 1GB RAM VM running xfs/073. > : > : The deadlocked is as follows: > : > : kloopd1: loop_queue_read_work > : xfs_file_iter_read > : lock XFS inode XFS_IOLOCK_SHARED (on image file) > : page cache read (GFP_KERNEL) > : radix tree alloc > : memory reclaim > : reclaim XFS inodes > : log force to unpin inodes > : > : > : xfs-cil/loop1: > : xlog_cil_push > : xlog_write > : > : xlog_state_get_iclog_space() > : > : > : > : kloopd1: loop_queue_write_work > : xfs_file_write_iter > : lock XFS inode XFS_IOLOCK_EXCL (on image file) > : > : > : i.e. the kloopd, with it's split read and write work queues, has > : introduced a dependency through memory reclaim. i.e. that writes > : need to be able to progress for reads make progress. > : > : The problem, fundamentally, is that mpage_readpages() does a > : GFP_KERNEL allocation, rather than paying attention to the inode's > : mapping gfp mask, which is set to GFP_NOFS. > : > : The didn't used to happen, because the loop device used to issue > : reads through the splice path and that does: > : > : error = add_to_page_cache_lru(page, mapping, index, > : GFP_KERNEL & mapping_gfp_mask(mapping)); > > This has changed by aa4d86163e4 (block: loop: switch to VFS ITER_BVEC). xfs-on-loop deadlocks since April would appear to warrant a -stable backport, yes? > this is a rebase on top of the current mmotm > (2015-09-22-15-28) So I've redone the patch against current mainline. From sandeen@sandeen.net Tue Sep 29 17:25:06 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 69CA57F37 for ; Tue, 29 Sep 2015 17:25:06 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 28005304048 for ; Tue, 29 Sep 2015 15:25:05 -0700 (PDT) X-ASG-Debug-ID: 1443565503-04cbb033b117ecb0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id rGPzLGIKPerKvRzg for ; Tue, 29 Sep 2015 15:25:04 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id A228361A5FC0 for ; Tue, 29 Sep 2015 17:25:03 -0500 (CDT) Subject: Re: [PATCH 1/2] xfs: always drain dio before extending aio write submission To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] xfs: always drain dio before extending aio write submission References: <1443465481-63460-1-git-send-email-bfoster@redhat.com> <1443465481-63460-2-git-send-email-bfoster@redhat.com> From: Eric Sandeen Message-ID: <560B0FBE.5010205@sandeen.net> Date: Tue, 29 Sep 2015 17:25:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1443465481-63460-2-git-send-email-bfoster@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1443565503 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.23026 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Looks good to me, and tested w/ a testcase I'll send in a bit. Reviewed-by: Eric Sandeen On 9/28/15 1:38 PM, Brian Foster wrote: > XFS supports and typically allows concurrent asynchronous direct I/O > submission to a single file. One exception to the rule is that file > extending dio writes that start beyond the current EOF (e.g., > potentially create a hole at EOF) require exclusive I/O access to the > file. This is because such writes must zero any pre-existing blocks > beyond EOF that are exposed by virtue of now residing within EOF as a > result of the write about to be submitted. > > Before EOF zeroing can occur, the current file i_size must be stabilized > to avoid data corruption. In this scenario, XFS upgrades the iolock to > exclude any further I/O submission, waits on in-flight I/O to complete > to ensure i_size is up to date (i_size is updated on dio write > completion) and restarts the various checks against the state of the > file. The problem is that this protection sequence is triggered only > when the iolock is currently held shared. While this is true for async > dio in most cases, the caller may upgrade the lock in advance based on > arbitrary circumstances with respect to EOF zeroing. For example, the > iolock is always acquired exclusively if the start offset is not block > aligned. This means that even though the iolock is already held > exclusive for such I/Os, pending I/O is not drained and thus EOF zeroing > can occur based on an unstable i_size. > > This problem has been reproduced as guest data corruption in virtual > machines with file-backed qcow2 virtual disks hosted on an XFS > filesystem. The virtual disks must be configured with aio=native mode > and the must not be truncated out to the maximum file size (as some virt > managers will do). > > Update xfs_file_aio_write_checks() to unconditionally drain in-flight > dio before EOF zeroing can occur. Rather than trigger the wait based on > iolock state, use a new flag and upgrade the iolock when necessary. Note > that this results in a full restart of the inode checks even when the > iolock was already held exclusive when technically it is only required > to recheck i_size. This should be a rare enough occurrence that it is > preferable to keep the code simple rather than create an alternate > restart jump target. > > Signed-off-by: Brian Foster > --- > fs/xfs/xfs_file.c | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c > index e78feb4..347b3e0 100644 > --- a/fs/xfs/xfs_file.c > +++ b/fs/xfs/xfs_file.c > @@ -574,6 +574,7 @@ xfs_file_aio_write_checks( > struct xfs_inode *ip = XFS_I(inode); > ssize_t error = 0; > size_t count = iov_iter_count(from); > + bool drained_dio = false; > > restart: > error = generic_write_checks(iocb, from); > @@ -611,12 +612,13 @@ restart: > bool zero = false; > > spin_unlock(&ip->i_flags_lock); > - if (*iolock == XFS_IOLOCK_SHARED) { > - xfs_rw_iunlock(ip, *iolock); > - *iolock = XFS_IOLOCK_EXCL; > - xfs_rw_ilock(ip, *iolock); > - iov_iter_reexpand(from, count); > - > + if (!drained_dio) { > + if (*iolock == XFS_IOLOCK_SHARED) { > + xfs_rw_iunlock(ip, *iolock); > + *iolock = XFS_IOLOCK_EXCL; > + xfs_rw_ilock(ip, *iolock); > + iov_iter_reexpand(from, count); > + } > /* > * We now have an IO submission barrier in place, but > * AIO can do EOF updates during IO completion and hence > @@ -626,6 +628,7 @@ restart: > * no-op. > */ > inode_dio_wait(inode); > + drained_dio = true; > goto restart; > } > error = xfs_zero_eof(ip, iocb->ki_pos, i_size_read(inode), &zero); > From sandeen@sandeen.net Tue Sep 29 20:03:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 69C8B7F37 for ; Tue, 29 Sep 2015 20:03:40 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 5A3AE304059 for ; Tue, 29 Sep 2015 18:03:36 -0700 (PDT) X-ASG-Debug-ID: 1443575012-04cbb033b21819b0001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id i8n2PfSoIHPQ1Qs6 for ; Tue, 29 Sep 2015 18:03:32 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id EF07463C77A5; Tue, 29 Sep 2015 20:03:31 -0500 (CDT) To: fstests From: Eric Sandeen Subject: [PATCH] test extending sub-block AIO writes for races X-Enigmail-Draft-Status: N1110 X-ASG-Orig-Subj: [PATCH] test extending sub-block AIO writes for races Cc: xfs@oss.sgi.com Message-ID: <560B34E3.4080107@sandeen.net> Date: Tue, 29 Sep 2015 20:03:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1443575012 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.23031 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- This tests bfoster's [PATCH 1/2] xfs: always drain dio before extending aio write submission patch; it launches four adjacent 1k IOs past EOF, then reads back to see if we have 4k worth of the data we wrote, or something else - possibly zeros from sub-block zeroing and eof racing. Signed-off-by: Eric Sandeen --- diff --git a/src/aio-dio-regress/aio-dio-eof-race.c b/src/aio-dio-regress/aio-dio-eof-race.c new file mode 100644 index 0000000..c1ce695 --- /dev/null +++ b/src/aio-dio-regress/aio-dio-eof-race.c @@ -0,0 +1,170 @@ +/* + * Launch 4 file-extending extending sub-block AIOs and ensure that we + * don't see data corruption when they're all complete. + * + * Copyright (C) 2015 Red Hat, Inc. All Rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define BUF_SIZE 4096 +#define IO_PATTERN 0xab + +void +dump_buffer( + void *buf, + off64_t offset, + ssize_t len) +{ + int i, j; + char *p; + int new; + + for (i = 0, p = (char *)buf; i < len; i += 16) { + char *s = p; + + if (i && !memcmp(p, p - 16, 16)) { + new = 0; + } else { + if (i) + printf("*\n"); + new = 1; + } + + if (!new) { + p += 16; + continue; + } + + printf("%08llx ", (unsigned long long)offset + i); + for (j = 0; j < 16 && i + j < len; j++, p++) + printf("%02x ", *p); + printf(" "); + for (j = 0; j < 16 && i + j < len; j++, s++) { + if (isalnum((int)*s)) + printf("%c", *s); + else + printf("."); + } + printf("\n"); + + } + printf("%08llx\n", (unsigned long long)offset + i); +} + +int main(int argc, char *argv[]) +{ + struct io_context *ctx = NULL; + struct io_event evs[4]; + struct iocb iocb1, iocb2, iocb3, iocb4; + struct iocb *iocbs[] = { &iocb1, &iocb2, &iocb3, &iocb4 }; + void *buf; + struct stat statbuf; + char cmp_buf[BUF_SIZE]; + int fd, err = 0; + off_t eof; + + fd = open(argv[1], O_DIRECT | O_CREAT | O_TRUNC | O_RDWR, 0600); + if (fd == -1) { + perror("open"); + return 1; + } + + err = posix_memalign(&buf, BUF_SIZE, BUF_SIZE); + if (err) { + fprintf(stderr, "error %s during %s\n", + strerror(err), + "posix_memalign"); + return 1; + } + memset(cmp_buf, IO_PATTERN, BUF_SIZE); + + err = io_setup(4, &ctx); + if (err) { + fprintf(stderr, "error %s during %s\n", + strerror(err), + "io_setup"); + return 1; + } + + eof = 0; + + /* Keep extending until 8MB */ + while (eof < 8 * 1024 * 1024) { + memset(buf, IO_PATTERN, BUF_SIZE); + + fstat(fd, &statbuf); + eof = statbuf.st_size; + + /* + * 4 ios, racing to extend EOF, combined they write full BUF_SIZE + */ + io_prep_pwrite(&iocb1, fd, buf, BUF_SIZE/4, eof + 0 * BUF_SIZE/4); + io_prep_pwrite(&iocb2, fd, buf, BUF_SIZE/4, eof + 1 * BUF_SIZE/4); + io_prep_pwrite(&iocb3, fd, buf, BUF_SIZE/4, eof + 2 * BUF_SIZE/4); + io_prep_pwrite(&iocb4, fd, buf, BUF_SIZE/4, eof + 3 * BUF_SIZE/4); + + err = io_submit(ctx, 4, iocbs); + if (err != 4) { + fprintf(stderr, "error %s during %s\n", + strerror(err), + "io_submit"); + return 1; + } + + err = io_getevents(ctx, 4, 4, evs, NULL); + if (err != 4) { + fprintf(stderr, "error %s during %s\n", + strerror(err), + "io_getevents"); + return 1; + } + + /* + * And then read it back. + * + * Using pread to keep it simple, but AIO has the same effect. + * + * eof is the old eof, we just wrote BUF_SIZE more + */ + if (pread(fd, buf, BUF_SIZE, eof) != BUF_SIZE) { + perror("pread"); + return 1; + } + + /* + * We launched 4 AIOs which, stiched together, should write + * a seamless BUF_SIZE worth of IO_PATTERN to the last block + */ + if (memcmp(buf, cmp_buf, BUF_SIZE)) { + printf("corruption while extending from %ld\n", eof); + dump_buffer(buf, 0, BUF_SIZE); + return 1; + } + } + + printf("Success, all done.\n"); + return 0; +} diff --git a/tests/generic/326 b/tests/generic/326 new file mode 100755 index 0000000..7db04ac --- /dev/null +++ b/tests/generic/326 @@ -0,0 +1,64 @@ +#! /bin/bash +# FS QA Test No. 326 +# +# Test races while extending past EOF via sub-block AIO writes +# +#----------------------------------------------------------------------- +# Copyright (c) 2015 Red Hat, Inc. All Rights Reserved. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation. +# +# This program is distributed in the hope that it would be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write the Free Software Foundation, +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +#----------------------------------------------------------------------- +# + +seq=`basename $0` +seqres=$RESULT_DIR/$seq +echo "QA output created by $seq" + +here=`pwd` +tmp=/tmp/$$ +status=1 # failure is the default! +trap "_cleanup; exit \$status" 0 1 2 3 15 + +_cleanup() +{ + cd / + rm -f $TEST_DIR/tst-aio-dio-eof-race +} + +# get standard environment, filters and checks +. ./common/rc +. ./common/filter + +_supported_fs generic +_supported_os Linux + +_require_test +_require_sparse_files +_require_aiodio aio-dio-eof-race + +# Test does 512 byte DIO, so make sure that'll work +logical_block_size=`_min_dio_alignment $TEST_DEV` + +if [ "$logical_block_size" -gt "512" ]; then + _notrun "device block size: $logical_block_size greater than 512" +fi + +# If 512 isn't a sub-block IO, the test should still pass, so +# let that go. + +# This test does several extending loops internally +$AIO_TEST $TEST_DIR/tst-aio-dio-eof-race + +status=$? +exit diff --git a/tests/generic/326.out b/tests/generic/326.out new file mode 100644 index 0000000..22a3e78 --- /dev/null +++ b/tests/generic/326.out @@ -0,0 +1,2 @@ +QA output created by 326 +Success, all done. diff --git a/tests/generic/group b/tests/generic/group index 4ae256f..a5f3008 100644 --- a/tests/generic/group +++ b/tests/generic/group @@ -207,3 +207,4 @@ 323 auto aio stress 324 auto fsr quick 325 auto quick data log +326 auto quick aio From 2kx_dhh.h57.1db@maximeo-com.com Tue Sep 29 22:28:23 2015 Return-Path: <2kx_dhh.h57.1db@maximeo-com.com> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=HTML_IMAGE_ONLY_28, HTML_MESSAGE,T_DKIM_INVALID autolearn=no version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id A01CA7F37 for ; Tue, 29 Sep 2015 22:28:23 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 80A12304051 for ; Tue, 29 Sep 2015 20:28:20 -0700 (PDT) X-ASG-Debug-ID: 1443583696-04cbb033b2184690001-NocioJ Received: from smtp-a18.md-connecting.com (smtp-a18.md-connecting.com [82.97.42.76]) by cuda.sgi.com with ESMTP id Rz8UWFKGWTtSN0Tb for ; Tue, 29 Sep 2015 20:28:16 -0700 (PDT) X-Barracuda-Envelope-From: 2kx_dhh.h57.1db@maximeo-com.com X-Barracuda-Apparent-Source-IP: 82.97.42.76 DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=maximeo-com.com; h=to :subject:date:from:reply-to:message-id:list-unsubscribe :mime-version:content-type; s=smtp3; bh=HU3v9v6wjaBx8PoHVjRJv48Y I3Y=; b=K6jLtQnM130+ckvOYKXLgZ0KDWgjIJ2975vl5nC7BUQOrVxwoiWHmTLG 3lflb/FsTu1GrlNEQdiaX7wT49PSZjtsq/k4wXmzrdl7um6pehIKp2XsxS9syIAd r45954Uhr/YRMrUoRlTnxJ3JOxn/2+9g9ghe2zZwDrf6ZOPHZug= DomainKey-Signature: a=rsa-sha1; c=simple; d=maximeo-com.com; h=to :subject:date:from:reply-to:message-id:list-unsubscribe :mime-version:content-type; q=dns; s=smtp3; b=HXDC3pojWYXmfVH0fT NqaVzTq7b2ULDeSHzN+Bk7f0xwiSjFzHJg0Woyzj82iO6+FfwMILFcHA2F6+3WRL jqTDaL1lxibc8Z/8eDgTzmoItxtcm6qoiyyybvn874/Tza8CbKaw21jkNHZcltCU lrT8ZypPrcZyLYO0vdE5rUyOU= To: xfs Subject: =?utf-8?Q?d=C3=A9posez_votre_demande_et_recevez_jusqu'=C3=A0_3_devis_grat?= =?utf-8?Q?uits!?= Date: Wed, 30 Sep 2015 05:28:08 +0200 X-ASG-Orig-Subj: =?utf-8?Q?d=C3=A9posez_votre_demande_et_recevez_jusqu'=C3=A0_3_devis_grat?= =?utf-8?Q?uits!?= From: solution travaux batiment Reply-to: solution travaux batiment <2kx_dhh.h57.1db@maximeo-com.com> Precedence: Message-ID: List-Unsubscribe: X-campaign-id: 44181406984402735757094_47 X-uid-id-m: eGZzQG9zcy5zZ2kuY29t=90 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Part1_b9bed32e681b518886a423b37c38d771" X-Barracuda-Connect: smtp-a18.md-connecting.com[82.97.42.76] X-Barracuda-Start-Time: 1443583696 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.73 X-Barracuda-Spam-Status: No, SCORE=0.73 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_IMAGE_ONLY_28, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.23033 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.73 HTML_IMAGE_ONLY_28 BODY: HTML: images with 2400-2800 bytes of words 0.00 HTML_MESSAGE BODY: HTML included in message --Part1_b9bed32e681b518886a423b37c38d771 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: quoted-printable Pour visualiser et se d=C3=A9sabonner ce message, =20 Veuillez, copier puis coller, l'adresse URL compl=C3=A8te ci-dessous dans= la barre d'adresse de votre navigateur et appuyer sur la touche "Entr=C3=A9e= " de votre clavier. - - - - - - - - - - - - - - - - -=20 http://app.maximeo-com.com/v/?camp=3D44181406984402735757094_47&ms=3DeGZz= QG9zcy5zZ2kuY29t - - - - - - - - - - - - - - - - -=20 --Part1_b9bed32e681b518886a423b37c38d771 Content-Type: text/html; charset = "utf-8" Content-Transfer-Encoding: quoted-printable d=C3=A9posez votre demande et recevez jusqu\'=C3=A0 3 devis gratui= ts!

Si cet email ne= s’affiche pas correctement, suivez ce lien.

<= table cellpadding=3D"0" cellspacing=3D"0" width=3D"600">
3D"header"
3D"image
3D"étapes"
3D"_pspacer4"

Pour se désabonner : Su= ivez ce lien.
Si ce message vous a causé un quelconque d&= eacute;rangement, nous vous prions de nous en excuser.

--Part1_b9bed32e681b518886a423b37c38d771-- From david@fromorbit.com Wed Sep 30 00:04:34 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 7A88F7F37 for ; Wed, 30 Sep 2015 00:04:34 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 0A355AC00C for ; Tue, 29 Sep 2015 22:04:30 -0700 (PDT) X-ASG-Debug-ID: 1443589467-04bdf0462216c280001-NocioJ Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id SxcGrm9au5txIOdh for ; Tue, 29 Sep 2015 22:04:28 -0700 (PDT) X-Barracuda-Envelope-From: david@fromorbit.com X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BUCQAjbAtWPK2+LHlegyRUaYJdg32iTgEBAQEBAQaLCxiLHIV3BAICgT1NAQEBAQEBBwEBAQFBP4QkAQEBAwE6HCMFCwgDGAklDwUlAwcaE4gmB8tnAQEBAQEBBAEBAQEBARwZhhOFRIUNB4MYgRQFhzIDhn2HRYUWh3iBVEaHE5IegnQcgWYsM4keAQEB Received: from ppp121-44-190-173.lns20.syd7.internode.on.net (HELO dastard) ([121.44.190.173]) by ipmail05.adl6.internode.on.net with ESMTP; 30 Sep 2015 14:34:26 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1Zh9Z4-0002Er-1U; Wed, 30 Sep 2015 15:04:26 +1000 Date: Wed, 30 Sep 2015 15:04:26 +1000 From: Dave Chinner To: Angelo Dureghello Cc: xfs@oss.sgi.com Subject: Re: xfstests, xfs test 080 fails on arm 32bit Message-ID: <20150930050425.GC3902@dastard> X-ASG-Orig-Subj: Re: xfstests, xfs test 080 fails on arm 32bit References: <560A9307.6080600@nomovok.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560A9307.6080600@nomovok.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1443589467 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.23035 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On Tue, Sep 29, 2015 at 03:32:55PM +0200, Angelo Dureghello wrote: > Hi, > > executing this test on a 32bit arm. i get (i traced mmapping sizes): > > # ./start_xfs_test.sh > QA output created by 080 > [ 161.827446] XFS (mmcblk0p5): Mounting V4 Filesystem > [ 162.357952] XFS (mmcblk0p5): Ending clean mount > > mmapping 512000000 > mmapping 512000000 > mmapping 512000000 > mmapping 512000000 > mmapping 512000000 > mmapping 512000000 > > oio ( 3241) 15:18:17 > --------------------- > mmap() failed - 0xffffffff 12 > > doio ( 3241) 15:18:17 > --------------------- > mmap-read() request failed: Cannot allocate memory (12) > Request number 15 > fd 4 is file /media/p5/rwtest.file - open flags are 0 O_RDONLY, > read done at file offset 978498 > number of requests is 1, strides per request is 1 > i/o byte count = 119505 > memory alignment is unaligned > > syscall: mmap-read(NULL, 512000000, PROT_READ, MAP_SHARED, 4, 0) > file is mmaped to: 0x0 > file-mem=0xeee42, length=119505, buffer=0x484a6 Does it close/unmap the other files it mmaps? i.e. 32 bit only has a 3GB address space for user applications (IIRC), so the 6th 512MB mapping will run the process out of address space and hence fail.... > doio ( 3241) 15:18:17 > --------------------- > doio(): operation 120 returned != 0 > rwtest.sh : iogen reported errors (r=141) > > > Is it possible the test was thought to pass on 64bit systems ? Works just fine on 64 bit systems: $ sudo ./check xfs/080 FSTYP -- xfs (debug) PLATFORM -- Linux/x86_64 test2 4.3.0-rc1-dgc+ MKFS_OPTIONS -- -f -bsize=4096 /dev/sdg MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/sdg /mnt/scratch xfs/080 2s ... 7s Ran: xfs/080 Passed all 1 tests And looking at the memory footprint: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3300 root 20 0 3010672 1612 1344 D 4.7 0.0 0:00.14 doio Yup, 3GB of virtual address space used, 1.6MB of actual memory used. _require_64bit_userspace is probably needed here... Cheers, Dave. -- Dave Chinner david@fromorbit.com From jtulak@redhat.com Wed Sep 30 03:22:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id BBD867F37 for ; Wed, 30 Sep 2015 03:22:05 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 503BEAC007 for ; Wed, 30 Sep 2015 01:22:02 -0700 (PDT) X-ASG-Debug-ID: 1443601319-04cbb033b3189b00001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id tJBdanOhG66baHsK (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 30 Sep 2015 01:22:00 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id B522C4DB01; Wed, 30 Sep 2015 08:21:59 +0000 (UTC) Received: from honza-mbp.lan.tulak.me.lan.tulak.me (vpn1-4-184.ams2.redhat.com [10.36.4.184]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8U8Lvcm015460; Wed, 30 Sep 2015 04:21:58 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: david@fromorbit.com, Jan Tulak Subject: [PATCH 11/14 v2] xfsprogs: Add statvfs64 for osx Date: Wed, 30 Sep 2015 10:21:55 +0200 X-ASG-Orig-Subj: [PATCH 11/14 v2] xfsprogs: Add statvfs64 for osx Message-Id: <1443601315-774-1-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-12-git-send-email-jtulak@redhat.com> References: <1442311164-12921-12-git-send-email-jtulak@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443601320 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 UPDATE: - removing unnecessary include lines (again) Simply rename statvfs64 to statfs with a #define. OSX version of statvfs is missing some members, so if the renaming is in effect (stavfs64 is defined), don't try to use them and go directly for the other member value. Signed-off-by: Jan Tulak --- fsr/xfs_fsr.c | 8 ++++++++ include/builddefs.in | 2 +- include/darwin.h | 5 +++++ 3 files changed, 14 insertions(+), 1 deletion(-) diff --git a/fsr/xfs_fsr.c b/fsr/xfs_fsr.c index e1b7bd6..c8ef18f 100644 --- a/fsr/xfs_fsr.c +++ b/fsr/xfs_fsr.c @@ -948,7 +948,11 @@ fsrfile_common( fname, strerror(errno)); return -1; } +#ifndef statvfs64 bsize = vfss.f_frsize ? vfss.f_frsize : vfss.f_bsize; +#else + bsize = vfss.f_bsize; +#endif if (statp->bs_blksize * statp->bs_blocks > vfss.f_bfree * bsize - minimumfree) { fsrprintf(_("insufficient freespace for: %s: " @@ -1728,7 +1732,11 @@ xfs_getrt(int fd, struct statvfs64 *sfbp) close(fd); return -1; } +#ifndef statvfs64 bsize = (sfbp->f_frsize ? sfbp->f_frsize : sfbp->f_bsize); +#else + bsize = sfbp->f_bsize; +#endif factor = fsgeom.blocksize / bsize; /* currently this is == 1 */ sfbp->f_bfree = (cnt.freertx * fsgeom.rtextsize) * factor; return 0; diff --git a/include/builddefs.in b/include/builddefs.in index 25b8816..31e21ba 100644 --- a/include/builddefs.in +++ b/include/builddefs.in @@ -123,7 +123,7 @@ PCFLAGS = -D_GNU_SOURCE $(GCCFLAGS) endif ifeq ($(PKG_PLATFORM),darwin) PCFLAGS = $(GCCFLAGS) -DEPENDFLAGS = -D__APPLE__ +DEPENDFLAGS = -D__APPLE__ -D_DARWIN_FEATURE_64_BIT_INODE endif ifeq ($(PKG_PLATFORM),irix) PLDLIBS = -ldisk -lgen diff --git a/include/darwin.h b/include/darwin.h index 0d2f175..288ad1f 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -216,4 +216,9 @@ static inline int timer_gettime (timer_t timerid, struct itimerspec *value) return getitimer(ITIMER_REAL, value); } +/* FSR */ + +#define statvfs64 statfs +#define _PATH_MOUNTED "/etc/mtab" + #endif /* __XFS_DARWIN_H__ */ -- 2.5.1 From jtulak@redhat.com Wed Sep 30 03:23:14 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 0DC317F37 for ; Wed, 30 Sep 2015 03:23:14 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id C8D358F8040 for ; Wed, 30 Sep 2015 01:23:10 -0700 (PDT) X-ASG-Debug-ID: 1443601389-04bdf0462816f940001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id h7Qq7lALQFvT7oNF (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 30 Sep 2015 01:23:09 -0700 (PDT) X-Barracuda-Envelope-From: jtulak@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client 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 (Postfix) with ESMTPS id 4D79D461EA; Wed, 30 Sep 2015 08:23:09 +0000 (UTC) Received: from honza-mbp.lan.tulak.me.lan.tulak.me (vpn1-4-184.ams2.redhat.com [10.36.4.184]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8U8N6US013632; Wed, 30 Sep 2015 04:23:07 -0400 From: Jan Tulak To: xfs@oss.sgi.com Cc: david@fromorbit.com, Jan Tulak Subject: [PATCH 10/14 v2] xfsprogs: Add a timer implementation for OS X Date: Wed, 30 Sep 2015 10:23:05 +0200 X-ASG-Orig-Subj: [PATCH 10/14 v2] xfsprogs: Add a timer implementation for OS X Message-Id: <1443601385-831-1-git-send-email-jtulak@redhat.com> In-Reply-To: <1442311164-12921-11-git-send-email-jtulak@redhat.com> References: <1442311164-12921-11-git-send-email-jtulak@redhat.com> 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: 1443601389 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.157.11:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 UPDATE: - Instead of ifndef just call memset to zero the structure universally. OS X does not have the timer used in xfs_repair. Add a simple implementation providing the required capabilities. Signed-off-by: Jan Tulak --- include/darwin.h | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ repair/progress.c | 3 +-- 2 files changed, 49 insertions(+), 2 deletions(-) diff --git a/include/darwin.h b/include/darwin.h index 1409c91..0d2f175 100644 --- a/include/darwin.h +++ b/include/darwin.h @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include @@ -168,4 +169,51 @@ platform_discard_blocks(int fd, uint64_t start, uint64_t len) return 0; } +/* + * POSIX timer replacement. + * It really just do the minimum we need for xfs_repair. + * Also, as setitimer can't create multiple timers, + * the timerid things are useless - we have only one ITIMER_REAL + * timer. + */ +#define CLOCK_REALTIME ITIMER_REAL +#define itimerspec itimerval +typedef uint64_t timer_t; +typedef double timer_c; +typedef clock_id_t clockid_t; + + +static inline int timer_create (clockid_t __clock_id, + struct sigevent *__restrict __evp, + timer_t *__restrict timer) +{ + // set something, to initialize the variable, just in case + *timer = 0; + return 0; +} + +static inline int timer_settime (timer_t timerid, int flags, + const struct itimerspec *__restrict timerspec, + struct itimerspec *__restrict ovalue) +{ + return setitimer(ITIMER_REAL, timerspec, ovalue); +} + +static inline int timer_delete (timer_t timerid) +{ + struct itimerspec timespec; + + timespec.it_interval.tv_sec=0; + timespec.it_interval.tv_usec=0; + timespec.it_value.tv_sec=0; + timespec.it_value.tv_usec=0; + + return setitimer(ITIMER_REAL, ×pec, NULL); +} + +static inline int timer_gettime (timer_t timerid, struct itimerspec *value) +{ + return getitimer(ITIMER_REAL, value); +} + #endif /* __XFS_DARWIN_H__ */ diff --git a/repair/progress.c b/repair/progress.c index 27cbaef..418b803 100644 --- a/repair/progress.c +++ b/repair/progress.c @@ -183,10 +183,9 @@ progress_rpt_thread (void *p) * Specify a repeating timer that fires each MSG_INTERVAL seconds. */ + memset(×pec, 0, sizeof(timespec)); timespec.it_value.tv_sec = msgp->interval; - timespec.it_value.tv_nsec = 0; timespec.it_interval.tv_sec = msgp->interval; - timespec.it_interval.tv_nsec = 0; if (timer_create (CLOCK_REALTIME, NULL, &timerid)) do_error(_("progress_rpt: cannot create timer\n")); -- 2.5.1 From bfoster@redhat.com Wed Sep 30 06:47:39 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 2A0C97F37 for ; Wed, 30 Sep 2015 06:47:39 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 1C7CF8F8050 for ; Wed, 30 Sep 2015 04:47:38 -0700 (PDT) X-ASG-Debug-ID: 1443613656-04cbb033b118e060001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Q4bWn9RxwBjh8h8f (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 30 Sep 2015 04:47:37 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 158BC8CF76; Wed, 30 Sep 2015 11:47:36 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8UBlZI6025061; Wed, 30 Sep 2015 07:47:35 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id 6B4CD1202D2; Wed, 30 Sep 2015 07:47:34 -0400 (EDT) Date: Wed, 30 Sep 2015 07:47:34 -0400 From: Brian Foster To: Eric Sandeen Cc: fstests , xfs@oss.sgi.com Subject: Re: [PATCH] test extending sub-block AIO writes for races Message-ID: <20150930114733.GB62991@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH] test extending sub-block AIO writes for races References: <560B34E3.4080107@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560B34E3.4080107@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443613656 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Tue, Sep 29, 2015 at 08:03:31PM -0500, Eric Sandeen wrote: > This tests bfoster's > [PATCH 1/2] xfs: always drain dio before extending aio write submission > patch; it launches four adjacent 1k IOs past EOF, then reads back > to see if we have 4k worth of the data we wrote, or something else - > possibly zeros from sub-block zeroing and eof racing. > > Signed-off-by: Eric Sandeen > --- > Thanks for the test! A few high level comments... > > diff --git a/src/aio-dio-regress/aio-dio-eof-race.c b/src/aio-dio-regress/aio-dio-eof-race.c > new file mode 100644 > index 0000000..c1ce695 > --- /dev/null > +++ b/src/aio-dio-regress/aio-dio-eof-race.c > @@ -0,0 +1,170 @@ > +/* > + * Launch 4 file-extending extending sub-block AIOs and ensure that we > + * don't see data corruption when they're all complete. > + * It might be good to point out that this stresses EOF zeroing, which also means a key point is not just file-extending I/O, but file-extending I/O beyond current EOF (e.g., I/O that creates holes between the current EOF and start of the new I/O). > + * Copyright (C) 2015 Red Hat, Inc. All Rights reserved. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define BUF_SIZE 4096 Have you considered making the buffer size variable? As is currently written, I don't think this will reproduce the problem on 512b or 1024b fsb filesystems because at least some of the file-extending I/Os must not be block aligned for it to trigger. > +#define IO_PATTERN 0xab > + > +void > +dump_buffer( > + void *buf, > + off64_t offset, > + ssize_t len) > +{ > + int i, j; > + char *p; > + int new; > + > + for (i = 0, p = (char *)buf; i < len; i += 16) { > + char *s = p; > + > + if (i && !memcmp(p, p - 16, 16)) { > + new = 0; > + } else { > + if (i) > + printf("*\n"); > + new = 1; > + } > + > + if (!new) { > + p += 16; > + continue; > + } > + > + printf("%08llx ", (unsigned long long)offset + i); > + for (j = 0; j < 16 && i + j < len; j++, p++) > + printf("%02x ", *p); > + printf(" "); > + for (j = 0; j < 16 && i + j < len; j++, s++) { > + if (isalnum((int)*s)) > + printf("%c", *s); > + else > + printf("."); > + } > + printf("\n"); > + > + } > + printf("%08llx\n", (unsigned long long)offset + i); > +} > + > +int main(int argc, char *argv[]) > +{ > + struct io_context *ctx = NULL; > + struct io_event evs[4]; > + struct iocb iocb1, iocb2, iocb3, iocb4; > + struct iocb *iocbs[] = { &iocb1, &iocb2, &iocb3, &iocb4 }; > + void *buf; > + struct stat statbuf; > + char cmp_buf[BUF_SIZE]; > + int fd, err = 0; > + off_t eof; > + > + fd = open(argv[1], O_DIRECT | O_CREAT | O_TRUNC | O_RDWR, 0600); > + if (fd == -1) { > + perror("open"); > + return 1; > + } > + > + err = posix_memalign(&buf, BUF_SIZE, BUF_SIZE); The alignment should technically be PAGE_SIZE (even though BUF_SIZE == 4096), right? > + if (err) { > + fprintf(stderr, "error %s during %s\n", > + strerror(err), > + "posix_memalign"); > + return 1; > + } > + memset(cmp_buf, IO_PATTERN, BUF_SIZE); > + > + err = io_setup(4, &ctx); > + if (err) { > + fprintf(stderr, "error %s during %s\n", > + strerror(err), > + "io_setup"); > + return 1; > + } > + > + eof = 0; > + > + /* Keep extending until 8MB */ > + while (eof < 8 * 1024 * 1024) { > + memset(buf, IO_PATTERN, BUF_SIZE); > + > + fstat(fd, &statbuf); > + eof = statbuf.st_size; > + > + /* > + * 4 ios, racing to extend EOF, combined they write full BUF_SIZE > + */ I would expand on this comment with something like the following: "Split the buffer into multiple I/Os to send a mix of block aligned/unaligned writes as well as writes that start beyond the current EOF. This stresses things like inode size management and stale block zeroing for races and can lead to data corruption when not handled properly." ... but feel free to reword that as necessary. I just wanted to point out that 1.) unaligned I/O is required and 2.) write offsets beyond EOF are required. > + io_prep_pwrite(&iocb1, fd, buf, BUF_SIZE/4, eof + 0 * BUF_SIZE/4); > + io_prep_pwrite(&iocb2, fd, buf, BUF_SIZE/4, eof + 1 * BUF_SIZE/4); > + io_prep_pwrite(&iocb3, fd, buf, BUF_SIZE/4, eof + 2 * BUF_SIZE/4); > + io_prep_pwrite(&iocb4, fd, buf, BUF_SIZE/4, eof + 3 * BUF_SIZE/4); > + > + err = io_submit(ctx, 4, iocbs); > + if (err != 4) { > + fprintf(stderr, "error %s during %s\n", > + strerror(err), > + "io_submit"); > + return 1; > + } > + > + err = io_getevents(ctx, 4, 4, evs, NULL); > + if (err != 4) { > + fprintf(stderr, "error %s during %s\n", > + strerror(err), > + "io_getevents"); > + return 1; > + } > + > + /* > + * And then read it back. > + * > + * Using pread to keep it simple, but AIO has the same effect. > + * > + * eof is the old eof, we just wrote BUF_SIZE more > + */ > + if (pread(fd, buf, BUF_SIZE, eof) != BUF_SIZE) { > + perror("pread"); > + return 1; > + } > + > + /* > + * We launched 4 AIOs which, stiched together, should write Nit: stitched > + * a seamless BUF_SIZE worth of IO_PATTERN to the last block > + */ > + if (memcmp(buf, cmp_buf, BUF_SIZE)) { > + printf("corruption while extending from %ld\n", eof); > + dump_buffer(buf, 0, BUF_SIZE); > + return 1; > + } > + } > + > + printf("Success, all done.\n"); > + return 0; > +} > diff --git a/tests/generic/326 b/tests/generic/326 > new file mode 100755 > index 0000000..7db04ac > --- /dev/null > +++ b/tests/generic/326 > @@ -0,0 +1,64 @@ > +#! /bin/bash > +# FS QA Test No. 326 > +# > +# Test races while extending past EOF via sub-block AIO writes > +# > +#----------------------------------------------------------------------- > +# Copyright (c) 2015 Red Hat, Inc. All Rights Reserved. > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation. > +# > +# This program is distributed in the hope that it would be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write the Free Software Foundation, > +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > +#----------------------------------------------------------------------- > +# > + > +seq=`basename $0` > +seqres=$RESULT_DIR/$seq > +echo "QA output created by $seq" > + > +here=`pwd` > +tmp=/tmp/$$ > +status=1 # failure is the default! > +trap "_cleanup; exit \$status" 0 1 2 3 15 > + > +_cleanup() > +{ > + cd / > + rm -f $TEST_DIR/tst-aio-dio-eof-race > +} > + > +# get standard environment, filters and checks > +. ./common/rc > +. ./common/filter > + > +_supported_fs generic > +_supported_os Linux > + > +_require_test > +_require_sparse_files > +_require_aiodio aio-dio-eof-race > + > +# Test does 512 byte DIO, so make sure that'll work > +logical_block_size=`_min_dio_alignment $TEST_DEV` > + > +if [ "$logical_block_size" -gt "512" ]; then > + _notrun "device block size: $logical_block_size greater than 512" > +fi > + Technically the test splits a 4k buffer into four parts and so sends 1k dio. Not that it really matters here, but I guess I'd update the comments. :) > +# If 512 isn't a sub-block IO, the test should still pass, so > +# let that go. > + Ok, so this at least points out the limitation to the test. I think it would be slightly better if the test were configurable as mentioned in the first comment above. For example, the test program could take a block size parameter and "do the right thing" based on that. Alternatively, we could specify buffer size and iocb count as parameters and let the xfstests script send the right params based on the test fs. I guess the latter would complicate things slightly because the program probably wants to ensure full buffers are written in each io_submit() instance for verification purposes. Just some thoughts... we could leave it as is too. In that case I would suggest to expand the comment above to be specific about which block sizes (512b, 1k) do not result in unaligned I/O. Brian > +# This test does several extending loops internally > +$AIO_TEST $TEST_DIR/tst-aio-dio-eof-race > + > +status=$? > +exit > diff --git a/tests/generic/326.out b/tests/generic/326.out > new file mode 100644 > index 0000000..22a3e78 > --- /dev/null > +++ b/tests/generic/326.out > @@ -0,0 +1,2 @@ > +QA output created by 326 > +Success, all done. > diff --git a/tests/generic/group b/tests/generic/group > index 4ae256f..a5f3008 100644 > --- a/tests/generic/group > +++ b/tests/generic/group > @@ -207,3 +207,4 @@ > 323 auto aio stress > 324 auto fsr quick > 325 auto quick data log > +326 auto quick aio > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Wed Sep 30 07:53:47 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 0DFC47F37 for ; Wed, 30 Sep 2015 07:53:47 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 034978F804B for ; Wed, 30 Sep 2015 05:53:43 -0700 (PDT) X-ASG-Debug-ID: 1443617620-04cbb033b118f730001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id 6JlXE35KmAt3pdkb for ; Wed, 30 Sep 2015 05:53:40 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id CF14463C77A5; Wed, 30 Sep 2015 07:53:39 -0500 (CDT) Subject: Re: [PATCH] test extending sub-block AIO writes for races To: Brian Foster X-ASG-Orig-Subj: Re: [PATCH] test extending sub-block AIO writes for races References: <560B34E3.4080107@sandeen.net> <20150930114733.GB62991@bfoster.bfoster> Cc: fstests , xfs@oss.sgi.com From: Eric Sandeen Message-ID: <560BDB53.6030303@sandeen.net> Date: Wed, 30 Sep 2015 07:53:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150930114733.GB62991@bfoster.bfoster> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1443617620 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.23043 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 9/30/15 6:47 AM, Brian Foster wrote: > On Tue, Sep 29, 2015 at 08:03:31PM -0500, Eric Sandeen wrote: >> This tests bfoster's >> [PATCH 1/2] xfs: always drain dio before extending aio write submission >> patch; it launches four adjacent 1k IOs past EOF, then reads back >> to see if we have 4k worth of the data we wrote, or something else - >> possibly zeros from sub-block zeroing and eof racing. >> >> Signed-off-by: Eric Sandeen >> --- >> > > Thanks for the test! A few high level comments... > >> >> diff --git a/src/aio-dio-regress/aio-dio-eof-race.c b/src/aio-dio-regress/aio-dio-eof-race.c >> new file mode 100644 >> index 0000000..c1ce695 >> --- /dev/null >> +++ b/src/aio-dio-regress/aio-dio-eof-race.c >> @@ -0,0 +1,170 @@ >> +/* >> + * Launch 4 file-extending extending sub-block AIOs and ensure that we >> + * don't see data corruption when they're all complete. >> + * > > It might be good to point out that this stresses EOF zeroing, which also > means a key point is not just file-extending I/O, but file-extending I/O > beyond current EOF (e.g., I/O that creates holes between the current EOF > and start of the new I/O). yeah, ok, good to be specific. >> + * Copyright (C) 2015 Red Hat, Inc. All Rights reserved. >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License as published by >> + * the Free Software Foundation; either version 2 of the License, or >> + * (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. >> + */ >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> + >> +#define BUF_SIZE 4096 > > Have you considered making the buffer size variable? As is currently > written, I don't think this will reproduce the problem on 512b or 1024b > fsb filesystems because at least some of the file-extending I/Os must > not be block aligned for it to trigger. yeah, I meant to make it smaller, then got distracted, tbh ; But I think launching 4x512 IOs should always do the trick, right? And it's impossible to repro on a 512b fs block I think, because we can't have any sub-block/unaligned IOs? So I think that perhaps switching it to 2048 & doing 4x512 IOs would suffice, right? >> +#define IO_PATTERN 0xab >> + >> +void >> +dump_buffer( >> + void *buf, >> + off64_t offset, >> + ssize_t len) >> +{ >> + int i, j; >> + char *p; >> + int new; >> + >> + for (i = 0, p = (char *)buf; i < len; i += 16) { >> + char *s = p; >> + >> + if (i && !memcmp(p, p - 16, 16)) { >> + new = 0; >> + } else { >> + if (i) >> + printf("*\n"); >> + new = 1; >> + } >> + >> + if (!new) { >> + p += 16; >> + continue; >> + } >> + >> + printf("%08llx ", (unsigned long long)offset + i); >> + for (j = 0; j < 16 && i + j < len; j++, p++) >> + printf("%02x ", *p); >> + printf(" "); >> + for (j = 0; j < 16 && i + j < len; j++, s++) { >> + if (isalnum((int)*s)) >> + printf("%c", *s); >> + else >> + printf("."); >> + } >> + printf("\n"); >> + >> + } >> + printf("%08llx\n", (unsigned long long)offset + i); >> +} >> + >> +int main(int argc, char *argv[]) >> +{ >> + struct io_context *ctx = NULL; >> + struct io_event evs[4]; >> + struct iocb iocb1, iocb2, iocb3, iocb4; >> + struct iocb *iocbs[] = { &iocb1, &iocb2, &iocb3, &iocb4 }; >> + void *buf; >> + struct stat statbuf; >> + char cmp_buf[BUF_SIZE]; >> + int fd, err = 0; >> + off_t eof; >> + >> + fd = open(argv[1], O_DIRECT | O_CREAT | O_TRUNC | O_RDWR, 0600); >> + if (fd == -1) { >> + perror("open"); >> + return 1; >> + } >> + >> + err = posix_memalign(&buf, BUF_SIZE, BUF_SIZE); > > The alignment should technically be PAGE_SIZE (even though BUF_SIZE == > 4096), right? hm, tbh this just came along from the other AIO tests I copied from ;) Sure, I can do it page-sized, that'd be better. >> + if (err) { >> + fprintf(stderr, "error %s during %s\n", >> + strerror(err), >> + "posix_memalign"); >> + return 1; >> + } >> + memset(cmp_buf, IO_PATTERN, BUF_SIZE); >> + >> + err = io_setup(4, &ctx); >> + if (err) { >> + fprintf(stderr, "error %s during %s\n", >> + strerror(err), >> + "io_setup"); >> + return 1; >> + } >> + >> + eof = 0; >> + >> + /* Keep extending until 8MB */ >> + while (eof < 8 * 1024 * 1024) { >> + memset(buf, IO_PATTERN, BUF_SIZE); >> + >> + fstat(fd, &statbuf); >> + eof = statbuf.st_size; >> + >> + /* >> + * 4 ios, racing to extend EOF, combined they write full BUF_SIZE >> + */ > > I would expand on this comment with something like the following: > > "Split the buffer into multiple I/Os to send a mix of block > aligned/unaligned writes as well as writes that start beyond the current > EOF. This stresses things like inode size management and stale block > zeroing for races and can lead to data corruption when not handled > properly." > > ... but feel free to reword that as necessary. I just wanted to point > out that 1.) unaligned I/O is required and 2.) write offsets beyond EOF > are required. ok >> + io_prep_pwrite(&iocb1, fd, buf, BUF_SIZE/4, eof + 0 * BUF_SIZE/4); >> + io_prep_pwrite(&iocb2, fd, buf, BUF_SIZE/4, eof + 1 * BUF_SIZE/4); >> + io_prep_pwrite(&iocb3, fd, buf, BUF_SIZE/4, eof + 2 * BUF_SIZE/4); >> + io_prep_pwrite(&iocb4, fd, buf, BUF_SIZE/4, eof + 3 * BUF_SIZE/4); >> + >> + err = io_submit(ctx, 4, iocbs); >> + if (err != 4) { >> + fprintf(stderr, "error %s during %s\n", >> + strerror(err), >> + "io_submit"); >> + return 1; >> + } >> + >> + err = io_getevents(ctx, 4, 4, evs, NULL); >> + if (err != 4) { >> + fprintf(stderr, "error %s during %s\n", >> + strerror(err), >> + "io_getevents"); >> + return 1; >> + } >> + >> + /* >> + * And then read it back. >> + * >> + * Using pread to keep it simple, but AIO has the same effect. >> + * >> + * eof is the old eof, we just wrote BUF_SIZE more >> + */ >> + if (pread(fd, buf, BUF_SIZE, eof) != BUF_SIZE) { >> + perror("pread"); >> + return 1; >> + } >> + >> + /* >> + * We launched 4 AIOs which, stiched together, should write > > Nit: stitched doh ;) >> + * a seamless BUF_SIZE worth of IO_PATTERN to the last block >> + */ >> + if (memcmp(buf, cmp_buf, BUF_SIZE)) { >> + printf("corruption while extending from %ld\n", eof); >> + dump_buffer(buf, 0, BUF_SIZE); >> + return 1; >> + } >> + } >> + >> + printf("Success, all done.\n"); >> + return 0; >> +} >> diff --git a/tests/generic/326 b/tests/generic/326 >> new file mode 100755 >> index 0000000..7db04ac >> --- /dev/null >> +++ b/tests/generic/326 >> @@ -0,0 +1,64 @@ >> +#! /bin/bash >> +# FS QA Test No. 326 >> +# >> +# Test races while extending past EOF via sub-block AIO writes >> +# >> +#----------------------------------------------------------------------- >> +# Copyright (c) 2015 Red Hat, Inc. All Rights Reserved. >> +# >> +# This program is free software; you can redistribute it and/or >> +# modify it under the terms of the GNU General Public License as >> +# published by the Free Software Foundation. >> +# >> +# This program is distributed in the hope that it would be useful, >> +# but WITHOUT ANY WARRANTY; without even the implied warranty of >> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> +# GNU General Public License for more details. >> +# >> +# You should have received a copy of the GNU General Public License >> +# along with this program; if not, write the Free Software Foundation, >> +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA >> +#----------------------------------------------------------------------- >> +# >> + >> +seq=`basename $0` >> +seqres=$RESULT_DIR/$seq >> +echo "QA output created by $seq" >> + >> +here=`pwd` >> +tmp=/tmp/$$ >> +status=1 # failure is the default! >> +trap "_cleanup; exit \$status" 0 1 2 3 15 >> + >> +_cleanup() >> +{ >> + cd / >> + rm -f $TEST_DIR/tst-aio-dio-eof-race >> +} >> + >> +# get standard environment, filters and checks >> +. ./common/rc >> +. ./common/filter >> + >> +_supported_fs generic >> +_supported_os Linux >> + >> +_require_test >> +_require_sparse_files >> +_require_aiodio aio-dio-eof-race >> + >> +# Test does 512 byte DIO, so make sure that'll work >> +logical_block_size=`_min_dio_alignment $TEST_DEV` >> + >> +if [ "$logical_block_size" -gt "512" ]; then >> + _notrun "device block size: $logical_block_size greater than 512" >> +fi >> + > > Technically the test splits a 4k buffer into four parts and so sends 1k > dio. Not that it really matters here, but I guess I'd update the > comments. :) > >> +# If 512 isn't a sub-block IO, the test should still pass, so >> +# let that go. >> + > > Ok, so this at least points out the limitation to the test. I think it > would be slightly better if the test were configurable as mentioned in > the first comment above. For example, the test program could take a > block size parameter and "do the right thing" based on that. > Alternatively, we could specify buffer size and iocb count as parameters > and let the xfstests script send the right params based on the test fs. > I guess the latter would complicate things slightly because the program > probably wants to ensure full buffers are written in each io_submit() > instance for verification purposes. > > Just some thoughts... we could leave it as is too. In that case I would > suggest to expand the comment above to be specific about which block > sizes (512b, 1k) do not result in unaligned I/O. ok, I'll make it a bit more universal one way or the other. Thanks for the review, -Eric > Brian > >> +# This test does several extending loops internally >> +$AIO_TEST $TEST_DIR/tst-aio-dio-eof-race >> + >> +status=$? >> +exit >> diff --git a/tests/generic/326.out b/tests/generic/326.out >> new file mode 100644 >> index 0000000..22a3e78 >> --- /dev/null >> +++ b/tests/generic/326.out >> @@ -0,0 +1,2 @@ >> +QA output created by 326 >> +Success, all done. >> diff --git a/tests/generic/group b/tests/generic/group >> index 4ae256f..a5f3008 100644 >> --- a/tests/generic/group >> +++ b/tests/generic/group >> @@ -207,3 +207,4 @@ >> 323 auto aio stress >> 324 auto fsr quick >> 325 auto quick data log >> +326 auto quick aio >> >> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs > From bfoster@redhat.com Wed Sep 30 10:24:58 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 1C59E7F37 for ; Wed, 30 Sep 2015 10:24:58 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 68745AC002 for ; Wed, 30 Sep 2015 08:24:57 -0700 (PDT) X-ASG-Debug-ID: 1443626694-04cbb033b0194310001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id AxkQg8cPS5LFKr8X (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 30 Sep 2015 08:24:54 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id EF7CB91E97; Wed, 30 Sep 2015 15:24:53 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8UFOqPG020139; Wed, 30 Sep 2015 11:24:53 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id D7D3A1202D2; Wed, 30 Sep 2015 11:24:51 -0400 (EDT) Date: Wed, 30 Sep 2015 11:24:51 -0400 From: Brian Foster To: Eric Sandeen Cc: fstests , xfs@oss.sgi.com Subject: Re: [PATCH] test extending sub-block AIO writes for races Message-ID: <20150930152451.GA16725@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH] test extending sub-block AIO writes for races References: <560B34E3.4080107@sandeen.net> <20150930114733.GB62991@bfoster.bfoster> <560BDB53.6030303@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560BDB53.6030303@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443626694 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 30, 2015 at 07:53:39AM -0500, Eric Sandeen wrote: > > > On 9/30/15 6:47 AM, Brian Foster wrote: > > On Tue, Sep 29, 2015 at 08:03:31PM -0500, Eric Sandeen wrote: > >> This tests bfoster's > >> [PATCH 1/2] xfs: always drain dio before extending aio write submission > >> patch; it launches four adjacent 1k IOs past EOF, then reads back > >> to see if we have 4k worth of the data we wrote, or something else - > >> possibly zeros from sub-block zeroing and eof racing. > >> > >> Signed-off-by: Eric Sandeen > >> --- > >> > > > > Thanks for the test! A few high level comments... > > > >> > >> diff --git a/src/aio-dio-regress/aio-dio-eof-race.c b/src/aio-dio-regress/aio-dio-eof-race.c > >> new file mode 100644 > >> index 0000000..c1ce695 > >> --- /dev/null > >> +++ b/src/aio-dio-regress/aio-dio-eof-race.c > >> @@ -0,0 +1,170 @@ > >> +/* > >> + * Launch 4 file-extending extending sub-block AIOs and ensure that we > >> + * don't see data corruption when they're all complete. > >> + * > > > > It might be good to point out that this stresses EOF zeroing, which also > > means a key point is not just file-extending I/O, but file-extending I/O > > beyond current EOF (e.g., I/O that creates holes between the current EOF > > and start of the new I/O). > > yeah, ok, good to be specific. > > >> + * Copyright (C) 2015 Red Hat, Inc. All Rights reserved. > >> + * > >> + * This program is free software; you can redistribute it and/or modify > >> + * it under the terms of the GNU General Public License as published by > >> + * the Free Software Foundation; either version 2 of the License, or > >> + * (at your option) any later version. > >> + * > >> + * This program is distributed in the hope that it will be useful, > >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of > >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >> + * GNU General Public License for more details. > >> + * > >> + * You should have received a copy of the GNU General Public License > >> + * along with this program; if not, write to the Free Software > >> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. > >> + */ > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> + > >> +#include > >> + > >> +#define BUF_SIZE 4096 > > > > Have you considered making the buffer size variable? As is currently > > written, I don't think this will reproduce the problem on 512b or 1024b > > fsb filesystems because at least some of the file-extending I/Os must > > not be block aligned for it to trigger. > > yeah, I meant to make it smaller, then got distracted, tbh ; > > But I think launching 4x512 IOs should always do the trick, right? > I would think so, though I don't know how many unaligned I/Os were necessary per io_submit() to make the test effective (e.g., 3 of 4 on 4k/2k fsb vs. 2 of 4 on 1k fsb). Might be worth a try to be sure. > And it's impossible to repro on a 512b fs block I think, because > we can't have any sub-block/unaligned IOs? > > So I think that perhaps switching it to 2048 & doing 4x512 IOs > would suffice, right? > Yeah, good point. I don't think this reproducer could trigger the problem with 512b FSBs. I think the corruption is still possible on such fs', but it would probably require extending I/O to a file with dirty pages and post-eof speculative preallocation. In short, I think that's probably a separate reproducer. Given that and if the above is effective, perhaps it's good enough to adjust the default buffer size and whatnot and forget the tunables and things. Brian > >> +#define IO_PATTERN 0xab > >> + > >> +void > >> +dump_buffer( > >> + void *buf, > >> + off64_t offset, > >> + ssize_t len) > >> +{ > >> + int i, j; > >> + char *p; > >> + int new; > >> + > >> + for (i = 0, p = (char *)buf; i < len; i += 16) { > >> + char *s = p; > >> + > >> + if (i && !memcmp(p, p - 16, 16)) { > >> + new = 0; > >> + } else { > >> + if (i) > >> + printf("*\n"); > >> + new = 1; > >> + } > >> + > >> + if (!new) { > >> + p += 16; > >> + continue; > >> + } > >> + > >> + printf("%08llx ", (unsigned long long)offset + i); > >> + for (j = 0; j < 16 && i + j < len; j++, p++) > >> + printf("%02x ", *p); > >> + printf(" "); > >> + for (j = 0; j < 16 && i + j < len; j++, s++) { > >> + if (isalnum((int)*s)) > >> + printf("%c", *s); > >> + else > >> + printf("."); > >> + } > >> + printf("\n"); > >> + > >> + } > >> + printf("%08llx\n", (unsigned long long)offset + i); > >> +} > >> + > >> +int main(int argc, char *argv[]) > >> +{ > >> + struct io_context *ctx = NULL; > >> + struct io_event evs[4]; > >> + struct iocb iocb1, iocb2, iocb3, iocb4; > >> + struct iocb *iocbs[] = { &iocb1, &iocb2, &iocb3, &iocb4 }; > >> + void *buf; > >> + struct stat statbuf; > >> + char cmp_buf[BUF_SIZE]; > >> + int fd, err = 0; > >> + off_t eof; > >> + > >> + fd = open(argv[1], O_DIRECT | O_CREAT | O_TRUNC | O_RDWR, 0600); > >> + if (fd == -1) { > >> + perror("open"); > >> + return 1; > >> + } > >> + > >> + err = posix_memalign(&buf, BUF_SIZE, BUF_SIZE); > > > > The alignment should technically be PAGE_SIZE (even though BUF_SIZE == > > 4096), right? > > hm, tbh this just came along from the other AIO tests I copied from ;) > Sure, I can do it page-sized, that'd be better. > > >> + if (err) { > >> + fprintf(stderr, "error %s during %s\n", > >> + strerror(err), > >> + "posix_memalign"); > >> + return 1; > >> + } > >> + memset(cmp_buf, IO_PATTERN, BUF_SIZE); > >> + > >> + err = io_setup(4, &ctx); > >> + if (err) { > >> + fprintf(stderr, "error %s during %s\n", > >> + strerror(err), > >> + "io_setup"); > >> + return 1; > >> + } > >> + > >> + eof = 0; > >> + > >> + /* Keep extending until 8MB */ > >> + while (eof < 8 * 1024 * 1024) { > >> + memset(buf, IO_PATTERN, BUF_SIZE); > >> + > >> + fstat(fd, &statbuf); > >> + eof = statbuf.st_size; > >> + > >> + /* > >> + * 4 ios, racing to extend EOF, combined they write full BUF_SIZE > >> + */ > > > > I would expand on this comment with something like the following: > > > > "Split the buffer into multiple I/Os to send a mix of block > > aligned/unaligned writes as well as writes that start beyond the current > > EOF. This stresses things like inode size management and stale block > > zeroing for races and can lead to data corruption when not handled > > properly." > > > > ... but feel free to reword that as necessary. I just wanted to point > > out that 1.) unaligned I/O is required and 2.) write offsets beyond EOF > > are required. > > ok > > > >> + io_prep_pwrite(&iocb1, fd, buf, BUF_SIZE/4, eof + 0 * BUF_SIZE/4); > >> + io_prep_pwrite(&iocb2, fd, buf, BUF_SIZE/4, eof + 1 * BUF_SIZE/4); > >> + io_prep_pwrite(&iocb3, fd, buf, BUF_SIZE/4, eof + 2 * BUF_SIZE/4); > >> + io_prep_pwrite(&iocb4, fd, buf, BUF_SIZE/4, eof + 3 * BUF_SIZE/4); > >> + > >> + err = io_submit(ctx, 4, iocbs); > >> + if (err != 4) { > >> + fprintf(stderr, "error %s during %s\n", > >> + strerror(err), > >> + "io_submit"); > >> + return 1; > >> + } > >> + > >> + err = io_getevents(ctx, 4, 4, evs, NULL); > >> + if (err != 4) { > >> + fprintf(stderr, "error %s during %s\n", > >> + strerror(err), > >> + "io_getevents"); > >> + return 1; > >> + } > >> + > >> + /* > >> + * And then read it back. > >> + * > >> + * Using pread to keep it simple, but AIO has the same effect. > >> + * > >> + * eof is the old eof, we just wrote BUF_SIZE more > >> + */ > >> + if (pread(fd, buf, BUF_SIZE, eof) != BUF_SIZE) { > >> + perror("pread"); > >> + return 1; > >> + } > >> + > >> + /* > >> + * We launched 4 AIOs which, stiched together, should write > > > > Nit: stitched > > doh ;) > > >> + * a seamless BUF_SIZE worth of IO_PATTERN to the last block > >> + */ > >> + if (memcmp(buf, cmp_buf, BUF_SIZE)) { > >> + printf("corruption while extending from %ld\n", eof); > >> + dump_buffer(buf, 0, BUF_SIZE); > >> + return 1; > >> + } > >> + } > >> + > >> + printf("Success, all done.\n"); > >> + return 0; > >> +} > >> diff --git a/tests/generic/326 b/tests/generic/326 > >> new file mode 100755 > >> index 0000000..7db04ac > >> --- /dev/null > >> +++ b/tests/generic/326 > >> @@ -0,0 +1,64 @@ > >> +#! /bin/bash > >> +# FS QA Test No. 326 > >> +# > >> +# Test races while extending past EOF via sub-block AIO writes > >> +# > >> +#----------------------------------------------------------------------- > >> +# Copyright (c) 2015 Red Hat, Inc. All Rights Reserved. > >> +# > >> +# This program is free software; you can redistribute it and/or > >> +# modify it under the terms of the GNU General Public License as > >> +# published by the Free Software Foundation. > >> +# > >> +# This program is distributed in the hope that it would be useful, > >> +# but WITHOUT ANY WARRANTY; without even the implied warranty of > >> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >> +# GNU General Public License for more details. > >> +# > >> +# You should have received a copy of the GNU General Public License > >> +# along with this program; if not, write the Free Software Foundation, > >> +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > >> +#----------------------------------------------------------------------- > >> +# > >> + > >> +seq=`basename $0` > >> +seqres=$RESULT_DIR/$seq > >> +echo "QA output created by $seq" > >> + > >> +here=`pwd` > >> +tmp=/tmp/$$ > >> +status=1 # failure is the default! > >> +trap "_cleanup; exit \$status" 0 1 2 3 15 > >> + > >> +_cleanup() > >> +{ > >> + cd / > >> + rm -f $TEST_DIR/tst-aio-dio-eof-race > >> +} > >> + > >> +# get standard environment, filters and checks > >> +. ./common/rc > >> +. ./common/filter > >> + > >> +_supported_fs generic > >> +_supported_os Linux > >> + > >> +_require_test > >> +_require_sparse_files > >> +_require_aiodio aio-dio-eof-race > >> + > >> +# Test does 512 byte DIO, so make sure that'll work > >> +logical_block_size=`_min_dio_alignment $TEST_DEV` > >> + > >> +if [ "$logical_block_size" -gt "512" ]; then > >> + _notrun "device block size: $logical_block_size greater than 512" > >> +fi > >> + > > > > Technically the test splits a 4k buffer into four parts and so sends 1k > > dio. Not that it really matters here, but I guess I'd update the > > comments. :) > > > >> +# If 512 isn't a sub-block IO, the test should still pass, so > >> +# let that go. > >> + > > > > Ok, so this at least points out the limitation to the test. I think it > > would be slightly better if the test were configurable as mentioned in > > the first comment above. For example, the test program could take a > > block size parameter and "do the right thing" based on that. > > Alternatively, we could specify buffer size and iocb count as parameters > > and let the xfstests script send the right params based on the test fs. > > I guess the latter would complicate things slightly because the program > > probably wants to ensure full buffers are written in each io_submit() > > instance for verification purposes. > > > > Just some thoughts... we could leave it as is too. In that case I would > > suggest to expand the comment above to be specific about which block > > sizes (512b, 1k) do not result in unaligned I/O. > > ok, I'll make it a bit more universal one way or the other. > > Thanks for the review, > -Eric > > > Brian > > > >> +# This test does several extending loops internally > >> +$AIO_TEST $TEST_DIR/tst-aio-dio-eof-race > >> + > >> +status=$? > >> +exit > >> diff --git a/tests/generic/326.out b/tests/generic/326.out > >> new file mode 100644 > >> index 0000000..22a3e78 > >> --- /dev/null > >> +++ b/tests/generic/326.out > >> @@ -0,0 +1,2 @@ > >> +QA output created by 326 > >> +Success, all done. > >> diff --git a/tests/generic/group b/tests/generic/group > >> index 4ae256f..a5f3008 100644 > >> --- a/tests/generic/group > >> +++ b/tests/generic/group > >> @@ -207,3 +207,4 @@ > >> 323 auto aio stress > >> 324 auto fsr quick > >> 325 auto quick data log > >> +326 auto quick aio > >> > >> > >> _______________________________________________ > >> xfs mailing list > >> xfs@oss.sgi.com > >> http://oss.sgi.com/mailman/listinfo/xfs > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Wed Sep 30 10:59:35 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id AFAA67F37 for ; Wed, 30 Sep 2015 10:59:35 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 8B7B38F8078 for ; Wed, 30 Sep 2015 08:59:35 -0700 (PDT) X-ASG-Debug-ID: 1443628772-04cbb033b3195320001-NocioJ Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id sOComY3KWUv6Eqpq for ; Wed, 30 Sep 2015 08:59:32 -0700 (PDT) X-Barracuda-Envelope-From: sandeen@sandeen.net X-Barracuda-Apparent-Source-IP: 63.231.237.45 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 338CB63C77A5; Wed, 30 Sep 2015 10:59:32 -0500 (CDT) Subject: [PATCH V2] test extending sub-block AIO writes for races To: fstests X-ASG-Orig-Subj: [PATCH V2] test extending sub-block AIO writes for races References: <560B34E3.4080107@sandeen.net> Cc: xfs@oss.sgi.com From: Eric Sandeen Message-ID: <560C06E3.4090708@sandeen.net> Date: Wed, 30 Sep 2015 10:59:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560B34E3.4080107@sandeen.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[63.231.237.45] X-Barracuda-Start-Time: 1443628772 X-Barracuda-URL: https://192.48.176.25:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.23046 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- This tests bfoster's [PATCH 1/2] xfs: always drain dio before extending aio write submission patch; it launches four adjacent 1k IOs past EOF, then reads back to see if we have 4k worth of the data we wrote, or something else - possibly zeros from sub-block zeroing and eof racing. Signed-off-by: Eric Sandeen --- V2: do 4x512 IOs to get as much sub-block goodness as possible fix up comments & typos diff --git a/src/aio-dio-regress/aio-dio-eof-race.c b/src/aio-dio-regress/aio-dio-eof-race.c new file mode 100644 index 0000000..ce5d715 --- /dev/null +++ b/src/aio-dio-regress/aio-dio-eof-race.c @@ -0,0 +1,173 @@ +/* + * Launch 4 sub-block AIOs past EOF and ensure that we don't see + * corruption from racing sub-block zeroing when they're complete. + * + * Copyright (C) 2015 Red Hat, Inc. All Rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +/* Sized to allow 4 x 512 AIOs */ +#define BUF_SIZE 2048 +#define IO_PATTERN 0xab + +void +dump_buffer( + void *buf, + off64_t offset, + ssize_t len) +{ + int i, j; + char *p; + int new; + + for (i = 0, p = (char *)buf; i < len; i += 16) { + char *s = p; + + if (i && !memcmp(p, p - 16, 16)) { + new = 0; + } else { + if (i) + printf("*\n"); + new = 1; + } + + if (!new) { + p += 16; + continue; + } + + printf("%08llx ", (unsigned long long)offset + i); + for (j = 0; j < 16 && i + j < len; j++, p++) + printf("%02x ", *p); + printf(" "); + for (j = 0; j < 16 && i + j < len; j++, s++) { + if (isalnum((int)*s)) + printf("%c", *s); + else + printf("."); + } + printf("\n"); + + } + printf("%08llx\n", (unsigned long long)offset + i); +} + +int main(int argc, char *argv[]) +{ + struct io_context *ctx = NULL; + struct io_event evs[4]; + struct iocb iocb1, iocb2, iocb3, iocb4; + struct iocb *iocbs[] = { &iocb1, &iocb2, &iocb3, &iocb4 }; + void *buf; + struct stat statbuf; + char cmp_buf[BUF_SIZE]; + int fd, err = 0; + off_t eof; + + fd = open(argv[1], O_DIRECT | O_CREAT | O_TRUNC | O_RDWR, 0600); + if (fd == -1) { + perror("open"); + return 1; + } + + err = posix_memalign(&buf, getpagesize(), BUF_SIZE); + if (err) { + fprintf(stderr, "error %s during %s\n", + strerror(err), + "posix_memalign"); + return 1; + } + memset(cmp_buf, IO_PATTERN, BUF_SIZE); + + err = io_setup(4, &ctx); + if (err) { + fprintf(stderr, "error %s during %s\n", + strerror(err), + "io_setup"); + return 1; + } + + eof = 0; + + /* Keep extending until 8MB (fairly arbitrary) */ + while (eof < 8 * 1024 * 1024) { + memset(buf, IO_PATTERN, BUF_SIZE); + fstat(fd, &statbuf); + eof = statbuf.st_size; + + /* + * Split the buffer into multiple I/Os to send a mix of block + * aligned/unaligned writes as well as writes that start beyond + * the current EOF. This stresses things like inode size + * management and stale block zeroing for races and can lead to + * data corruption when not handled properly. + */ + io_prep_pwrite(&iocb1, fd, buf, BUF_SIZE/4, eof + 0*BUF_SIZE/4); + io_prep_pwrite(&iocb2, fd, buf, BUF_SIZE/4, eof + 1*BUF_SIZE/4); + io_prep_pwrite(&iocb3, fd, buf, BUF_SIZE/4, eof + 2*BUF_SIZE/4); + io_prep_pwrite(&iocb4, fd, buf, BUF_SIZE/4, eof + 3*BUF_SIZE/4); + + err = io_submit(ctx, 4, iocbs); + if (err != 4) { + fprintf(stderr, "error %s during %s\n", + strerror(err), + "io_submit"); + return 1; + } + + err = io_getevents(ctx, 4, 4, evs, NULL); + if (err != 4) { + fprintf(stderr, "error %s during %s\n", + strerror(err), + "io_getevents"); + return 1; + } + + /* + * And then read it back. + * + * Using pread to keep it simple, but AIO has the same effect. + * eof is the prior eof; we just wrote BUF_SIZE more. + */ + if (pread(fd, buf, BUF_SIZE, eof) != BUF_SIZE) { + perror("pread"); + return 1; + } + + /* + * We launched 4 AIOs which, stitched together, should write + * a seamless BUF_SIZE worth of IO_PATTERN to the last block. + */ + if (memcmp(buf, cmp_buf, BUF_SIZE)) { + printf("corruption while extending from %ld\n", eof); + dump_buffer(buf, 0, BUF_SIZE); + return 1; + } + } + + printf("Success, all done.\n"); + return 0; +} diff --git a/tests/generic/326 b/tests/generic/326 new file mode 100755 index 0000000..f20375a --- /dev/null +++ b/tests/generic/326 @@ -0,0 +1,65 @@ +#! /bin/bash +# FS QA Test No. 326 +# +# Test races while extending past EOF via sub-block AIO writes +# +#----------------------------------------------------------------------- +# Copyright (c) 2015 Red Hat, Inc. All Rights Reserved. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation. +# +# This program is distributed in the hope that it would be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write the Free Software Foundation, +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +#----------------------------------------------------------------------- +# + +seq=`basename $0` +seqres=$RESULT_DIR/$seq +echo "QA output created by $seq" + +here=`pwd` +tmp=/tmp/$$ +status=1 # failure is the default! +trap "_cleanup; exit \$status" 0 1 2 3 15 + +_cleanup() +{ + cd / + rm -f $TEST_DIR/tst-aio-dio-eof-race +} + +# get standard environment, filters and checks +. ./common/rc +. ./common/filter + +_supported_fs generic +_supported_os Linux + +_require_test +_require_sparse_files +_require_aiodio aio-dio-eof-race + +# Test does 512 byte DIO, so make sure that'll work +logical_block_size=`_min_dio_alignment $TEST_DEV` + +if [ "$logical_block_size" -gt "512" ]; then + _notrun "device block size: $logical_block_size greater than 512" +fi + +# We don't mind 512-byte fs blocks; the IOs won't be sub-block, +# but the test should still pass, even if it doesn't stress the code +# we're targeting. + +# Note, this test does several extending loops internally +$AIO_TEST $TEST_DIR/tst-aio-dio-eof-race + +status=$? +exit diff --git a/tests/generic/326.out b/tests/generic/326.out new file mode 100644 index 0000000..22a3e78 --- /dev/null +++ b/tests/generic/326.out @@ -0,0 +1,2 @@ +QA output created by 326 +Success, all done. diff --git a/tests/generic/group b/tests/generic/group index 4ae256f..a5f3008 100644 --- a/tests/generic/group +++ b/tests/generic/group @@ -207,3 +207,4 @@ 323 auto aio stress 324 auto fsr quick 325 auto quick data log +326 auto quick aio From bfoster@redhat.com Wed Sep 30 11:53:45 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: xfs@oss.sgi.com Delivered-To: xfs@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 1D2667F37 for ; Wed, 30 Sep 2015 11:53:45 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 0DE09304059 for ; Wed, 30 Sep 2015 09:53:41 -0700 (PDT) X-ASG-Debug-ID: 1443632019-04cb6c6b0416ac40001-NocioJ Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id IiUZxbMNopCnUfiP (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 30 Sep 2015 09:53:40 -0700 (PDT) X-Barracuda-Envelope-From: bfoster@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 6CE958C1B8; Wed, 30 Sep 2015 16:53:39 +0000 (UTC) Received: from bfoster.bfoster (dhcp-41-128.bos.redhat.com [10.18.41.128]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8UGrcdG017471; Wed, 30 Sep 2015 12:53:39 -0400 Received: by bfoster.bfoster (Postfix, from userid 1000) id A65FC1203DF; Wed, 30 Sep 2015 12:53:37 -0400 (EDT) Date: Wed, 30 Sep 2015 12:53:37 -0400 From: Brian Foster To: Eric Sandeen Cc: fstests , xfs@oss.sgi.com Subject: Re: [PATCH V2] test extending sub-block AIO writes for races Message-ID: <20150930165337.GB16725@bfoster.bfoster> X-ASG-Orig-Subj: Re: [PATCH V2] test extending sub-block AIO writes for races References: <560B34E3.4080107@sandeen.net> <560C06E3.4090708@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560C06E3.4090708@sandeen.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1443632020 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://192.48.176.15:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On Wed, Sep 30, 2015 at 10:59:31AM -0500, Eric Sandeen wrote: > This tests bfoster's > [PATCH 1/2] xfs: always drain dio before extending aio write submission > patch; it launches four adjacent 1k IOs past EOF, then reads back > to see if we have 4k worth of the data we wrote, or something else - > possibly zeros from sub-block zeroing and eof racing. > > Signed-off-by: Eric Sandeen > --- > > V2: > do 4x512 IOs to get as much sub-block goodness as possible > fix up comments & typos > > diff --git a/src/aio-dio-regress/aio-dio-eof-race.c b/src/aio-dio-regress/aio-dio-eof-race.c > new file mode 100644 > index 0000000..ce5d715 > --- /dev/null > +++ b/src/aio-dio-regress/aio-dio-eof-race.c > @@ -0,0 +1,173 @@ ... > +void > +dump_buffer( > + void *buf, > + off64_t offset, > + ssize_t len) > +{ > + int i, j; > + char *p; > + int new; > + Whitespace damage on the line above... > + for (i = 0, p = (char *)buf; i < len; i += 16) { > + char *s = p; > + ... > + > + } > + printf("%08llx\n", (unsigned long long)offset + i); > +} > + > +int main(int argc, char *argv[]) > +{ ... > + /* > + * Split the buffer into multiple I/Os to send a mix of block > + * aligned/unaligned writes as well as writes that start beyond > + * the current EOF. This stresses things like inode size > + * management and stale block zeroing for races and can lead to > + * data corruption when not handled properly. > + */ > + io_prep_pwrite(&iocb1, fd, buf, BUF_SIZE/4, eof + 0*BUF_SIZE/4); > + io_prep_pwrite(&iocb2, fd, buf, BUF_SIZE/4, eof + 1*BUF_SIZE/4); > + io_prep_pwrite(&iocb3, fd, buf, BUF_SIZE/4, eof + 2*BUF_SIZE/4); > + io_prep_pwrite(&iocb4, fd, buf, BUF_SIZE/4, eof + 3*BUF_SIZE/4); > + ... and above here as well. Otherwise looks good to me. Thanks again! Reviewed-by: Brian Foster > + err = io_submit(ctx, 4, iocbs); > + if (err != 4) { > + fprintf(stderr, "error %s during %s\n", > + strerror(err), > + "io_submit"); > + return 1; > + } > + > + err = io_getevents(ctx, 4, 4, evs, NULL); > + if (err != 4) { > + fprintf(stderr, "error %s during %s\n", > + strerror(err), > + "io_getevents"); > + return 1; > + } > + > + /* > + * And then read it back. > + * > + * Using pread to keep it simple, but AIO has the same effect. > + * eof is the prior eof; we just wrote BUF_SIZE more. > + */ > + if (pread(fd, buf, BUF_SIZE, eof) != BUF_SIZE) { > + perror("pread"); > + return 1; > + } > + > + /* > + * We launched 4 AIOs which, stitched together, should write > + * a seamless BUF_SIZE worth of IO_PATTERN to the last block. > + */ > + if (memcmp(buf, cmp_buf, BUF_SIZE)) { > + printf("corruption while extending from %ld\n", eof); > + dump_buffer(buf, 0, BUF_SIZE); > + return 1; > + } > + } > + > + printf("Success, all done.\n"); > + return 0; > +} > diff --git a/tests/generic/326 b/tests/generic/326 > new file mode 100755 > index 0000000..f20375a > --- /dev/null > +++ b/tests/generic/326 > @@ -0,0 +1,65 @@ > +#! /bin/bash > +# FS QA Test No. 326 > +# > +# Test races while extending past EOF via sub-block AIO writes > +# > +#----------------------------------------------------------------------- > +# Copyright (c) 2015 Red Hat, Inc. All Rights Reserved. > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation. > +# > +# This program is distributed in the hope that it would be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write the Free Software Foundation, > +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > +#----------------------------------------------------------------------- > +# > + > +seq=`basename $0` > +seqres=$RESULT_DIR/$seq > +echo "QA output created by $seq" > + > +here=`pwd` > +tmp=/tmp/$$ > +status=1 # failure is the default! > +trap "_cleanup; exit \$status" 0 1 2 3 15 > + > +_cleanup() > +{ > + cd / > + rm -f $TEST_DIR/tst-aio-dio-eof-race > +} > + > +# get standard environment, filters and checks > +. ./common/rc > +. ./common/filter > + > +_supported_fs generic > +_supported_os Linux > + > +_require_test > +_require_sparse_files > +_require_aiodio aio-dio-eof-race > + > +# Test does 512 byte DIO, so make sure that'll work > +logical_block_size=`_min_dio_alignment $TEST_DEV` > + > +if [ "$logical_block_size" -gt "512" ]; then > + _notrun "device block size: $logical_block_size greater than 512" > +fi > + > +# We don't mind 512-byte fs blocks; the IOs won't be sub-block, > +# but the test should still pass, even if it doesn't stress the code > +# we're targeting. > + > +# Note, this test does several extending loops internally > +$AIO_TEST $TEST_DIR/tst-aio-dio-eof-race > + > +status=$? > +exit > diff --git a/tests/generic/326.out b/tests/generic/326.out > new file mode 100644 > index 0000000..22a3e78 > --- /dev/null > +++ b/tests/generic/326.out > @@ -0,0 +1,2 @@ > +QA output created by 326 > +Success, all done. > diff --git a/tests/generic/group b/tests/generic/group > index 4ae256f..a5f3008 100644 > --- a/tests/generic/group > +++ b/tests/generic/group > @@ -207,3 +207,4 @@ > 323 auto aio stress > 324 auto fsr quick > 325 auto quick data log > +326 auto quick aio > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs