From owner-freebsd-stable@freebsd.org Wed Dec 18 16:31:43 2019 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7EF8C1E2B73 for ; Wed, 18 Dec 2019 16:31:43 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47dLB651Q3z4mBr for ; Wed, 18 Dec 2019 16:31:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f42.google.com with SMTP id p8so3156090oth.10 for ; Wed, 18 Dec 2019 08:31:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1/1OuL9VgkeMBhPQB7QzUBWGrZOYhHDLv4u/JFVe7V0=; b=V9aM4qwoH8Wx6q3sDns9BKxSynv65a88kFOKYLlroasO98h1XUn9WkSpbdBnOy6ODR JloVBHNtGea7VcibUFDuoUh2c52lx40dwydBwdS8usCkDem4OAM2aV+TQxWDie7yyZ3w 5AoG9loruIoLCyJjc/C4wA3OY4ZTCdwnZQbqL6YVxd6BlPCc3OD4BVnFjvKR8HzeeoE2 k52gXbFRNq9AJlX0TuUJU7wg+RGpv5gquMYvDIujNP8QAZiSz3sSIp5YUGbtmb3/UNzC xK+xiPrgVBUCkf6dHFCbP8L3vh5dH3fI0FStxSicsq1STZYk6DqLLXmxiNOrgueMKlAa gpFg== X-Gm-Message-State: APjAAAXUKClOLTrerQl5igLNoYaMF5oeSr/Se6CzcJljD1pxXlm6e9+7 7WbWzc2+4AJjfVnzh3qhHrLNvya9jVxHUeNBpmnD+Q== X-Google-Smtp-Source: APXvYqw4RpSmkgWITBLg9DedngsEKrAumdTkC8Pv5eWUzcYTI1buyhZ+UuBYa5xSP9mZXeumJvTCN0PmCqc8I55fmww= X-Received: by 2002:a05:6830:12cf:: with SMTP id a15mr3529879otq.222.1576686700948; Wed, 18 Dec 2019 08:31:40 -0800 (PST) MIME-Version: 1.0 References: <57da15d4-0944-982b-7d7e-d7b2571e869c@denninger.net> In-Reply-To: <57da15d4-0944-982b-7d7e-d7b2571e869c@denninger.net> From: Alan Somers Date: Wed, 18 Dec 2019 09:31:29 -0700 Message-ID: Subject: Re: ZFS and power management To: Karl Denninger Cc: FreeBSD X-Rspamd-Queue-Id: 47dLB651Q3z4mBr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.42 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[42.210.85.209.rep.mailspike.net : 127.0.0.18]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[42.210.85.209.list.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-1.07)[ip: (-0.28), ipnet: 209.85.128.0/17(-3.12), asn: 15169(-1.90), country: US(-0.05)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 16:31:43 -0000 On Wed, Dec 18, 2019 at 9:22 AM Karl Denninger wrote: > I'm curious if anyone has come up with a way to do this... > > I have a system here that has two pools -- one comprised of SSD disks > that are the "most commonly used" things including user home directories > and mailboxes, and another that is comprised of very large things that > are far less-commonly used (e.g. video data files, media, build > environments for various devices, etc.) > > The second pool has perhaps two dozen filesystems that are mounted, but > again, rarely accessed. However, despite them being rarely accessed ZFS > performs various maintenance checkpoint functions on a nearly-continuous > basis (it appears) because there's a low level, but not zero, amount of > I/O traffic to and from them. Thus if I set power control (e.g. spin > down after 5 minutes of inactivity) they never do. I could simply > export the pool but I prefer (greatly) to not do that because some of > the data on that pool (e.g. backups from PCs) is information that if a > user wants to get to it it ought to "just work." > > Well, one disk is no big deal. A rack full of them is another matter. > I could materially cut the power consumption of this box down (likely by > a third or more) if those disks were spun down during 95% of the time > the box is up, but with the "standard" way ZFS does things that doesn't > appear to be possible. > > Has anyone taken a crack at changing the paradigm (e.g. using the > automounter, perhaps?) to get around this? > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ > I have, and I found that it wasn't actually ZFS's fault. By itself ZFS wasn't initiating any background I/O whatsoever. I used a combination of fstat and dtrace to track down the culprit processes. Once I had shutdown/patched/reconfigured each of those processes, the disks stayed idle indefinitely. You might have success using the same strategy. I suspect that the automounter wouldn't help you, because any access that ought to "just work" for a normal user would likewise "just work" for whatever background process is hitting your disks right now. -Alan