From owner-freebsd-fs@FreeBSD.ORG  Mon Sep 30 09:16:43 2013
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTP id 03784C3C
 for <freebsd-fs@FreeBSD.org>; Mon, 30 Sep 2013 09:16:43 +0000 (UTC)
 (envelope-from borjam@sarenet.es)
Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65])
 by mx1.freebsd.org (Postfix) with ESMTP id BA9CE25C0
 for <freebsd-fs@FreeBSD.org>; Mon, 30 Sep 2013 09:16:42 +0000 (UTC)
Received: from [172.16.1.206] (izaro.sarenet.es [192.148.167.11])
 by proxypop04.sare.net (Postfix) with ESMTPSA id 26C8F9DC513;
 Mon, 30 Sep 2013 11:07:38 +0200 (CEST)
Subject: Re: zfs: the exponential file system from hell
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Borja Marcos <borjam@sarenet.es>
In-Reply-To: <52457A32.2090105@fsn.hu>
Date: Mon, 30 Sep 2013 11:07:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <77F6465C-4E76-4EE9-88B5-238FFB4E0161@sarenet.es>
References: <52457A32.2090105@fsn.hu>
To: Attila Nagy <bra@fsn.hu>
X-Mailer: Apple Mail (2.1283)
Cc: freebsd-fs@FreeBSD.org
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Sep 2013 09:16:43 -0000


On Sep 27, 2013, at 2:29 PM, Attila Nagy wrote:

> Hi,
>=20
> Did anyone try to fill a zpool with multiple zfs in it and graph the =
space accounted by df and zpool list?
> If not, here it is:
> =
https://picasaweb.google.com/104147045962330059540/FreeBSDZfsVsDf#59282714=
43977601554

There is a fundamental problem with "df" and ZFS. df is based on the =
assumption that each file system has=20
a fixed maximum size (generally the size of the disk partition on which =
it resides).

ZFS is really different, though. Unless you assign them fixed sizes, it =
works much like a virtual memory system. There
is a large pool shared by all the datasets, and *any* of them can grow =
to the maximum pool size, that's the data
"df " shows.

With virtual storage allocation, compression and deduplication you can =
no longer make the old assumptions you made
in the old days.=20

Anyway, in a system with variable datasets "df" is actually meaningless =
and you should rely on "zpool list", which gives you
the real size, allocated space, free space, etc.


% zpool list
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
pool  1.59T   500G  1.11T    30%  1.00x  ONLINE  -
%=20

Times change, embracing the satanic filesystem implies that you have to =
change your mindset (and your scripts!)  :)








Borja.