From owner-freebsd-current@freebsd.org Wed Aug 10 16:53:35 2016 Return-Path: Delivered-To: freebsd-current@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 28F16BB513E for ; Wed, 10 Aug 2016 16:53:35 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 DBBB918A7; Wed, 10 Aug 2016 16:53:34 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yw0-x230.google.com with SMTP id z8so28807793ywa.1; Wed, 10 Aug 2016 09:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+5/cZII9/KTXeU0bSHA5RkOosfiroR+aAW2DScxYW9U=; b=awLwJOqjPNU66MaBYcXXK+kncIO9hvSGfr0KLKvMlET9omnPpR7Sw9x3puYaon83UZ aNGLmOK7w+lrNN6PQg/OfPFUjOwJhKnSPFDK6qFn0BF4U7bVOXZxxa2vfDMX0pLpO7/S EPcZy8p1Za1yYxLJg9/MaQZCKhUgfLVrK68tUNFVfMjcTLfXvU8V52/SHf6zw81JjABQ KPdTyfPdyiXRrY0KkvD7qB5+L3/OpJbb79CBQLPJTVkPNVF+UjpStoWubBdcqlYWND2T b1Wym8uQG7eUFv0WqzaZsyexBaiAwt+D+28qyiYycXRqhOQpVbVgoUN89mTHS2u0NJFZ H9+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+5/cZII9/KTXeU0bSHA5RkOosfiroR+aAW2DScxYW9U=; b=Hcd1khntGUGJejVjX8yrnM95p4Gxka0uV15EukcYdnv7ep0accapaIfKc7+y4dRDoW O2qJOEVYh2AOP0UP9m4ngvm3/LYzHJeQgYUSrATPRdseW1y6KZjPc0c/MUjYBzMyRdiL v5hFcE31jBmUQHJgMMwM8VMVH7Dcqil2YmefC6hHRvIImPN0GVax+7+84ibGCM2D1dDu RC7wi7YEAEbN+BqPhEVb9oPE6EeOVeiBCNCpQ2wtMaLhRAlNcTpWS4v3FM0HBvVuE9Xt fp9shZG6w+nvKf9E2jMXnq82PpLwB5PfK+Xue++wqApl/M2EeE/OyUTcN24lSJ7HDrim lOyw== X-Gm-Message-State: AEkoout+wjiaA5julH8knEaVQjzfR/utkJVqcNGZRWhVn/Irza7n0hYii0Zy428UsdlDP5vYlghuYnVvFocPng== X-Received: by 10.129.164.9 with SMTP id b9mr3495573ywh.145.1470848013834; Wed, 10 Aug 2016 09:53:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.51.150 with HTTP; Wed, 10 Aug 2016 09:53:33 -0700 (PDT) In-Reply-To: <196319fe-8113-bb2d-74b7-fbdd3369d988@freebsd.org> References: <196319fe-8113-bb2d-74b7-fbdd3369d988@freebsd.org> From: Ultima Date: Wed, 10 Aug 2016 12:53:33 -0400 Message-ID: Subject: Re: Possible zpool online, resilvering issue To: Stefan Esser Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 16:53:35 -0000 Hello, > I didn't see any reply on the list, so I thought I might let you know Sorry, never received this reply (till now) xD >what I assume is happening: > ZFS never updates data in place, which affects inode updates, e.g. if > a file has been read and access times must be updated. (For that reason, > many ZFS file systems are configured to ignore access time updates). > Even if there were only R/O accesses to files in the pool, there will > have been updates to the inodes, which were missed by the offlined > drives (unless you ignore atime updates). > But even if there are no access time updates, ZFS might have written > new uberblocks and other meta information. Check the POOL history and > see if there were any TXGs created during the scrub. > If you scrub the pooll while it is off-line, it should stay stable > (but if any information about the scrub, the offlining of drives etc. > is recorded in the pool's history log, differences are to be expected). > Just my $.02 ... > Regards, STefan Thanks for the reply, I'm not completely sure what would be considered a TXG. Maintained normal operations during most this noise and this pool has quite a bit of activity during normal operations. My zpool history looks like it gos on forever and the last scrub is showing it repaired 9.48G. That was for all these access time updates? I guess that would be a little less then 2.5G per disk worth. The zpool history looks like it gos on forever (733373 lines). This pool has much of this activity with poudriere. All the entries I see are clone, destroy, rollback and snapshotting. I can't really say how much but at least 500 (prob much more than that) entries between the last two scrubs. Atime is off on all datasets. So to be clear, this is expected behavior with atime=off + TXGs during offline time? I had thought that the resilver after onlining the disk would bring that disk up-to-date with the pool. I guess my understanding was a bit off. Ultima