From owner-freebsd-fs@FreeBSD.ORG Thu Dec 4 22:53:00 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93C3B4F7 for ; Thu, 4 Dec 2014 22:53:00 +0000 (UTC) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6785B287 for ; Thu, 4 Dec 2014 22:53:00 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id et14so18970763pad.29 for ; Thu, 04 Dec 2014 14:52:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=PrlCjIupNP1mTA5a7CPuA2G/GbE39oBU5m5hTMEUew0=; b=TPvmuqw7OJJ2gZ0cGfisOf2KeyrB0UmXb33PJoFxjfXt0XRL+yG3hQ5njXWhQmapPz RXbBcfZ8IZA5I+LA5iZHHoPJRW9uWs2fAd0QnII4VXwoPFJ0iZKqykirf5iqaaVWlWZ1 zkxkvsVQF2d4SxgcG+dM1/hBTEYsdTX3ZfOs2jtAzKAeLN1IwiY0nkeKM4wu1Q/IubCC OvptzFbA24iqgjBU1CxpfuqNqt808RakNcNlQYpIgPkuz4sGUp0meVX/Mw8vt7tJ0YdZ wqc2cJBPJZvflyuOlgKkcIc0bGbrl2uCFEVLPWrVooKQmRcWGKenCVK8qNJlYbX1Cg36 v1Aw== X-Gm-Message-State: ALoCoQlllVClPLFNsDGSACUzrfGdKNfpg6ltBuaA0heyJj2zunmNE6E7XOmE3Fvgtv7TnSvlhA80 X-Received: by 10.70.21.168 with SMTP id w8mr22649181pde.95.1417733574596; Thu, 04 Dec 2014 14:52:54 -0800 (PST) Received: from hobbes.nimgs.com (wsip-184-188-181-148.sd.sd.cox.net. [184.188.181.148]) by mx.google.com with ESMTPSA id kj3sm10911379pdb.85.2014.12.04.14.52.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 14:52:53 -0800 (PST) From: Craig Yoshioka X-Google-Original-From: Craig Yoshioka Subject: remove or make reserved ZFS space configurable Message-Id: <1D872444-CF75-48FF-BFDE-51885A3BBF9B@nimgs.com> Date: Thu, 4 Dec 2014 14:52:51 -0800 To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 22:53:00 -0000 I saw an earlier thread about an update that added (invisible) reserved = space for ZFS Pools. I use ZFS as the filesystem for my backup disks. This allows me to = occasionally rotate through old backup drives and scrub them to detect = damage without having to implement such detection in my backup system. = I can then re-backup bad files, or reconstruct a backup drive, if = necessary. I configured my backup software to leave ~100GB free (3TB = drives) and I was not amused when I recently mounted a set of backup = drives, and puzzled over why they were now "full=E2=80=9D and if I had = messed up and lost data. And even with the reserved space, while = troubleshooting I tried a rm and it failed (so what's the point of the = reserved space?). I don't care about the performance degradation on these drives... these = drives are 99% single-write. I agree, that having reserved space as a = default is probably good, but why isn't this implemented as a = configurable option (like a default zpool/zfs quota property)? Instead = it looks like I have to wait for an update to make it to release and = then set some kernel option? To prevent accidental filling of a pool, I = usually create a zfs filesystem on each pool with about ~10% reserved = space, is this solution not workable? =20 Thanks, -Craig