Understanding the Space Used by ZFS

By Brian Leonard on Sep 28, 2010

Until recently, I've been confused and frustrated by the zfs list output as I try to clear up space on my hard drive.

Take this example using a 1 GB zpool:

bleonard@os200906:~# mkfile 1G /dev/dsk/disk1

bleonard@os200906:~# zpool create tank disk1

bleonard@os200906:~# zpool list tank

NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT

tank  1016M    73K  1016M     0%  ONLINE  -

Now let's create some files and snapshots:

bleonard@os200906:~# mkfile 100M /tank/file1

bleonard@os200906:~# zfs snapshot tank@snap1

bleonard@os200906:~# mkfile 100M /tank/file2

bleonard@os200906:~# zfs snapshot tank@snap2

bleonard@os200906:~# zfs list -t all -r tank

NAME         USED  AVAIL  REFER  MOUNTPOINT

tank         200M   784M   200M  /tank

tank@snap1    17K      -   100M  -

tank@snap2      0      -   200M  -

The output here looks as I'd expect. I have used 200 MB of disk space, neither of which is used by the snapshots. snap1 refers to 100 MBs of data (file1) and snap2 refers to 200 MBs of data (file1 and file2).

Now let's delete file1 and look at our zfs list output again:

bleonard@os200906:~# rm /tank/file1

bleonard@os200906:~# zpool scrub tank

bleonard@os200906:~# zfs list -t all -r tank

NAME         USED  AVAIL  REFER  MOUNTPOINT

tank         200M   784M   100M  /tank

tank@snap1    17K      -   100M  -

tank@snap2    17K      -   200M  -

Only 1 thing has changed - tank now only refers to 100 MB of data. file1 has been deleted and is only referenced by the snapshots. So why don't the snapshots reflect this in their USED column? You may think we should show 100 MB used by snap1, however, this would be misleading as deleting snap1 has no effect on the data used by the tank file system. Deleting snap1 would only free up 17K of disk space. We'll come back to this test case in a moment.

There is an option to get more detail on the space consumed by the snapshots. Although you can pretty easily deduct from the example above that the snapshots are using 100 MB, by using the zfs space option you can save yourself from doing the math:

bleonard@os200906:~# zfs list -t all -o space -r tank

NAME        AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD

tank         784M   200M      100M    100M              0       154K

tank@snap1      -    17K         -       -              -          -

tank@snap2      -    17K         -       -              -          -

Here we can clearly see that of the 200 MB used by our file system, 100 MB is used by snapshots (file1) and 100 MB is used by the dataset itself (file2). Of course, there are other factors that can affect the total amount used - see the zfs man page for details.

