From owner-freebsd-fs@freebsd.org Sun Apr 16 21:01:13 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46A09D41FE8 for ; Sun, 16 Apr 2017 21:01:13 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A1771CFE for ; Sun, 16 Apr 2017 21:01:13 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3GL01o3022636 for ; Sun, 16 Apr 2017 21:01:13 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201704162101.v3GL01o3022636@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention Date: Sun, 16 Apr 2017 21:01:13 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 21:01:13 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic New | 217062 | for file systems mounted with -o noexec, exec=off Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 140068 | [smbfs] [patch] smbfs does not allow semicolon in Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f Open | 211491 | System hangs after "Uptime" on reboot with ZFS 7 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Tue Apr 18 15:08:50 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C408D42793 for ; Tue, 18 Apr 2017 15:08:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7B4A5131 for ; Tue, 18 Apr 2017 15:08:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3IF8jDR076181 for ; Tue, 18 Apr 2017 15:08:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 209158] node / npm triggering zfs rename deadlock Date: Tue, 18 Apr 2017 15:08:46 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bugs.freebsd.org@lpz.yellowspace.net X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: avg@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 15:08:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209158 Lorenzo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugs.freebsd.org@lpz.yellow | |space.net --- Comment #51 from Lorenzo --- (In reply to Michael Gmelin from comment #50) +1 on this. Any chance to have the fix merged on 10.3? I can reliably repro= duce the problem at any time on 10.3-RELEASE-p11/-p17 with an nmp install. It is quite a show blocker, and we're relying on LTS releases (10.3-RELEASE being= the only one currently)... --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Wed Apr 19 15:02:46 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CFF6D458FA for ; Wed, 19 Apr 2017 15:02:46 +0000 (UTC) (envelope-from dan@langille.org) Received: from clavin2.langille.org (clavin2.langille.org [199.233.228.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "BSD Cabal Headquarters" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B6951A2C for ; Wed, 19 Apr 2017 15:02:45 +0000 (UTC) (envelope-from dan@langille.org) Received: from (clavin2.int.langille.org (clavin2.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 713F242D6 for ; Wed, 19 Apr 2017 14:56:06 +0000 (UTC) From: Dan Langille Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: vdev state changed & zfs scrub Message-Id: <0030E8CC-66B2-4EBF-A63B-91CF8370D526@langille.org> Date: Wed, 19 Apr 2017 10:56:05 -0400 To: freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 15:02:46 -0000 I see this on more than one system: Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D3558867368789024889 Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D3597532040953426928 Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D8095897341669412185 Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D15391662935041273970 Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D8194939911233312160 Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D4885020496131451443 Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D14289732009384117747 Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D7564561573692839552 zpool status output includes: $ zpool status pool: system state: ONLINE scan: scrub in progress since Wed Apr 19 03:12:22 2017 2.59T scanned out of 6.17T at 64.6M/s, 16h9m to go 0 repaired, 41.94% done The timing of the scrub is not coincidental. Why is vdev status changing? Thank you. --=20 Dan Langille - BSDCan / PGCon dan@langille.org From owner-freebsd-fs@freebsd.org Wed Apr 19 15:06:55 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B4ECD45BD0 for ; Wed, 19 Apr 2017 15:06:55 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C79DB8 for ; Wed, 19 Apr 2017 15:06:55 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by mail-yb0-x230.google.com with SMTP id 6so4903159ybq.2 for ; Wed, 19 Apr 2017 08:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4Nfuat7EX45NN6KSo3OCJuBl15dey5+aPZJizunUL1Q=; b=subGdY2PZqK5nt7KgiY1b0X9WdJXjv2w7AkTOhihaB2ayzMWyjF5Y4ASL+ZS084p/w pUuymDyBfQ0DTbJV8IeWQ+o48JLHRMY/vyEI7KYTuTSY3LXeSQZNCkn2JpRnX4XR6wA9 0+EX+IoG4fYFAtwCNcwoDPU1L5wh14MZ0RTuO2xbVSrz7uWjFOil6+zCsJM2mgN+Aztb ZvXojQcg99kOQiWqrxRG6GcAsXEG7FYVYFLNM/gbju8gnutSqFFPLmgNBk7OjVX7OlLK 3TJyx/XvngfocOtub/emvpXorrHEqTnJXvS3BJi/qgDOvS+feVSpKCRtzSuQJ2hId1hc 5GEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4Nfuat7EX45NN6KSo3OCJuBl15dey5+aPZJizunUL1Q=; b=oilOj1z8eGMRqlKYzYmgxmFKyt5Fs1p0U0/GrvQgYv6gZoJWvlywYJ9+DT3Ef0Ecdu txJC/ZDvg9XW5Ex26pHR4UotRbxfKZUOAAw1/35xDxT49oA/FH9Q807KXEaO9Xh5ZML7 WeSBjUrDCAOyXnURBr+aJAwcV14QBHTcZZIcWbx3iQeV0Z6HrfOfVlYjpESYoCZw/lMx Wx1SlTPmpvUt/zGIE6FLn23yF2pzRrVeH9WMK7ibkFym3w6pelqLLXTz+tER8d8OhTvx gCJFZjtAsqQbO3h59s0ApFj4/3yZUGPlqumQw12J5dcekwRZM0YsvE7hNnMRVcS9Ag20 v3kg== X-Gm-Message-State: AN3rC/7XjCjBDSjOnP0iNwscCSlI/V1QZgn5YS0m96HDo3tmTkBkmgDx m3KwyTa5t0pVaLCQlfkIUeiJh+XsIg== X-Received: by 10.157.21.17 with SMTP id u17mr1564011otf.43.1492614414238; Wed, 19 Apr 2017 08:06:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.170.161 with HTTP; Wed, 19 Apr 2017 08:06:53 -0700 (PDT) In-Reply-To: References: From: Doug Rabson Date: Wed, 19 Apr 2017 16:06:53 +0100 Message-ID: Subject: Re: NFSv4 Linux client atime for exclusive create To: Rick Macklem Cc: "freebsd-fs@freebsd.org" , "jim@ks.uiuc.edu" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 15:06:55 -0000 Is the client using EXCLUSIVE4 or EXCLUSIVE4_1 for the open? If its EXCLUSIVE4_1, i.e. the mode which allows attribute setting during the open, the client should use the value of the supattr_exclcreat attribute (see section 5.8.1.14 of rfc5661) to figure out what attributes can be set. In this case, supattr_exclcreat should not include atime which should force the client to update it separately. It would be helpful to see a packet trace for this which should make it clearer what is happening here. On 14 April 2017 at 23:44, Rick Macklem wrote: > PR#218218 reports a problem where a file created by an NFSv4 mount (using > a recent > Linux kernel) results in a bogus atime for the newly created file. > > With the help of a packet trace from the problem reported I now know what > is > happening, but it turns out to be interesting and I am not sure I have a > good way > to fix it. > Here's the story... > - The Linux client does an Exclusive create. > - As was the norm for NFSv3, the FreeBSD server stores the create_verifier > for this > exclusive create in the atime field of the newly created file, so it can > be checked > for a retry of the exclusive create. > --> For NFSv3, it was required that a client follow an exclusive create > with a Setattr > of atime to fix the atime. > It turns out that, for NFSv4, the client is not required to do the Setattr > of atime. > (The FreeBSD client does do this and I think older Linux NFSv4 clients > did.) > --> This Linux client follows the exclusive create with a Setattr, but > only for the "mode" > attribute, leaving the create_verifier in the atime field. > > I can think of two ways to fix this: > 1 - Make the Setattr set atime whenever it sets any other attribute. > --> This would result in atime being set for changes to the file's > metadata, which is not > what atime is supposed to do. (Yuck!) > 2 - For NFSv4, store the create_verifier in an extended attribute instead > of atime. > --> I think this would work, but it would imply that only file > systems that support > extended attributes (UFS, ZFS, ??) could be exported to NFSv4 > clients. > > Anyone have other ideas w.r.t. how to fix this? > > Does restricting NFSv4 exports to file systems that support extended > attributes sound > reasonable? > > Thanks for any comments w.r.t. this, rick > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@freebsd.org Wed Apr 19 20:29:11 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A358DD46E3A for ; Wed, 19 Apr 2017 20:29:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660058.outbound.protection.outlook.com [40.107.66.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52D961E29 for ; Wed, 19 Apr 2017 20:29:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Wed, 19 Apr 2017 20:29:08 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.1034.015; Wed, 19 Apr 2017 20:29:08 +0000 From: Rick Macklem To: Doug Rabson CC: "freebsd-fs@freebsd.org" , "jim@ks.uiuc.edu" Subject: Re: NFSv4 Linux client atime for exclusive create Thread-Topic: NFSv4 Linux client atime for exclusive create Thread-Index: AQHStW9Xwd3iU1MkQkKHy7u7vlbe/6HM0kmAgABXYs0= Date: Wed, 19 Apr 2017 20:29:08 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:TfEHfgdffpM8gzz6obYSp7EG2aM/0stVM+MfSSWw8d2sw5vXZBjy9dpTaFMAppkHb8EpFA0uAjI1kA67yVm5Qp5M0bNTUXeJdl/8sNG44d2w2PbxZwfQPXn/lh91SI0T7opxH6PGRJOVgny1MVrw0tFk9jo7iQa2ZUF8JLsGAmiy/YsfSjCB1LTmET0CySOLHatP7MEZzdts5NSk3hp1OoeM0a/iP6ldDG2KFyIqYqDeeQji1sNOPjWSP48mLkKG90vWcMC/PM4qDxeEDOeSfD+kFCA8Nt6VmRv/7/qpxvGKmX+6FMrUMvNIUM8r3ljItZ1DUUBEL1QOJU3/iMsrvQ== x-ms-office365-filtering-correlation-id: 55ad63c5-7eab-44b1-21b2-08d48762bb63 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:YTXPR01MB0191; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39840400002)(39850400002)(39400400002)(39450400003)(51444003)(24454002)(4326008)(9686003)(110136004)(54906002)(55016002)(7696004)(229853002)(305945005)(2950100002)(38730400002)(74316002)(53936002)(5660300001)(6916009)(122556002)(33656002)(81166006)(6506006)(54356999)(76176999)(6436002)(6246003)(2900100001)(3280700002)(102836003)(2906002)(8936002)(77096006)(50986999)(8676002)(25786009)(189998001)(3660700001)(74482002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 20:29:08.4982 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 20:29:11 -0000 Doug Rabson wrote: >Is the client using EXCLUSIVE4 or EXCLUSIVE4_1 for the open? If its EXCLUS= IVE4_1, i.e. the >mode which allows attribute setting during the open, the = client should use the value of >the supattr_exclcreat attribute (see sectio= n 5.8.1.14 of rfc5661) to figure out what >attributes can be set. In this c= ase, supattr_exclcreat should not include atime which should >force the cli= ent to update it separately. The packet trace Jim sent me was NFSv4.0 and, as such, used EXCLUSIVE4. (The Open was followed by a Setattr in a separate compound RPC that only sp= ecified the "mode" attribute. The client never seemed to specify an atime.) I haven't tried an NFSv4.1 mount yet, but I need to take a look at it. (I did succeed in reproducing the problem with an NFSV4.0 mount from a Linu= x box I have.) >It would be helpful to see a packet trace for this which should make it cl= earer what is >happening here. Jim did send me this off list. I now have a patch that stores the create_verifier in an extended attribute= and I think that should be fine? (It does imply that NFSv4.0 read/write mounts will onl= y work correctly for server file systems that support extended attributes, but I t= hink that is a reasonable restriction that can't be avoided?) [stuff snipped] rick= From owner-freebsd-fs@freebsd.org Wed Apr 19 21:26:51 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F15A1D460D4 for ; Wed, 19 Apr 2017 21:26:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660060.outbound.protection.outlook.com [40.107.66.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F71A175B for ; Wed, 19 Apr 2017 21:26:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Wed, 19 Apr 2017 21:26:49 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.1034.015; Wed, 19 Apr 2017 21:26:49 +0000 From: Rick Macklem To: Doug Rabson CC: "freebsd-fs@freebsd.org" , "jim@ks.uiuc.edu" Subject: Re: NFSv4 Linux client atime for exclusive create Thread-Topic: NFSv4 Linux client atime for exclusive create Thread-Index: AQHStW9Xwd3iU1MkQkKHy7u7vlbe/6HM0kmAgABXYs2AABEAkQ== Date: Wed, 19 Apr 2017 21:26:48 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rabson.org; dkim=none (message not signed) header.d=none;rabson.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:Zj4GkgAZyaVmLkoqJNmmw0AmLLTGDLJyZ3YK/9AcX/rdrbhM/+cm3P/Rhow8Vn0vJym9cqlSPKRNx2v8yWze+QIzHyTGO+2UV+yPvmhdKh9Ty+n4T/vbQNBQkOc/QZKBEoTJpMS2bUGrCNUDSMMhGkLA/unqqSRqYnNVaM3G+ox1PyMw8itYvbszJSc3Zj1iBHGEnAhMxQZZMZBnW7vdPV1AjtdUA3PEHUTQiq3ZyfTGsSsxtK+vMrpNiyXaV0iVpLnRLKyKuP1xDxDhgKK9sRW0h8H7EO97oNCv3H+ByBqHmew+dNvIKVxCmBbmRSaUQ52qmidgW3kXJ7Vc11uo9A== x-ms-office365-filtering-correlation-id: 0843d047-1617-484b-7296-08d4876ac9f6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:YTXPR01MB0189; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(75325880899374); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0189; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39400400002)(39410400002)(39850400002)(51444003)(51914003)(377454003)(24454002)(76176999)(4326008)(6916009)(7696004)(54356999)(2900100001)(53546009)(25786009)(2950100002)(110136004)(229853002)(50986999)(33656002)(122556002)(3280700002)(189998001)(55016002)(77096006)(6246003)(38730400002)(102836003)(74482002)(81166006)(6506006)(2906002)(8676002)(3660700001)(8936002)(74316002)(6306002)(9686003)(5660300001)(305945005)(53936002)(6436002)(86362001)(54906002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 21:26:49.0016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:26:52 -0000 Hope you don't mind a quick top post related to my last email... I just looked in the new RFC for NFSv4.0 and it notes that the reply to Open should specify the attribute(s) used to store the create_verifier. Either this wasn't in the original RFC (3530) or I never read it, because t= he FreeBSD NFSv4.0 server doesn't do this. I'll come up with a patch that sets the atime bit in the EXCLUSIVE4 Open reply and see if that changes the Linux client behaviour. Also, the server doesn't set this bit in the EXCLUSIVE4_1 reply as RFC5661 says it should, so I need to patch this too. I suspect this will fix the problem without using an extended attribute to store the create_verifier. Having said that, I think that storing the create_verifier in an extended a= ttribute might be a good idea, for file systems that support them? Thanks for the comments that convinced me to take another look at the RFCs,= rick ________________________________________ From: owner-freebsd-fs@freebsd.org on behalf= of Rick Macklem Sent: Wednesday, April 19, 2017 4:29:08 PM To: Doug Rabson Cc: freebsd-fs@freebsd.org; jim@ks.uiuc.edu Subject: Re: NFSv4 Linux client atime for exclusive create Doug Rabson wrote: >Is the client using EXCLUSIVE4 or EXCLUSIVE4_1 for the open? If its EXCLUS= IVE4_1, i.e. the >mode which allows attribute setting during the open, the = client should use the value of >the supattr_exclcreat attribute (see sectio= n 5.8.1.14 of rfc5661) to figure out what >attributes can be set. In this c= ase, supattr_exclcreat should not include atime which should >force the cli= ent to update it separately. The packet trace Jim sent me was NFSv4.0 and, as such, used EXCLUSIVE4. (The Open was followed by a Setattr in a separate compound RPC that only sp= ecified the "mode" attribute. The client never seemed to specify an atime.) I haven't tried an NFSv4.1 mount yet, but I need to take a look at it. (I did succeed in reproducing the problem with an NFSV4.0 mount from a Linu= x box I have.) >It would be helpful to see a packet trace for this which should make it cl= earer what is >happening here. Jim did send me this off list. I now have a patch that stores the create_verifier in an extended attribute= and I think that should be fine? (It does imply that NFSv4.0 read/write mounts will onl= y work correctly for server file systems that support extended attributes, but I t= hink that is a reasonable restriction that can't be avoided?) [stuff snipped] rick _______________________________________________ freebsd-fs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Thu Apr 20 03:12:54 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8C5DD474DE for ; Thu, 20 Apr 2017 03:12:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95C3817D9 for ; Thu, 20 Apr 2017 03:12:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3K3Csov094492 for ; Thu, 20 Apr 2017 03:12:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 218636] [fuse] [bug] kernel_cache is enabled by default Date: Thu, 20 Apr 2017 03:12:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cem@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 03:12:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218636 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress Assignee|freebsd-fs@FreeBSD.org |cem@freebsd.org CC| |cem@freebsd.org --- Comment #1 from Conrad Meyer --- https://reviews.freebsd.org/D10434 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Apr 20 08:39:51 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2355D46136 for ; Thu, 20 Apr 2017 08:39:51 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D9EE351 for ; Thu, 20 Apr 2017 08:39:51 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by mail-oi0-x234.google.com with SMTP id j201so40670348oih.2 for ; Thu, 20 Apr 2017 01:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bDJH/JdDcIXRVxRdlgDdwlL7ztuo4VeMxWen8+T8hmE=; b=H7aGFPgpL/kyhrBo5WLsW2Sh+l4p3fcubXwyB2K0NBtUaA/rqE/SezjneORP8JeiAb XeUz63NYZiSawdz2NweqQK85ru7maNQOgAzFOIUdsDDAhH3Gz+qLUBOnVEYG+ERL/jjH ANC51F+aM5ZpTBDDX5gKy1sUw1pbOGLMpYJNN6ccme8K7LobzuD7kLW/Skt19iyAovht 7gGqoQt9ihaF8j7a6Elmn5Jc8n8VGWaRglVGzBi2eLxwyG1+41v2hKzkYDGN8ssA1miq d+Fpvb1yLlqgJ1Kei0X4Huue6UfAeA6hio9XqrG0uizr38UdnvxzFQH5VKWeoDbCKsuf Hatw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bDJH/JdDcIXRVxRdlgDdwlL7ztuo4VeMxWen8+T8hmE=; b=T+qDGEcyeCeIO1+pcH29Re1KyRjFx3YnKpLcOsXmykW0nOifuE5k3GsgeN0rS3vJ0b P6HsFFjqPaDzlCNC120cqEM4wCNLiF9ZbsmCfiOWmj3NE+erldCRG/O83k5zgHgThlQS Ky43I4pNrZKqsAX3BUuviy+m9ie9pXbJ3oBTMyqKutfTw4ikgh+rikHS7ikPZlLVlcwG Vtt7ppQCBA4jDLqOxzvAK1ySi5AyFmhs527XFJk8fwglXO1mZccCQcR0kxq8BrfrWKV7 lPBzezwhd+EloUytNDOvXP6s6maqOvpuepJazBFIn+CSh2h/TWR+fP+Ec7s+jEzg/kQa QyVw== X-Gm-Message-State: AN3rC/7s/456jxuAwzBTt35lDLCIRL0nJFl8iWChS/1YuA4KCWw/cEfN VllB4WDe4zrH3IthpOQPeXQpUZupnA== X-Received: by 10.157.43.40 with SMTP id o37mr1326221otb.64.1492677590513; Thu, 20 Apr 2017 01:39:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.170.161 with HTTP; Thu, 20 Apr 2017 01:39:50 -0700 (PDT) In-Reply-To: References: From: Doug Rabson Date: Thu, 20 Apr 2017 09:39:50 +0100 Message-ID: Subject: Re: NFSv4 Linux client atime for exclusive create To: Rick Macklem Cc: "freebsd-fs@freebsd.org" , "jim@ks.uiuc.edu" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 08:39:51 -0000 That was actually going to me my next suggestion, honest. Hopefully that fixes the problem, if not its a bug in the Linux client. On 19 April 2017 at 22:26, Rick Macklem wrote: > Hope you don't mind a quick top post related to my last email... > I just looked in the new RFC for NFSv4.0 and it notes that the reply > to Open should specify the attribute(s) used to store the create_verifier. > Either this wasn't in the original RFC (3530) or I never read it, because > the > FreeBSD NFSv4.0 server doesn't do this. > > I'll come up with a patch that sets the atime bit in the EXCLUSIVE4 Open > reply and see if that changes the Linux client behaviour. > > Also, the server doesn't set this bit in the EXCLUSIVE4_1 reply as RFC5661 > says it should, so I need to patch this too. > > I suspect this will fix the problem without using an extended attribute to > store the create_verifier. > > Having said that, I think that storing the create_verifier in an extended > attribute > might be a good idea, for file systems that support them? > > Thanks for the comments that convinced me to take another look at the > RFCs, rick > ________________________________________ > From: owner-freebsd-fs@freebsd.org on > behalf of Rick Macklem > Sent: Wednesday, April 19, 2017 4:29:08 PM > To: Doug Rabson > Cc: freebsd-fs@freebsd.org; jim@ks.uiuc.edu > Subject: Re: NFSv4 Linux client atime for exclusive create > > Doug Rabson wrote: > >Is the client using EXCLUSIVE4 or EXCLUSIVE4_1 for the open? If its > EXCLUSIVE4_1, i.e. the >mode which allows attribute setting during the > open, the client should use the value of >the supattr_exclcreat attribute > (see section 5.8.1.14 of rfc5661) to figure out what >attributes can be > set. In this case, supattr_exclcreat should not include atime which should > >force the client to update it separately. > The packet trace Jim sent me was NFSv4.0 and, as such, used EXCLUSIVE4. > (The Open was followed by a Setattr in a separate compound RPC that only > specified > the "mode" attribute. The client never seemed to specify an atime.) > > I haven't tried an NFSv4.1 mount yet, but I need to take a look at it. > (I did succeed in reproducing the problem with an NFSV4.0 mount from a > Linux > box I have.) > > >It would be helpful to see a packet trace for this which should make it > clearer what is >happening here. > Jim did send me this off list. > > I now have a patch that stores the create_verifier in an extended > attribute and I think > that should be fine? (It does imply that NFSv4.0 read/write mounts will > only work > correctly for server file systems that support extended attributes, but I > think that > is a reasonable restriction that can't be avoided?) > [stuff snipped] > > rick > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@freebsd.org Thu Apr 20 09:39:14 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DE67D47DD1 for ; Thu, 20 Apr 2017 09:39:14 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D51D48F5 for ; Thu, 20 Apr 2017 09:39:13 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x22e.google.com with SMTP id o22so67565980iod.3 for ; Thu, 20 Apr 2017 02:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=hdt5YhDm7cwr2nSXzNm8SbfZoat6OX+oddmWwsH82EU=; b=JP+djVDJ4ALAFcQ0WHHPZ5uiUV1KQV+Zz4r8x24Vlrk+RCv0GIRpCJfqf8IODjSy+R NUVErNqeN8Jsrm/6Cc/2+cIKuJbuIQLdrhnyglGjhB3kglJE+m2B30UeuugmE3LSQzKV zaTw8FHjqGgYG5EM9cCv0QO/cjLiohNq5VErVW2g6JG+obY3pfslTQFERVkRLvDd+t/3 xc5gvkPKXRyriQRPqLt05upameGGRDHQCaMC8NzZCEPWVDri/VFR8BY3eJk3BOm+oxz9 ZaQ41MmKAxUq2/gZkmO8eXZWkoD2SzqDPBA/mLc/yc/zJ3obS2xNMwyj1PV0+ZaIsC4T uoJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=hdt5YhDm7cwr2nSXzNm8SbfZoat6OX+oddmWwsH82EU=; b=R/DBa/+WkUSdoKKmwROY5zgzQJmFIpbY5PDLE4JcMuVFbfhFNllfMZTuXYf0Zcbql8 kCXWIm3dwSfVIfjQbAm9+YOlQOGEUawzquXcQ1te0bNqPdKY+Mk8zhiYM9NYw6szuE6+ EIHL3CQbYEHUlvNtyfFS9Qin6PqqirY/MF7eOLaIX6FacO34JUgxJBKJPLhAhlNodAnx CkZULtxjvgz/2D4TTWqiB5akkWrbPGoqpEnM4I9eb0uEMbK1mNJUdwtYHVCyw4tnyOT3 DcgIikHRbDZBPgLzbEhvoVUSkoqjiFXro9E8GUDkYkpdmwZ8wVchH90wk1h8UPCDAVCf MX/g== X-Gm-Message-State: AN3rC/4HFLwdqndUaZMkyowUzXUPIe6bC5H9iWtC0yqwMLAjdFc7xWIY vrbIh8BGJxesy682D+FZVWV9Vb2IyQWNd1s= X-Received: by 10.107.138.7 with SMTP id m7mr7810853iod.133.1492681152923; Thu, 20 Apr 2017 02:39:12 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.102.193 with HTTP; Thu, 20 Apr 2017 02:39:12 -0700 (PDT) From: Maxim Sobolev Date: Thu, 20 Apr 2017 02:39:12 -0700 X-Google-Sender-Auth: Lfm5pOQotlJmVRD8FCeU0uwdkBo Message-ID: Subject: UFS snapshot "file" is slightly bigger than underlying disk partition To: FreeBSD Filesystems , Kirk McKusick Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 09:39:14 -0000 Hi Kirk, I've noticed that the snapshot file is slightly bigger than underlying disk partition. First I thought it's some kind of header attached to the end, but the size of difference is actually dependent on the disk size. Is it by design, or some sort of "off by x" error? What's annoying about that is that the size is not multiple of SECTOR_SIZE. Also looks like if I just cut that junk out resulting FS image is just as usable. Attached script illustrates that. The first column is size of the partition, the second column is the size of the difference, both in bytes. 1048576 48 2097152 56 4194304 72 8388608 72 16777216 72 33554432 72 67108864 72 134217728 72 268435456 72 536870912 72 1073741824 72 2147483648 72 4294967296 96 8589934592 152 17179869184 256 34359738368 464 68719476736 880 137438953472 1720 274877906944 3392 549755813888 6744 Please advise, thanks. -Max (P.S. This is 11.0-RELEASE-p9) From owner-freebsd-fs@freebsd.org Thu Apr 20 09:39:52 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 978F4D47E16 for ; Thu, 20 Apr 2017 09:39:52 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B2F697B for ; Thu, 20 Apr 2017 09:39:52 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id m123so32279199wma.0 for ; Thu, 20 Apr 2017 02:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=8wAHRCmVNERMMG/FDKacgDY2R6rI1Wh0MzJdGIOqD7k=; b=gfO6QRZ8HPwWxB748ivq4k3ezZgRdadu3043yTM9f+pFk1+gMLE6/jfB/l06uFjhf/ LdF1YDUXIQPQuqcd8qvBCe9h/or0Vh0RQ5HLkT3is6WgrKbzr94JwtoNrxW2Gb6qcdga dIKM/jQKDV5MJwvRJRuAVBe8Q0AR844AGDaPLvv793gZo5Rv1Sm79xthMSxC4eKgqup3 NS9AyfLd0S/o8G60p4bJfaE1/32T03vdBRufImcAPsWjI0RG92bLAnqG/SsC/fM+YNXx MBEneZIxXAX2i8QTWsxkgJmdjYjNUuiJHpJUHa5x4fk2lrcHf4iLVFgdkearOAg/bk4M 6orQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8wAHRCmVNERMMG/FDKacgDY2R6rI1Wh0MzJdGIOqD7k=; b=pjafXV5pYysdTmtF+E1/LmQMeIeIGqv3FnHREWblEN+/BySALcZ8gSBDaO+HLXGNZT OuBmvzOSWZoDWVfFPrug1iRU+r6B5I58TnccEhA52Kz7ZOI0vnmUMDpgk1zp+o7hDJYI jafHYo93gA6o8+hyZOkPLiDLG/++H17F5YLwvGR45+bk+EZRwQ8aV3hzGYzTB+L1RLi2 1+HTuY6A7R+VjN1LNyHJERrmTADMpIe3NvGkGcMfaIBd72Be9eOyInZqtZXpQidcZ86P hHYR8uRTAMx3FlEG4jRcuBVBkygLzh3RBag5c/C11TMjpCHSLc0+VxY0ERcWsBLpkZ5e p4IA== X-Gm-Message-State: AN3rC/5v6qrD0U5UsHAGnaBmYxDTrBsfb4bZLARulwpRYl7vXef8VIrZ oRNgCaubPWMftB/T X-Received: by 10.28.198.65 with SMTP id w62mr2199015wmf.80.1492681189604; Thu, 20 Apr 2017 02:39:49 -0700 (PDT) Received: from Johans-MacBook-Air-2.local (92-111-79-242.static.chello.nl. [92.111.79.242]) by smtp.googlemail.com with ESMTPSA id w52sm6884775wrc.14.2017.04.20.02.39.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 02:39:48 -0700 (PDT) Subject: Re: vdev state changed & zfs scrub To: Dan Langille References: <0030E8CC-66B2-4EBF-A63B-91CF8370D526@langille.org> Cc: freebsd-fs@freebsd.org From: Johan Hendriks Message-ID: <597c74ea-c414-cf2f-d98c-24bb231009ea@gmail.com> Date: Thu, 20 Apr 2017 11:39:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <0030E8CC-66B2-4EBF-A63B-91CF8370D526@langille.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: nl X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 09:39:52 -0000 Op 19/04/2017 om 16:56 schreef Dan Langille: > I see this on more than one system: > > Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=3558867368789024889 > Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=3597532040953426928 > Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=8095897341669412185 > Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=15391662935041273970 > Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=8194939911233312160 > Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=4885020496131451443 > Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=14289732009384117747 > Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=7564561573692839552 > > zpool status output includes: > > $ zpool status > pool: system > state: ONLINE > scan: scrub in progress since Wed Apr 19 03:12:22 2017 > 2.59T scanned out of 6.17T at 64.6M/s, 16h9m to go > 0 repaired, 41.94% done > > The timing of the scrub is not coincidental. > > Why is vdev status changing? > > Thank you. > I have the same "issue", I asked this in the stable list but did not got any reaction. https://lists.freebsd.org/pipermail/freebsd-stable/2017-March/086883.html In my initial mail it was only one machine running 11.0, the rest was running 10.x. Now I have upgraded other machines to 11.0 and I see it there also. regards Johan Hendriks From owner-freebsd-fs@freebsd.org Thu Apr 20 11:19:11 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50995D459E4 for ; Thu, 20 Apr 2017 11:19:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A46FE6DD for ; Thu, 20 Apr 2017 11:19:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA27220; Thu, 20 Apr 2017 14:19:02 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1d1A74-000MVg-K7; Thu, 20 Apr 2017 14:19:02 +0300 Subject: Re: vdev state changed & zfs scrub To: Johan Hendriks , Dan Langille Cc: freebsd-fs@FreeBSD.org References: <0030E8CC-66B2-4EBF-A63B-91CF8370D526@langille.org> <597c74ea-c414-cf2f-d98c-24bb231009ea@gmail.com> From: Andriy Gapon Message-ID: <106e81a2-4631-642d-6567-319d20d943d2@FreeBSD.org> Date: Thu, 20 Apr 2017 14:18:26 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <597c74ea-c414-cf2f-d98c-24bb231009ea@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 11:19:11 -0000 On 20/04/2017 12:39, Johan Hendriks wrote: > Op 19/04/2017 om 16:56 schreef Dan Langille: >> I see this on more than one system: >> >> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=3558867368789024889 >> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=3597532040953426928 >> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=8095897341669412185 >> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=15391662935041273970 >> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=8194939911233312160 >> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=4885020496131451443 >> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=14289732009384117747 >> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=7564561573692839552 >> >> zpool status output includes: >> >> $ zpool status >> pool: system >> state: ONLINE >> scan: scrub in progress since Wed Apr 19 03:12:22 2017 >> 2.59T scanned out of 6.17T at 64.6M/s, 16h9m to go >> 0 repaired, 41.94% done >> >> The timing of the scrub is not coincidental. >> >> Why is vdev status changing? >> >> Thank you. >> > I have the same "issue", I asked this in the stable list but did not got > any reaction. > https://lists.freebsd.org/pipermail/freebsd-stable/2017-March/086883.html > > In my initial mail it was only one machine running 11.0, the rest was > running 10.x. > Now I have upgraded other machines to 11.0 and I see it there also. Previously none of ZFS events were logged at all, that's why you never saw them. As to those particular events, unfortunately two GUIDs is all that the event contains. So, to get the state you have to explicitly check it, for example, with zpool status. It could be that the scrub is simply re-opening the devices, so the state "changes" from VDEV_STATE_HEALTHY to VDEV_STATE_CLOSED to VDEV_STATE_HEALTHY. You can simply ignore those reports if you don't see any trouble. Maybe lower priority of those messages in /etc/devd/zfs.conf... -- Andriy Gapon From owner-freebsd-fs@freebsd.org Thu Apr 20 11:42:59 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FE15D47401 for ; Thu, 20 Apr 2017 11:42:59 +0000 (UTC) (envelope-from dan@langille.org) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "BSD Cabal Headquarters" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E54C51511; Thu, 20 Apr 2017 11:42:58 +0000 (UTC) (envelope-from dan@langille.org) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id E21CD26FD ; Thu, 20 Apr 2017 11:42:49 +0000 (UTC) From: Dan Langille Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: vdev state changed & zfs scrub Date: Thu, 20 Apr 2017 07:42:47 -0400 In-Reply-To: <106e81a2-4631-642d-6567-319d20d943d2@FreeBSD.org> Cc: Johan Hendriks , freebsd-fs@FreeBSD.org To: Andriy Gapon References: <0030E8CC-66B2-4EBF-A63B-91CF8370D526@langille.org> <597c74ea-c414-cf2f-d98c-24bb231009ea@gmail.com> <106e81a2-4631-642d-6567-319d20d943d2@FreeBSD.org> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 11:42:59 -0000 > On Apr 20, 2017, at 7:18 AM, Andriy Gapon wrote: >=20 > On 20/04/2017 12:39, Johan Hendriks wrote: >> Op 19/04/2017 om 16:56 schreef Dan Langille: >>> I see this on more than one system: >>>=20 >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D3558867368789024889 >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D3597532040953426928 >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D8095897341669412185 >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D15391662935041273970 >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D8194939911233312160 >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D4885020496131451443 >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D14289732009384117747 >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, = pool_guid=3D15387115135938424988 vdev_guid=3D7564561573692839552 >>>=20 >>> zpool status output includes: >>>=20 >>> $ zpool status >>> pool: system >>> state: ONLINE >>> scan: scrub in progress since Wed Apr 19 03:12:22 2017 >>> 2.59T scanned out of 6.17T at 64.6M/s, 16h9m to go >>> 0 repaired, 41.94% done >>>=20 >>> The timing of the scrub is not coincidental. >>>=20 >>> Why is vdev status changing? >>>=20 >>> Thank you. >>>=20 >> I have the same "issue", I asked this in the stable list but did not = got >> any reaction. >> = https://lists.freebsd.org/pipermail/freebsd-stable/2017-March/086883.html >>=20 >> In my initial mail it was only one machine running 11.0, the rest was >> running 10.x. >> Now I have upgraded other machines to 11.0 and I see it there also. >=20 > Previously none of ZFS events were logged at all, that's why you never = saw them. > As to those particular events, unfortunately two GUIDs is all that the = event > contains. So, to get the state you have to explicitly check it, for = example, > with zpool status. It could be that the scrub is simply re-opening = the devices, > so the state "changes" from VDEV_STATE_HEALTHY to VDEV_STATE_CLOSED to > VDEV_STATE_HEALTHY. You can simply ignore those reports if you don't = see any > trouble. > Maybe lower priority of those messages in /etc/devd/zfs.conf... I found the relevant entries in said file: notify 10 { match "system" "ZFS"; match "type" "resource.fs.zfs.statechange"; action "logger -p kern.notice -t ZFS 'vdev state changed, = pool_guid=3D$pool_guid vdev_guid=3D$vdev_guid'"; }; Is 10 priority the current priority? At first, I thought it might be kern.notice, but reading man = syslog.conf, notice is a level, not a priority. I've change 10 to a 1 and we shall see. Thank you. --=20 Dan Langille - BSDCan / PGCon dan@langille.org From owner-freebsd-fs@freebsd.org Thu Apr 20 14:30:45 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF49FD469DE for ; Thu, 20 Apr 2017 14:30:45 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7B2D820; Thu, 20 Apr 2017 14:30:45 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id v3KEVN59061503; Thu, 20 Apr 2017 07:31:23 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201704201431.v3KEVN59061503@chez.mckusick.com> From: Kirk McKusick To: Maxim Sobolev Subject: Re: UFS snapshot "file" is slightly bigger than underlying disk partition cc: FreeBSD Filesystems In-reply-to: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <61501.1492698683.1@chez.mckusick.com> Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Apr 2017 07:31:23 -0700 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:30:45 -0000 > From: Maxim Sobolev > Date: Thu, 20 Apr 2017 02:39:12 -0700 > Subject: UFS snapshot "file" is slightly bigger than underlying disk par= tition > To: FreeBSD Filesystems , > Kirk McKusick > = > Hi Kirk, > = > I've noticed that the snapshot file is slightly bigger than underlying d= isk > partition. First I thought it's some kind of header attached to the end, > but the size of difference is actually dependent on the disk size. Is it= by > design, or some sort of "off by x" error? What's annoying about that is > that the size is not multiple of SECTOR_SIZE. Also looks like if I just = cut > that junk out resulting FS image is just as usable. > = > Attached script illustrates that. The first column is size of the > partition, the second column is the size of the difference, both in byte= s. > = > 1048576 48 > 2097152 56 > 4194304 72 > 8388608 72 > 16777216 72 > 33554432 72 > 67108864 72 > 134217728 72 > 268435456 72 > 536870912 72 > 1073741824 72 > 2147483648 72 > 4294967296 96 > 8589934592 152 > 17179869184 256 > 34359738368 464 > 68719476736 880 > 137438953472 1720 > 274877906944 3392 > 549755813888 6744 > = > Please advise, thanks. > = > -Max > (P.S. This is 11.0-RELEASE-p9) The extra space is for auxilary information that is used to track changes made in the snapshot. Removing it will cause your snapshot maintainance to slow down by 10-100x and in the worst case can cause it to become corrupt. In short, don't mess with it. Kirk McKusick From owner-freebsd-fs@freebsd.org Thu Apr 20 15:24:55 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2270BD48E4A for ; Thu, 20 Apr 2017 15:24:55 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id 97A94DD9; Thu, 20 Apr 2017 15:24:53 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.15.2/8.15.2) with ESMTP id v3KFE4XU044124; Thu, 20 Apr 2017 16:14:04 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id v3KFE4Kt001839; Thu, 20 Apr 2017 16:14:04 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id v3KFE4P8001833; Thu, 20 Apr 2017 16:14:04 +0100 Date: Thu, 20 Apr 2017 16:14:04 +0100 Message-Id: <201704201514.v3KFE4P8001833@higson.cam.lispworks.com> From: Martin Simmons To: Dan Langille CC: avg@FreeBSD.org, freebsd-fs@FreeBSD.org In-reply-to: (message from Dan Langille on Thu, 20 Apr 2017 07:42:47 -0400) Subject: Re: vdev state changed & zfs scrub References: <0030E8CC-66B2-4EBF-A63B-91CF8370D526@langille.org> <597c74ea-c414-cf2f-d98c-24bb231009ea@gmail.com> <106e81a2-4631-642d-6567-319d20d943d2@FreeBSD.org> X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 15:24:55 -0000 >>>>> On Thu, 20 Apr 2017 07:42:47 -0400, Dan Langille said: > > > On Apr 20, 2017, at 7:18 AM, Andriy Gapon wrote: > > > > On 20/04/2017 12:39, Johan Hendriks wrote: > >> Op 19/04/2017 om 16:56 schreef Dan Langille: > >>> I see this on more than one system: > >>> > >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=3558867368789024889 > >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=3597532040953426928 > >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=8095897341669412185 > >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=15391662935041273970 > >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=8194939911233312160 > >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=4885020496131451443 > >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=14289732009384117747 > >>> Apr 19 03:12:22 slocum ZFS: vdev state changed, pool_guid=15387115135938424988 vdev_guid=7564561573692839552 > >>> > >>> zpool status output includes: > >>> > >>> $ zpool status > >>> pool: system > >>> state: ONLINE > >>> scan: scrub in progress since Wed Apr 19 03:12:22 2017 > >>> 2.59T scanned out of 6.17T at 64.6M/s, 16h9m to go > >>> 0 repaired, 41.94% done > >>> > >>> The timing of the scrub is not coincidental. > >>> > >>> Why is vdev status changing? > >>> > >>> Thank you. > >>> > >> I have the same "issue", I asked this in the stable list but did not got > >> any reaction. > >> https://lists.freebsd.org/pipermail/freebsd-stable/2017-March/086883.html > >> > >> In my initial mail it was only one machine running 11.0, the rest was > >> running 10.x. > >> Now I have upgraded other machines to 11.0 and I see it there also. > > > > Previously none of ZFS events were logged at all, that's why you never saw them. > > As to those particular events, unfortunately two GUIDs is all that the event > > contains. So, to get the state you have to explicitly check it, for example, > > with zpool status. It could be that the scrub is simply re-opening the devices, > > so the state "changes" from VDEV_STATE_HEALTHY to VDEV_STATE_CLOSED to > > VDEV_STATE_HEALTHY. You can simply ignore those reports if you don't see any > > trouble. > > Maybe lower priority of those messages in /etc/devd/zfs.conf... > > I found the relevant entries in said file: > > notify 10 { > match "system" "ZFS"; > match "type" "resource.fs.zfs.statechange"; > action "logger -p kern.notice -t ZFS 'vdev state changed, pool_guid=$pool_guid vdev_guid=$vdev_guid'"; > }; > > Is 10 priority the current priority? > > At first, I thought it might be kern.notice, but reading man syslog.conf, notice is a level, not a priority. No, I think he meant change kern.notice to something else such as kern.info so you don't see them in /var/log/messages (as controlled by /etc/syslog.conf). __Martin From owner-freebsd-fs@freebsd.org Thu Apr 20 16:12:54 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77DC0D4825E for ; Thu, 20 Apr 2017 16:12:54 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EAA2164B for ; Thu, 20 Apr 2017 16:12:54 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x232.google.com with SMTP id x184so57452764oia.1 for ; Thu, 20 Apr 2017 09:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3ZelR0FV5ngrRPAzmpbiiLxHYnAYWXPkic6IaRfxnJ0=; b=UTFzmwlN8SwV7yNdTYBhG0UYWQP9xp8w9nZGVXJg4Et8tc6/wDpXnZuwET9vcy1kpc GjQuOM+bvvmYv9CZGvS9derQMvrTsdgRcDcSE1PHnVHHLg/vaFQRBuHfDtZlUyU6sXHU +p8azgR1ca709v3UoWXcYcb6KLG1iqg11SWGDhFgeTR08/aLQOJ7SsbX4zrZlPUIRT6s i0lP3NLGKM+YRebCv5IUjwRCSiI1dWArSYmHPaVYGjmmGKVNibELotvWc5nGraEMKzrm MTnKv7sw1fxeP2FWGG1zGCMbPM9mPLiq7m3JhsD18V8Ljd5A2yA26AQTxyhwPS8uq1u8 bh1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3ZelR0FV5ngrRPAzmpbiiLxHYnAYWXPkic6IaRfxnJ0=; b=ItmOQlLKSmfkyBgndWzNw8FT/LEUtPJNX46cDmdzPXuPy5tHd5CetoTxIeNrp85opV dpPb29cUYr7//qXlKLqp0ZHzdSNHM2juNRw2jxINhYuea7iQT+ueyJrgLTjtyxACOWOA w+X35kwEN/fH8ZeBb5GqtRnz4MOuTkBYktB3yh93cit3JeF7loD5BnU+A9cVG8Hb3dqq vTX4ryj3X8PRz5zFwvSDlGnUhT8Grd00QVdUzC2SYutQs5KoDM0FY3M5UtrgPAFB/uME 5o4kNlBnrRVcDcPFBqFTbdW/RvkDOoJq0YrSCKwBPHfqDf0/ro30QRo5OMQwianJHTg0 hQIA== X-Gm-Message-State: AN3rC/6FH1fj3h+dDjd/feyL6co5xDrxDXKYoRvts7xqvF8zkMH8mSFo xrF+LEgdxYiPRvZmVHfBVnnlDZnfirR4 X-Received: by 10.36.85.148 with SMTP id e142mr4850445itb.106.1492704773414; Thu, 20 Apr 2017 09:12:53 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.102.193 with HTTP; Thu, 20 Apr 2017 09:12:52 -0700 (PDT) In-Reply-To: <201704201431.v3KEVN59061503@chez.mckusick.com> References: <201704201431.v3KEVN59061503@chez.mckusick.com> From: Maxim Sobolev Date: Thu, 20 Apr 2017 09:12:52 -0700 X-Google-Sender-Auth: HNE8SnvbiIgLFzj_5aN-UnmJXns Message-ID: Subject: Re: UFS snapshot "file" is slightly bigger than underlying disk partition To: Kirk McKusick Cc: FreeBSD Filesystems Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:12:54 -0000 Is it possible to hide it somehow from the external view then by any chance? If nothing else, there are some reserved areas for boot code for example and such in the on-disk format as far as I know. What I am interested here is just making compressed image of the FS with the mkuzip, but since the snapshot has some extra bytes at the end, what I am getting is not 1:1 replica, but it now has an extra unwanted block(s) at the end. I can obviously tweak mkuzip to have ability to ignore trailing XXX bytes, but IMHO that would better to be handled in the UFS code. -Max On Thu, Apr 20, 2017 at 7:31 AM, Kirk McKusick wrote: > > From: Maxim Sobolev > > Date: Thu, 20 Apr 2017 02:39:12 -0700 > > Subject: UFS snapshot "file" is slightly bigger than underlying disk > partition > > To: FreeBSD Filesystems , > > Kirk McKusick > > > > Hi Kirk, > > > > I've noticed that the snapshot file is slightly bigger than underlying > disk > > partition. First I thought it's some kind of header attached to the end, > > but the size of difference is actually dependent on the disk size. Is it > by > > design, or some sort of "off by x" error? What's annoying about that is > > that the size is not multiple of SECTOR_SIZE. Also looks like if I just > cut > > that junk out resulting FS image is just as usable. > > > > Attached script illustrates that. The first column is size of the > > partition, the second column is the size of the difference, both in > bytes. > > > > 1048576 48 > > 2097152 56 > > 4194304 72 > > 8388608 72 > > 16777216 72 > > 33554432 72 > > 67108864 72 > > 134217728 72 > > 268435456 72 > > 536870912 72 > > 1073741824 72 > > 2147483648 72 > > 4294967296 96 > > 8589934592 152 > > 17179869184 256 > > 34359738368 464 > > 68719476736 880 > > 137438953472 1720 > > 274877906944 3392 > > 549755813888 6744 > > > > Please advise, thanks. > > > > -Max > > (P.S. This is 11.0-RELEASE-p9) > > The extra space is for auxilary information that is used to track > changes made in the snapshot. Removing it will cause your snapshot > maintainance to slow down by 10-100x and in the worst case can > cause it to become corrupt. In short, don't mess with it. > > Kirk McKusick > > From owner-freebsd-fs@freebsd.org Thu Apr 20 19:43:23 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DB5DD48CC6; Thu, 20 Apr 2017 19:43:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 030228D5; Thu, 20 Apr 2017 19:43:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v3KJhEYS083761 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Apr 2017 22:43:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v3KJhEYS083761 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v3KJhE1Z083760; Thu, 20 Apr 2017 22:43:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 20 Apr 2017 22:43:14 +0300 From: Konstantin Belousov To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, freebsd-ports@freebsd.org Cc: emaste@freebsd.org, Kirk McKusick Subject: 64-bit inodes (ino64) Status Update and Call for Testing Message-ID: <20170420194314.GI1788@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 19:43:23 -0000 Inodes are data structures corresponding to objects in a file system, such as files and directories. FreeBSD has historically used 32-bit values to identify inodes, which limits file systems to somewhat under 2^32 objects. Many modern file systems internally use 64-bit identifiers and FreeBSD needs to follow suit to properly and fully support these file systems. The 64-bit inode project, also known as ino64, started life many years ago as a project by Gleb Kurtsou (gleb@). After that time several people have had a hand in updating it and addressing regressions, after mckusick@ picked up and updated the patch, and acted as a flag-waver. Sponsored by the FreeBSD Foundation I have spent a significant effort on outstanding issues and integration -- fixing compat32 ABI, NFS and ZFS, addressing ABI compat issues and investigating and fixing ports failures. rmacklem@ provided feedback on NFS changes, emaste@ and jhb@ provided feedback and review on the ABI transition support. pho@ performed extensive testing and identified a number of issues that have now been fixed. kris@ performed an initial ports investigation followed by an exp-run by antoine@. emaste@ helped with organization of the process. This note explains how to perform useful testing of the ino64 branch, beyond typical smoke tests. 1. Overview. The ino64 branch extends the basic system types ino_t and dev_t from 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. The struct dirent layout is modified due to the larger size of ino_t, and also gains a d_off (directory offset) member. As ino64 implies an ABI change anyway the struct statfs f_mntfromname[] and f_mntonname[] array length MNAMELEN is increased from 88 to 1024, to allow for longer mount path names. ABI breakage is mitigated by providing compatibility using versioned symbols, ingenious use of the existing padding in structures, and by employing other tricks. Unfortunately, not everything can be fixed, especially outside the base system. For instance, third-party APIs which pass struct stat around are broken in backward and forward- incompatible way. 2. Motivation. The main risk of the ino64 change is the uncontrolled ABI breakage. Due to expansion of the basic types dev_t, ino_t and struct dirent, the impact is not limited to one part of the system, but affects: - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo and more) - libc interface (mostly related to the readdir(3), FTS(3)) - collateral damage in other libraries that happens to use changed types in the interfaces. See, for instance, libprocstat, for which compat was provided using symbol versioning, and libutil, which shlib version was bumped. 3. Quirks. We handled kinfo sysctl MIBs, but other MIBs which report structures depended on the changed type, are not handled in general. It was considered that the breakage is either in the management interfaces, where we usually allow ABI slip, or is not important. Struct xvnode changed layout, no compat shims are provided. For struct xtty, dev_t tty device member was reduced to uint32_t. It was decided that keeping ABI compat in this case is more useful than reporting 64bit dev_t, for the sake of pstat. 4. Testing procedure. The ino64 project can be tested by cloning the project branch from GitHub or by applying the patch to a working tree. The authorative source is the GitHub, I do not promise to update the review for each update. To clone from GitHub: % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino64 To fetch the patch from Phabricator: - Visit https://reviews.freebsd.org/D10439 - Click "Download Raw Diff" at the upper right of the page Or % arc patch D10439 After that, in the checkout directory do % (cd sys/kern && touch syscalls.master && make sysent) % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent) If you use custom kernel configuration, ensure that options COMPAT_FREEBSD11 is included into the config. Then build world and kernel in the usual way, install kernel, reboot, install new world. Do not make shortcuts in the update procedure. 4.1 New kernel, old world. Build and install pristine HEAD world, apply patch and only build and install updated kernel. The system must work same as with the pristine kernel. 4.2 New kernel, new world, old third-party applications. Build and install patched kernel and world. Applications compiled on the pristine HEAD (e.g. installed by pkg from the regular portmgr builds) must work without a regression. 4.3 32bit compat. Same as 4.1 and 4.2, but for 32bit (i386) binaries on the amd64 host. Note that big-endian host, like powerpc, might expose additional bugs in the 32bit compat with the patch, but the testing is too cumbersome to arrange. 4.4 Targeted tests. Useful programs to check items 4.1, 4.2 and 4.3 are versions of the following programs, taken from the pristine system: stat(8). Use it on regular file, file in /dev, socket, pipe and so on. For both native and 32bit compat, stat(8) must print reasonable information. procstat(1). Use it with the -f option to examine processes files. kinfo(9) data must be returned in the format acceptable for older apps. Use pristine find(1) binary with many arbitrary options on a system with installed patched world, in particular, libc. Find examines FTS(3), and compat shims in libc are non-trivial. 4.5 NFS server and client test. Check that the NFS server in the patched kernel operates correctly and without performance regressions. Same for client. NFS should be checked for all four combination of patched/unpatched kernel server/client, because the filehandle format includes inode number. 4.6 Other filesystems Generally, filesystems should see no change in the system behaviour, since patch goal is to provide space to grow in the ABI. In particular, local filesystem layout must stay same. Of course, it is possible that some reliance on the exact sizes of the changed types was left unnoticed during the patch review, in which case e.g. on-disk format would be broken. We do not expect this to slip in, but it is possible and should be watched for. 4.7 Test accounting The process accounting, as documented in acct(5), changed format of the records due to dev_t increase. Verify that the programs like sa(8) and accton(8) correctly work with both old and new accounting records. 5. Ports Status with ino64 A ports exp-run for ino64 is open in PR 218320. The failing ports each responsible for more than 1 skipped port are: lang/ghc 497 multimedia/webcamd 62 lang/gcc6-aux 54 devel/libgtop 39 sysutils/py-psutil 13 devel/llvm38 6 lang/rust 4 sysutils/py-psutil121 3 Patches are available for lang/llvm39, lang/llvm40, lang/ghc, and lang/rust in the topic branch as ports.patch, and llvm38 can be fixed in the same way as llvm39 and llvm40. Assistance with investigating and fixing the port failures will be greatly appreciated. Below is an overview of the problems and proposed solutions, probably mostly relevant to the ports maintainers. 5.1. LLVM LLVM includes a component called Address Sanitizer or ASAN, which tries to intercept syscalls, and contains knowledge of the layout of many system structures. Since stat and lstat syscalls were removed and several types and structures changed, this has to be reflected in the ASAN hacks. 5.2. lang/ghc The ghc compiler and parts of the runtime are written in Haskell, which means that to compile ghc, you need a working Haskell compiler for bootstrap. By default for ghc, the runtime is provided in the form of static libraries. Static libraries reference default versions of libc symbols, which are assigned the ELF symbol version at the final linking stage. As result, using such libraries results in using the updated syscall, but internally the code still uses old system types. The end result is the random memory corruption because both libc and kernel assume new types. This situation cannot be fixed by symbol versioning, because versioning acts too late. Instead, we hacked the bootstrap compiler by providing symbols for modified syscalls in the shipped static libraries, which symbols direct execution to the compat variants of the syscalls. This allows the bootstrap compiler to generate working code. After the stage0, compiler operates on new structures and things stabilize. The real solution is, of course, to re-package the bootstrap compiler, but for some time we need to support pre-ino64 HEAD in ports. Also, learning full scope of GHC maintainance duties, required for that, is too much for the ino64 task. 5.3. lang/rust Rustc has a similar structure to GHC, and same issue. The same solution of patching the bootstrap was done. Also rust libstd and liblibc provide rustified definitions of the system structures, which were updated to reflect the updated layout. I failed to understand why e.g. struct stat has to be defined in 3 places at least, but all found locations were patched. 6. Next Steps The tentative schedule for the ino64 project: 2017-04-20 Post wide call for testing Investigate and address port failures with maintainer support 2017-05-05 Request second exp-run with initial patches applied Investigate and address port failures with maintainer support 2017-05-19 Commit to HEAD Address post-commit failures where feasible From owner-freebsd-fs@freebsd.org Thu Apr 20 23:46:03 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D7AED48A2F for ; Thu, 20 Apr 2017 23:46:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660049.outbound.protection.outlook.com [40.107.66.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26F4B3E5 for ; Thu, 20 Apr 2017 23:46:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Thu, 20 Apr 2017 23:46:00 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.1034.015; Thu, 20 Apr 2017 23:46:00 +0000 From: Rick Macklem To: Doug Rabson CC: "freebsd-fs@freebsd.org" , "jim@ks.uiuc.edu" Subject: Re: NFSv4 Linux client atime for exclusive create Thread-Topic: NFSv4 Linux client atime for exclusive create Thread-Index: AQHStW9Xwd3iU1MkQkKHy7u7vlbe/6HM0kmAgABXYs2AABEAkYAAvc8AgAD5RDY= Date: Thu, 20 Apr 2017 23:45:59 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:s6Y5ghzPk/lif65Di8LduNptkINkcE874G1FbagMGcacQF/id2W/TYqTCLJwXMcNRuoEaNo/QA6GN8gQMOkSbzz67LIm9Cy8rZ3t7Z2/n/mymIRb7REirWSK95EkAfa+Su9za32sZw9+yT9/8CbGoz12zhbaiuqg+SUIiIKXKWEeqXxqvODmY+b2H5j8Oj1tZPHVwpoW/DLKJ88dJzyUOkTLrt4iPL6DmXkUIn7AZb0L7t3aK7xWDNW+4ibW9OVkJfJkHHfTyuLD7rCTCRMmKrO+FpggwSinbiANyO6Uv2Rr/KdxdHJULBt2Jfcey7kCpAsAR2JsJbSJ8N6AH4wtNQ== x-ms-office365-filtering-correlation-id: 4a48b80c-6d0c-426e-53fc-08d4884765fc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:YTXPR01MB0190; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39840400002)(39850400002)(39450400003)(39410400002)(24454002)(93886004)(5890100001)(6246003)(305945005)(5660300001)(229853002)(8676002)(99936001)(122556002)(74316002)(77096006)(54356999)(9686003)(2900100001)(110136004)(4326008)(102836003)(76176999)(6506006)(38730400002)(25786009)(50986999)(3280700002)(3660700001)(6436002)(7696004)(189998001)(2906002)(54906002)(86362001)(55016002)(74482002)(81166006)(53936002)(33656002)(6916009)(2950100002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_YTXPR01MB0189AFA97A8BFE756E6EFE4DDD1B0YTXPR01MB0189CANP_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 23:45:59.9632 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 23:46:03 -0000 --_002_YTXPR01MB0189AFA97A8BFE756E6EFE4DDD1B0YTXPR01MB0189CANP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Doug Rabson wrote: >That was actually going to me my next suggestion, honest. Hopefully that f= ixes the >problem, if not its a bug in the Linux client. Yep, the attached patch fixed the problem. I wrote: >I'll come up with a patch that sets the atime bit in the EXCLUSIVE4 Open >reply and see if that changes the Linux client. The attached patch sets the TIMEACCESS bit in the reply for both NFSv4.0 an= d NFSv4.1 and fixes the problem for both cases for a quick test with the Linux client= . (With this bit set in the reply, Linux sets TIMEACCESSSET in the Setattr.) Doug Rabson wrote: >Is the client using EXCLUSIVE4 or EXCLUSIVE4_1 for the open? If its EXCLUS= IVE4_1, i.e. the >mode which allows attribute setting during the open, the = client should use the value of >the supattr_exclcreat attribute (see sectio= n 5.8.1.14 of rfc5661) to figure out what >attributes can be set. In this c= ase, supattr_exclcreat should not include atime which should=20 The FreeBSD NFSv4.1 server does exclude atime from the supattr_exclcreat b= itset and it checks for it set and returns the correct error. However, like NFSv4.0, the code didn't set the TIMEACCESS attribute bit in = the EXCLUSIVE4_1 reply. (The attached little patch fixes this for both NFSv4.0 = and NFSV4.1.) Thanks everyone for your help. I am thinking that storing the create_verifier in an extended attribute for= file systems that support extended attributes is a good idea, since it will allo= w NFSv4.1 clients to avoid following the Open/Exclusive4_1 with a Setattr RPC. Anyone else have an opinion w.r.t. this? (I'll leave this for a future commit, depending on what others think of the= idea.) I will probably commit the attached patch soon, rick ps: Jim, I don't think there is any point in testing the other patch, altho= ugh I suspect it would fix the problem. You could test this one, if you can easily = do it. pss: My only excuse for never doing this is that it is one sentence in an R= FC of several hundred pages;-) --_002_YTXPR01MB0189AFA97A8BFE756E6EFE4DDD1B0YTXPR01MB0189CANP_ Content-Type: application/octet-stream; name="atime2.patch" Content-Description: atime2.patch Content-Disposition: attachment; filename="atime2.patch"; size=476; creation-date="Thu, 20 Apr 2017 23:41:08 GMT"; modification-date="Thu, 20 Apr 2017 23:41:08 GMT" Content-Transfer-Encoding: base64 LS0tIGZzL25mc3NlcnZlci9uZnNfbmZzZHBvcnQuYy5zYXYJMjAxNy0wNC0yMCAxMDo0Nzo1MS40 NDY5ODMwMDAgLTA0MDAKKysrIGZzL25mc3NlcnZlci9uZnNfbmZzZHBvcnQuYwkyMDE3LTA0LTIw IDExOjAzOjUzLjMzOTIyODAwMCAtMDQwMApAQCAtMTQzNiw3ICsxNDM2LDkgQEAgbmZzdm5vX29w ZW4oc3RydWN0IG5mc3J2X2Rlc2NyaXB0ICpuZCwgcwogCQkJCQkJdnB1dChuZHAtPm5pX3ZwKTsK IAkJCQkJCW5kcC0+bmlfdnAgPSBOVUxMOwogCQkJCQkJbmQtPm5kX3JlcHN0YXQgPSBORlNFUlJf Tk9UU1VQUDsKLQkJCQkJfQorCQkJCQl9IGVsc2UKKwkJCQkJCU5GU1NFVEJJVF9BVFRSQklUKGF0 dHJiaXRwLAorCQkJCQkJICAgIE5GU0FUVFJCSVRfVElNRUFDQ0VTUyk7CiAJCQkJfSBlbHNlIHsK IAkJCQkJbmZzcnZfZml4YXR0cihuZCwgbmRwLT5uaV92cCwgbnZhcCwKIAkJCQkJICAgIGFjbHAs IHAsIGF0dHJiaXRwLCBleHApOwo= --_002_YTXPR01MB0189AFA97A8BFE756E6EFE4DDD1B0YTXPR01MB0189CANP_-- From owner-freebsd-fs@freebsd.org Fri Apr 21 09:39:43 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51DB1D475DD for ; Fri, 21 Apr 2017 09:39:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A57E017E2 for ; Fri, 21 Apr 2017 09:39:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA29796; Fri, 21 Apr 2017 12:39:40 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1d1V2S-000Nf9-A2; Fri, 21 Apr 2017 12:39:40 +0300 Subject: Re: vdev state changed & zfs scrub To: Martin Simmons , Dan Langille Cc: freebsd-fs@FreeBSD.org References: <0030E8CC-66B2-4EBF-A63B-91CF8370D526@langille.org> <597c74ea-c414-cf2f-d98c-24bb231009ea@gmail.com> <106e81a2-4631-642d-6567-319d20d943d2@FreeBSD.org> <201704201514.v3KFE4P8001833@higson.cam.lispworks.com> From: Andriy Gapon Message-ID: <43bac6ef-b588-5eb1-08cb-25caee8ace9b@FreeBSD.org> Date: Fri, 21 Apr 2017 12:38:43 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <201704201514.v3KFE4P8001833@higson.cam.lispworks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 09:39:43 -0000 On 20/04/2017 18:14, Martin Simmons wrote: > No, I think he meant change kern.notice to something else such as kern.info so > you don't see them in /var/log/messages (as controlled by /etc/syslog.conf). Yes, that's exactly what I meant. Sorry for not being clear. -- Andriy Gapon From owner-freebsd-fs@freebsd.org Fri Apr 21 16:39:34 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EF57D48107 for ; Fri, 21 Apr 2017 16:39:34 +0000 (UTC) (envelope-from jim@ks.uiuc.edu) Received: from halifax.ks.uiuc.edu (halifax.ks.uiuc.edu [130.126.120.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailhost.ks.uiuc.edu", Issuer "Thawte Premium Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D03D614CF for ; Fri, 21 Apr 2017 16:39:33 +0000 (UTC) (envelope-from jim@ks.uiuc.edu) Received: from sunnyvale.ks.uiuc.edu (sunnyvale.ks.uiuc.edu [130.126.120.168]) by halifax.ks.uiuc.edu (8.13.7/8.13.7) with ESMTP id v3LGPNje003148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Apr 2017 11:25:24 -0500 (CDT) Received: from localhost (jim@localhost) by sunnyvale.ks.uiuc.edu (8.14.4/8.14.4/Submit) with ESMTP id v3LGPNIw098654; Fri, 21 Apr 2017 11:25:23 -0500 X-Authentication-Warning: sunnyvale.ks.uiuc.edu: jim owned process doing -bs Date: Fri, 21 Apr 2017 11:25:23 -0500 (CDT) From: Jim Phillips To: Rick Macklem cc: Doug Rabson , "freebsd-fs@freebsd.org" Subject: Re: NFSv4 Linux client atime for exclusive create In-Reply-To: Message-ID: References: , MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 16:39:34 -0000 Tested the new patch and it fixes the issue (as did the old one). Jim On Thu, 20 Apr 2017, Rick Macklem wrote: > Doug Rabson wrote: >> That was actually going to me my next suggestion, honest. Hopefully that fixes the >problem, if not its a bug in the Linux client. > Yep, the attached patch fixed the problem. > > I wrote: >> I'll come up with a patch that sets the atime bit in the EXCLUSIVE4 Open >> reply and see if that changes the Linux client. > The attached patch sets the TIMEACCESS bit in the reply for both NFSv4.0 and NFSv4.1 > and fixes the problem for both cases for a quick test with the Linux client. (With this > bit set in the reply, Linux sets TIMEACCESSSET in the Setattr.) > > Doug Rabson wrote: >> Is the client using EXCLUSIVE4 or EXCLUSIVE4_1 for the open? If its EXCLUSIVE4_1, i.e. the >mode which allows attribute setting during the open, the client should use the value of >the supattr_exclcreat attribute (see section 5.8.1.14 of rfc5661) to figure out what >attributes can be set. In this case, supattr_exclcreat should not include atime which should > The FreeBSD NFSv4.1 server does exclude atime from the supattr_exclcreat bitset and > it checks for it set and returns the correct error. > However, like NFSv4.0, the code didn't set the TIMEACCESS attribute bit in the > EXCLUSIVE4_1 reply. (The attached little patch fixes this for both NFSv4.0 and NFSV4.1.) > > Thanks everyone for your help. > > I am thinking that storing the create_verifier in an extended attribute for file > systems that support extended attributes is a good idea, since it will allow NFSv4.1 > clients to avoid following the Open/Exclusive4_1 with a Setattr RPC. > Anyone else have an opinion w.r.t. this? > (I'll leave this for a future commit, depending on what others think of the idea.) > > I will probably commit the attached patch soon, rick > ps: Jim, I don't think there is any point in testing the other patch, although I suspect > it would fix the problem. You could test this one, if you can easily do it. > pss: My only excuse for never doing this is that it is one sentence in an RFC of > several hundred pages;-) > From owner-freebsd-fs@freebsd.org Fri Apr 21 19:51:43 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9083FD49071 for ; Fri, 21 Apr 2017 19:51:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670065.outbound.protection.outlook.com [40.107.67.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 41DD7A9B for ; Fri, 21 Apr 2017 19:51:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM (10.169.141.138) by YQBPR01MB0177.CANPRD01.PROD.OUTLOOK.COM (10.169.141.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Fri, 21 Apr 2017 19:51:39 +0000 Received: from YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM ([10.169.141.138]) by YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM ([10.169.141.138]) with mapi id 15.01.1047.017; Fri, 21 Apr 2017 19:51:39 +0000 From: Rick Macklem To: Jim Phillips CC: Doug Rabson , "freebsd-fs@freebsd.org" Subject: Re: NFSv4 Linux client atime for exclusive create Thread-Topic: NFSv4 Linux client atime for exclusive create Thread-Index: AQHStW9Xwd3iU1MkQkKHy7u7vlbe/6HM0kmAgABXYs2AABEAkYAAvc8AgAD5RDaAARsjgIAAOWwo Date: Fri, 21 Apr 2017 19:51:39 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ks.uiuc.edu; dkim=none (message not signed) header.d=none;ks.uiuc.edu; dmarc=none action=none header.from=uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YQBPR01MB0177; 7:0wgqwbPLyu0eYJSOyC6RL3YUaHBOWlE41IaBKU5ML/3eau+v1gM9N8OC6v/ulXj3D0/ka1jZg4nq9fnCE5kXqgcs8aZURtHIcxf8T8e+C5taUwFtn1C90PYXmdpSpnwOO/TrJ9ibzSutWRtIlr8/YkvosiIGGWWbCzEKbHeLi7nuDcjWzBmfrl9M2Nmu6BsP2112OFi5NtmgnKE88FmCuQNS32wpqMa2onJ3mCQf01i3H6AufWG17qO737zzMEq9zgHbCMpU8tZBNLAImiV9XdK4jRVjOrJK04WQ5pG7pOH6aIviYroPjTQycuIOJiGSlc40J+ukSzul7QByeZrbHA== x-ms-office365-filtering-correlation-id: 3021b9ef-765f-4013-f569-08d488efd37f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:YQBPR01MB0177; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:YQBPR01MB0177; BCL:0; PCL:0; RULEID:; SRVR:YQBPR01MB0177; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39400400002)(39410400002)(39850400002)(24454002)(377454003)(8936002)(5890100001)(53936002)(3280700002)(25786009)(53546009)(6436002)(77096006)(6506006)(74316002)(122556002)(110136004)(33656002)(38730400002)(93886004)(86362001)(102836003)(54906002)(305945005)(3660700001)(2171002)(189998001)(6246003)(229853002)(55016002)(4326008)(74482002)(76176999)(81166006)(54356999)(50986999)(5660300001)(7696004)(6916009)(2906002)(2900100001)(8676002)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR01MB0177; H:YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 19:51:39.2301 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR01MB0177 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 19:51:43 -0000 Ok. Thanks for testing it. It is committed to head and will be MFC'd in a couple of weeks. Sorry it was broken for sooooo looonnnggg, rick ________________________________________ From: Jim Phillips Sent: Friday, April 21, 2017 12:25:23 PM To: Rick Macklem Cc: Doug Rabson; freebsd-fs@freebsd.org Subject: Re: NFSv4 Linux client atime for exclusive create Tested the new patch and it fixes the issue (as did the old one). Jim On Thu, 20 Apr 2017, Rick Macklem wrote: > Doug Rabson wrote: >> That was actually going to me my next suggestion, honest. Hopefully that= fixes the >problem, if not its a bug in the Linux client. > Yep, the attached patch fixed the problem. > > I wrote: >> I'll come up with a patch that sets the atime bit in the EXCLUSIVE4 Open >> reply and see if that changes the Linux client. > The attached patch sets the TIMEACCESS bit in the reply for both NFSv4.0 = and NFSv4.1 > and fixes the problem for both cases for a quick test with the Linux clie= nt. (With this > bit set in the reply, Linux sets TIMEACCESSSET in the Setattr.) > > Doug Rabson wrote: >> Is the client using EXCLUSIVE4 or EXCLUSIVE4_1 for the open? If its EXCL= USIVE4_1, i.e. the >mode which allows attribute setting during the open, th= e client should use the value of >the supattr_exclcreat attribute (see sect= ion 5.8.1.14 of rfc5661) to figure out what >attributes can be set. In this= case, supattr_exclcreat should not include atime which should > The FreeBSD NFSv4.1 server does exclude atime from the supattr_exclcreat= bitset and > it checks for it set and returns the correct error. > However, like NFSv4.0, the code didn't set the TIMEACCESS attribute bit i= n the > EXCLUSIVE4_1 reply. (The attached little patch fixes this for both NFSv4.= 0 and NFSV4.1.) > > Thanks everyone for your help. > > I am thinking that storing the create_verifier in an extended attribute f= or file > systems that support extended attributes is a good idea, since it will al= low NFSv4.1 > clients to avoid following the Open/Exclusive4_1 with a Setattr RPC. > Anyone else have an opinion w.r.t. this? > (I'll leave this for a future commit, depending on what others think of t= he idea.) > > I will probably commit the attached patch soon, rick > ps: Jim, I don't think there is any point in testing the other patch, alt= hough I suspect > it would fix the problem. You could test this one, if you can easily= do it. > pss: My only excuse for never doing this is that it is one sentence in an= RFC of > several hundred pages;-) > From owner-freebsd-fs@freebsd.org Fri Apr 21 20:44:51 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A40DAD4952E for ; Fri, 21 Apr 2017 20:44:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 857AE1E76 for ; Fri, 21 Apr 2017 20:44:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3LKipxc015476 for ; Fri, 21 Apr 2017 20:44:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 218218] bad atime after cp on linux nfs4 clients Date: Fri, 21 Apr 2017 20:44:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rmacklem@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: bug_status assigned_to flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 20:44:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218218 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress Assignee|freebsd-fs@FreeBSD.org |rmacklem@FreeBSD.org Flags| |mfc-stable10?, | |mfc-stable11? --- Comment #4 from Rick Macklem --- Commit r317236 in head/current fixes this and will be MFC'd in 2 weeks. Thanks go to Jim for reporting this and testing the patch. --=20 You are receiving this mail because: You are the assignee for the bug.=