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. Logrotate还有谁记得它？？

    我发现很多人的服务器上都运行着一些诸如每天切分Nginx日志之类的CRON脚本,大家似乎遗忘了Logrotate,争相发明自己的轮子,这真是让人沮丧啊!就好比明明身边躺着现成的性感美女,大家却忙着自娱 ...

  2. Spring学习13-中IOC(工厂模式)和AOP(代理模式)的详细解释

    我们是在使用Spring框架的过程中,其实就是为了使用IOC,依赖注入,和AOP,面向切面编程,这两个是Spring的灵魂. 主要用到的设计模式有工厂模式和代理模式. IOC是工厂模式参考:设计模式- ...

  3. Java并发知识点总结

    前言:Java语言一个重要的特点就是内置了对并发的支持,让Java大受企业和程序员的欢迎.同时,如果想要提升自己的技术,Java并发知识必不可少,这里简单整理了一些相关内容,希望可以起到抛砖引玉的作用 ...

  4. window.location.hash 使用

    [转]http://www.cnblogs.com/nifengs/p/5104763.html location是javascript里边管理地址栏的内置对象,比如location.href就管理页 ...

  5. UVA11374_Airport Express

    给一个无向图,有的边是特殊边,最多可以取一条特殊边,求最短路,并且输出路径. 这样考虑,加入所有非特殊边,求出每个点到起点和终点的最短路.然后加入特殊边的时候,如果取当前这条特殊边,那么答案会是两点预 ...

  6. ibatis解决sql注入问题

    原文: http://blog.csdn.net/scorpio3k/article/details/7610973 对于ibaits参数引用可以使用#和$两种写法,其中#写法会采用预编译方式,将转义 ...

  7. MT【160】格点

    (2017年清华大学  THUSSAT) 把不超过实数 $x$ 最大整数记为 $[x]$,任取互质且不小于 3 的正奇数 $m,n$,令$$I=\sum_{i=1}^{\frac{m-1}{2}}\l ...

  8. 【刷题】洛谷 P4209 学习小组

    题目描述 共有n个学生,m个学习小组,每个学生只愿意参加其中的一些学习小组,且一个学生最多参加k个学习小组.每个学生参加学习小组财务处都收一定的手续费,不同的学习小组有不同的手续费.若有a个学生参加第 ...

  9. 一步步创建第一个Docker App —— 3. 创建一个集群Swarm

    原文:https://docs.docker.com/engine/getstarted-voting-app/create-swarm/ 初始化集群 Swarm 1. 使用 ssh 命令登录 man ...

  10. ip netns

    虚拟化网络都是基于netns实现,不管是昨日的openstack,还是今日的docker. ip netns ip-netns - process network namespace manageme ...