Now, if we were to delete snap1 (we know this is safe, because it's not using any space):

bleonard@os200906:~# zfs destroy tank@snap1

bleonard@os200906:~# zfs list -t all -r tank

NAME         USED  AVAIL  REFER  MOUNTPOINT

tank         200M   784M   100M  /tank

tank@snap2   100M      -   200M  -

We can see that snap2 now shows 100 MBs used. If I were to delete snap2, I would be deleting 100 MB of data (or reclaiming 100 MB of space):

Now let's look at a more realistic example - my home directory where I have Time Slider running:

bleonard@opensolaris:~$ zfs list -t all -r -o space rpool/export/home

NAME                                                       AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD

rpool/export/home                                          25.4G  35.2G     17.9G   17.3G              0          0

rpool/export/home@zfs-auto-snap:monthly-2010-08-03-09:30       -   166M         -       -              -          -

rpool/export/home@zfs-backup-2010-08-12-15:30                  -  5.06M         -       -              -          -

rpool/export/home@zfs-backup-2010-08-12-15:56                  -  5.15M         -       -              -          -

rpool/export/home@zfs-backup-2010-08-31-14:12                  -  54.6M         -       -              -          -

rpool/export/home@zfs-auto-snap:monthly-2010-09-01-00:00       -  53.8M         -       -              -          -

rpool/export/home@zfs-auto-snap:weekly-2010-09-08-00:00        -  95.8M         -       -              -          -

rpool/export/home@zfs-backup-2010-09-09-09:04                  -  53.9M         -       -              -          -

rpool/export/home@zfs-auto-snap:weekly-2010-09-15-00:00        -  2.06G         -       -              -          -

rpool/export/home@zfs-auto-snap:weekly-2010-09-22-00:00        -  89.7M         -       -              -          -

rpool/export/home@zfs-auto-snap:frequent-2010-09-28-11:00      -  18.3M         -       -              -          -

rpool/export/home@zfs-auto-snap:frequent-2010-09-28-11:15      -   293K         -       -              -          -

rpool/export/home@zfs-auto-snap:frequent-2010-09-28-11:30      -   293K         -       -              -          -

rpool/export/home@zfs-auto-snap:frequent-2010-09-28-11:45      -  1.18M         -       -              -          -

My snapshots are consuming almost 18 GBs of space. However, it would appear that I could only reclaim about 2.5 GBs of space by deleting all of my snapshots. In reality, 15.5 GBs of space is referenced by 2 or more snapshots.

I can get a better idea of which snapshots might reclaim the most space by removing the space option so I get the REFER field in the output:

bleonard@opensolaris:~$ zfs list -t all -r rpool/export/home

NAME                                                        USED  AVAIL  REFER  MOUNTPOINT

rpool/export/home                                          35.2G  25.4G  17.3G  /export/home

rpool/export/home@zfs-auto-snap:monthly-2010-08-03-09:30    166M      -  15.5G  -

rpool/export/home@zfs-backup-2010-08-12-15:30              5.06M      -  28.5G  -

rpool/export/home@zfs-backup-2010-08-12-15:56              5.15M      -  28.5G  -

rpool/export/home@zfs-backup-2010-08-31-14:12              54.6M      -  15.5G  -

rpool/export/home@zfs-auto-snap:monthly-2010-09-01-00:00   53.8M      -  15.5G  -

rpool/export/home@zfs-auto-snap:weekly-2010-09-08-00:00    95.8M      -  15.5G  -

rpool/export/home@zfs-backup-2010-09-09-09:04              53.9M      -  17.4G  -

rpool/export/home@zfs-auto-snap:weekly-2010-09-15-00:00    2.06G      -  19.4G  -

rpool/export/home@zfs-auto-snap:weekly-2010-09-22-00:00    89.7M      -  15.5G  -

rpool/export/home@zfs-auto-snap:frequent-2010-09-28-11:15   293K      -  17.3G  -

rpool/export/home@zfs-auto-snap:frequent-2010-09-28-11:30   293K      -  17.3G  -

rpool/export/home@zfs-auto-snap:frequent-2010-09-28-11:45  1.18M      -  17.3G  -

rpool/export/home@zfs-auto-snap:hourly-2010-09-28-12:00        0      -  17.3G  -

rpool/export/home@zfs-auto-snap:frequent-2010-09-28-12:00      0      -  17.3G  -

In the above output, I can see that 2 snapshots, taken 26 seconds apart, are referring to 28.5 GBs of disk space. If I were to delete one of those snapshots and check the zfs list output again:

bleonard@opensolaris:~$ pfexec zfs destroy rpool/export/home@zfs-backup-2010-08-12-15:30

bleonard@opensolaris:~$ zfs list -t all -r rpool/export/home

NAME                                                        USED  AVAIL  REFER  MOUNTPOINT

rpool/export/home                                          35.2G  25.4G  17.3G  /export/home

rpool/export/home@zfs-auto-snap:monthly-2010-08-03-09:30    166M      -  15.5G  -

rpool/export/home@zfs-backup-2010-08-12-15:56              12.5G      -  28.5G  -

rpool/export/home@zfs-backup-2010-08-31-14:12              54.6M      -  15.5G  -

rpool/export/home@zfs-auto-snap:monthly-2010-09-01-00:00   53.8M      -  15.5G  -

rpool/export/home@zfs-auto-snap:weekly-2010-09-08-00:00    95.8M      -  15.5G  -

rpool/export/home@zfs-backup-2010-09-09-09:04              53.9M      -  17.4G  -

rpool/export/home@zfs-auto-snap:weekly-2010-09-15-00:00    2.06G      -  19.4G  -

rpool/export/home@zfs-auto-snap:weekly-2010-09-22-00:00    89.7M      -  15.5G  -

rpool/export/home@zfs-auto-snap:frequent-2010-09-28-11:15   293K      -  17.3G  -

rpool/export/home@zfs-auto-snap:frequent-2010-09-28-11:30   293K      -  17.3G  -

rpool/export/home@zfs-auto-snap:frequent-2010-09-28-11:45  1.18M      -  17.3G  -

rpool/export/home@zfs-auto-snap:frequent-2010-09-28-12:00   537K      -  17.3G  -

I can now clearly see that the remaining snapshot is using 12.5 GBs of space and deleting this snapshot would reclaim much needed space on my laptop:

bleonard@opensolaris:~$ zpool list rpool

NAME    SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT

rpool   149G   120G  28.5G    80%  ONLINE  -

bleonard@opensolaris:~$ pfexec zfs destroy rpool/export/home@zfs-backup-2010-08-12-15:56

bleonard@opensolaris:~$ zpool list rpool

NAME    SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT

rpool   149G   108G  41.0G    72%  ONLINE  -

And that should be enough to keep Time Slider humming along smoothly and prevent the warning dialog from appearing (lucky you if you haven't seen that yet).

 
 
https://blogs.oracle.com/observatory/entry/understanding_the_space_used_by

Understanding the Space Used by ZFS -- (转)的更多相关文章

  1. linux概念之分区与文件系统

    分区类型 [root@-shiyan dev]# fdisk /dev/sda WARNING: DOS-compatible mode is deprecated. It's strongly re ...

  2. User space 与 Kernel space

    学习 Linux 时,经常可以看到两个词:User space(用户空间)和 Kernel space(内核空间). 简单说,Kernel space 是 Linux 内核的运行空间,User spa ...

  3. Understanding, Operating and Monitoring Apache Kafka

    Apache Kafka is an attractive service because it's conceptually simple and powerful. It's easy to un ...

  4. A Beginner's Guide To Understanding Convolutional Neural Networks(转)

    A Beginner's Guide To Understanding Convolutional Neural Networks Introduction Convolutional neural ...

  5. Understanding CMS GC Logs--转载

    原文地址:https://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs Understanding CMS GC Logs By Po ...

  6. Understanding G1 GC Logs--转载

    原文地址:https://blogs.oracle.com/poonam/entry/understanding_g1_gc_logs Understanding G1 GC Logs By Poon ...

  7. [ZZ] Understanding 3D rendering step by step with 3DMark11 - BeHardware >> Graphics cards

    http://www.behardware.com/art/lire/845/ --> Understanding 3D rendering step by step with 3DMark11 ...

  8. Understanding Virtual Memory

    Understanding Virtual Memory by Norm Murray and Neil Horman Introduction Definitions The Life of a P ...

  9. （转）A Beginner's Guide To Understanding Convolutional Neural Networks Part 2

    Adit Deshpande CS Undergrad at UCLA ('19) Blog About A Beginner's Guide To Understanding Convolution ...

随机推荐

  1. screen.height && screen.width

    screen.height && screen.width how to get window max width in js screen.height; screen.width; ...

  2. 重温SQL——行转列，列转行

    行转列,列转行是我们在开发过程中经常碰到的问题.行转列一般通过CASE WHEN 语句来实现,也可以通过 SQL SERVER 2005 新增的运算符PIVOT来实现.用传统的方法,比较好理解.层次清 ...

  3. CF1088F Ehab and a weird weight formula 贪心 倍增

    CF1088F Ehab and a weird weight formula 题意 给定一棵树,点有点权,其中这棵树满足除了权值最小的点外,每个点至少有一个点权小于它的相邻点. 要求你重新构建这棵树 ...

  4. 聊聊flink的NetworkEnvironmentConfiguration

    本文主要研究一下flink的NetworkEnvironmentConfiguration NetworkEnvironmentConfiguration flink-1.7.2/flink-runt ...

  5. 【JQuery】DOM元素

    一.前言         接着上一章的内容,继续本章的学习. 二.内容 .get 获得由选择器指定的DOM元素, 可输入匹配元素的index编号 $(selector).get(index) .ind ...

  6. loj Snakes 的 Naïve Graph 【数论】

    题目链接 loj 题解 感谢珂神的指导orz 观察式子\(i \times j \equiv 1 \pmod m\),显然\(i,j\)是模\(m\)意义下成对的逆元,只需统计模\(m\)意义下存在逆 ...

  7. Linux内核设计第七周学习总结 Linux内核如何装载和启动一个可执行程序

    陈巧然原创作品 转载请注明出处 <Linux内核分析>MOOC课程http://mooc.study.163.com/course/USTC-100002900 实验目的 使用gdb跟踪s ...

  8. 解题：USACO13JAN Island Travels

    题面 好像没啥可说的,就当练码力了...... 先用BFS跑出岛屿,然后跑最短路求岛屿间的距离,最后状压DP得出答案 注意细节,码码码2333 #include<set> #include ...

  9. python之旅：字符编码

    一 了解字符编码的知识储备 一 计算机基础知识 知识储备:cpu.内存.硬盘 二 文本编辑器存取文件的原理(nodepad++,pycharm,word) #1.打开编辑器就打开了启动了一个进程,是在 ...

  10. web服务器nginx和apache的对比分析

         今天准备较详细的对比一下apache httpd与nginx两个web服务器的异同点.优缺点.由于我并不是做web开发的,所以有什么理解错误还请指出,想要了解它们是因为工作中有时候会用到它, ...