For illumos-based distributions, there is a "written" and "written@" property that shows the amount of data writtent to each snapshot. This helps to clear the confusion over the way the "used" property is accounted. https://www.illumos.org/issues/1645
-- richard On Aug 29, 2012, at 11:12 AM, "Truhn, Chad" <chad.tr...@bowheadsupport.com> wrote: > All, > > I apologize in advance for what appears to be a question asked quite often, > but I am not sure I have ever seen an answer that explains it. This may also > be a bit long-winded so I apologize for that as well. > > I would like to know how much unique space each individual snapshot is using. > > I have a ZFS filesystem that shows: > > $zfs list -o space rootpool/export/home > NAME AVAIL USED USEDSNAP USEDDS > USEDREFRESERV USEDCHILD > rootpool/export/home 5.81G 14.4G 8.81G 5.54G 0 > 0 > > So reading this I see that I have a total of 14.4G of space used by this data > set. Currently 5.54 is "active" data that is available on the normal > filesystem and 8.81G used in snapshots. 8.81G + 5.54G = 14.4G (roughly). I > 100% agree with these numbers and the world makes sense. > > This is also backed up by: > > $zfs get usedbysnapshots rootpool/export/home > NAME PROPERTY VALUE > SOURCE > rootpool/export/home usedbysnapshots 8.81G - > > > Now if I wanted to see how much space any individual snapshot is currently > using I would like to think that this would show me: > > $zfs list -ro space rootpool/export/home > > NAME AVAIL USED > USEDSNAP USEDDS USEDREFRESERV USEDCHILD > rootpool/export/home 5.81G 14.4G 8.81G 5.54G > 0 0 > rootpool/export/home@week3 - 202M - - > - - > rootpool/export/home@week2 - 104M - - > - - > rootpool/export/home@7daysago - 1.37M - - > - - > rootpool/export/home@6daysago - 1.20M - - > - - > rootpool/export/home@5daysago - 1020K - - > - - > rootpool/export/home@4daysago - 342K - - > - - > rootpool/export/home@3daysago - 1.28M - - > - - > rootpool/export/home@week1 - 0 - - > - - > rootpool/export/home@2daysago - 0 - - > - - > rootpool/export/home@yesterday - 360K - - > - - > rootpool/export/home@today - 1.26M - - > - - > > > So normal logic would tell me if USEDSNAP is 8.81G and is composed of 11 > snapshots, I would add up the size of each of those snapshots and that would > roughly equal 8.81G. So time to break out the calculator: > > 202M + 104M + 1.37M + 1.20M + 1020K + 342K + 1.28M +0 +0 + 360K + 1.26M > equals....... ~312M! > > That is nowhere near 8.81G. I would accept it even if it was within 15%, but > it's not even close. That definitely not metadata or ZFS overhead or > anything. > > I understand that snapshots are just the delta between the time when the > snapshot was taken and the current "active" filesystem and are truly just > references to a block on disk rather than a "copy". I also understand how > two (or more) snapshots can reference the same block on a disk but yet there > is still only that one block used. If I delete a recent snapshot I may not > save as much space as advertised because some may be inherited by a "parent" > snapshot. But that inheritance is not creating duplicate used space on disk > so it doesn't justify the huge difference in sizes. > > But even with this logic in place there is currently 8.81G of blocks referred > to by snapshots which are not currently on the "active" filesystem and I > don't believe anyone can argue with that. Can something show me how much > space a single snapshot has reserved? > > I searched through some of the archives and found this thread > (http://mail.opensolaris.org/pipermail/zfs-discuss/2012-August/052163.html) > from early this month and I feel as if I have the same problem as the OP, but > hopefully attacking it with a little more background. I am not arguing with > discrepancies between df/du and zfs output and I have read the Oracle > documentation about it but haven't found what I feel like should be a simple > answer. I currently have a ticket open with Oracle, but I am getting answers > to all kinds of questions except for the question I am asking so I am hoping > someone out there might be able to help me. > > I am a little concerned I am going to find out that there is no real way to > show it and that makes for one sad SysAdmin. > > Thanks, > Chad > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- ZFS Performance and Training richard.ell...@richardelling.com +1-760-896-4422
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
