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. BZOJ3267/3272 KC采花/Zgg吃东西（线段树）

    直接维护选k个子段时的最优解似乎也可以做,然而复杂度是O(nk2logn),显然跑不过. 考虑一种费用流做法.序列里每个点拆成入点和出点,源连入汇连出,入点和出点间连流量1费用ai的边,相邻点出点向入 ...

  2. The Best Path HDU - 5883（欧拉回路 && 欧拉路径）

    The Best Path Time Limit: 9000/3000 MS (Java/Others)    Memory Limit: 65535/32768 K (Java/Others)Tot ...

  3. c# 方法参数 params 的试用

    //添加方法 public void test(params string[] messages) { } //调用方法 test("aaa","bbb",&q ...

  4. 【spring】- springmvc 工作原理

    原理 本质是将DispatcherServlet及关联的Spring上下文环境的初始化工作织入Servlet的生命周期内,将外部WEB请求转换为Spring Bean能处理的形式,然后将处理后的结果借 ...

  5. 51nod 1785 数据流中的算法 | STL的应用

    51nod 1785 数据流中的算法 题面 动态求平均数.方差.中位数. 题解 这道题的坑: 平均数在答案中是向下取整输出并在后面添加".00" 方差:平方的平均数减去平均数的平方 ...

  6. 基于Java visualvm的可视化监控的使用

    1 Java visualVM可视化监控工具打开方式 ctrl + r 快捷键调出运行窗口,输出 jvisualvm指令,即可打开java visualVM工具.详情如下图: 2 Java Visua ...

  7. 添加jar包需注意

    对于纯java项目使用的是本地自己的JRE,通过build path导入的JAR包的配置信息会出现在应用的”.classpath”文件中,ClassLoader会智能地去加载这些JAR. 而Web项目 ...

  8. Chapter 5(串)

    1.kmp #include <stdio.h> #include <stdlib.h> #include <stdbool.h> #include <str ...

  9. python基础之模块之序列化

    ---什么是序列化(picking)? 我们把变量从内存中变成可存储或传输的过程称之为序列化. 序列化之后,就可以把序列化后的内容写入磁盘,或者通过网络传输到别的机器上. 反过来,把变量内容从序列化的 ...

  10. 在 mac 上添加想要的命令

    习惯了 Linux 下的 ll 命令,Mac 终端没有这个命令很不舒服.可以将 ll 别名解决这个问题: 打开终端,进入到当前根目录 cd ~ 编辑.bash_profile文件 vim .bash_ ...