>>>>> "a" == <[EMAIL PROTECTED]> writes: >>>>> "c" == Miles Nordin <[EMAIL PROTECTED]> writes: >>>>> "n" == none <[EMAIL PROTECTED]> writes:
n> Unfortunately the USED column is of little help since it only
n> shows you the data unique to that snapshot. In my case almost
n> all data is shared amongst the snapshots so it only shows up
n> in the USED of the whole fs.
Unfortunately sounds right to me.
bash-3.2# mkfile 1m 0
bash-3.2# zfs snapshot root/export/home/carton/[EMAIL PROTECTED]
bash-3.2# zfs snapshot root/export/home/carton/[EMAIL PROTECTED]
bash-3.2# rm 0
bash-3.2# zfs list -r root/export/home/carton/t
NAME USED AVAIL REFER MOUNTPOINT
root/export/home/carton/t 1.04M 26.6G 18K /export/home/carton/t
root/export/home/carton/[EMAIL PROTECTED] 0 - 1.02M -
root/export/home/carton/[EMAIL PROTECTED] 0 - 1.02M -
It seems like taking a lot of snapshots can make 'zfs list' output
less useful.
I've trouble imagining an interface to expose the information you
want. The obvious extension of what we have now is ``show
hypothetical 'zfs list' output after I'd deleted this dataset,'' but I
think that'd be clumsy to use and inefficient to implement.
Maybe btrfs will think of something, since AIUI their model is to have
mandatory infinite snapshots, and instead of explicitly requesting
point-in-time snapshots, your manual action is to free up space by
specifying ranges of snapshot you'd like to delete. They'll likely
have some interface to answer questions like ``how much space is used
by the log between 2008-01-25 and 2008-02-22?'', and they will have
background log-quantitization daemons that delete snapshot ranges
analagous to our daemons that take snapshots.
Maybe imagining infinitely-granular snapshots is the key to a better
interface: ``show me the USED value for snapshots [EMAIL PROTECTED] - [EMAIL
PROTECTED]
inclusive,'' and you must always give a contiguous range. That's
analagous to btrfs-world's hypothetical ``show me the space consumed
by the log between these two timestamps.''
the btrfs guy in here seemed to be saying there's dedup across clone
branches, which ZFS does not do. I suppose that would complicate
space reporting and their interface to do it.
a> I really think there is something wrong with how space is
a> being reported by zfs list in terms of snapshots.
I also had trouble understanding it.
right:
conduct tests and use them to form a rational explanation of the
numbers' meanings. If you can't determine one, ask for help and try
harder. Create experiments to debunk a series of proposed, wrong
explanations. If a right explanation doesn't emerge, complain it's
broken chaos.
wrong:
use the one-word column titles to daydream about what you THINK the
numbers ought to mean if you'd designed it, and act obstinately
surprised when the actual meaning doesn't match your daydream.
One word isn't enough to get you and the designers on the same page.
You must mentally prepare yourself to accept column-meanings other
than your assumption.
Imagine the columns were given to you without headings. Or, reread
your 'zfs list' output assuming the column headings are ORANGE,
TASMANIAN_DEVIL, and BARBIE, then try to understand what each means
through experiment rather than assumption.
a> But the used seems wrong.
%$"#$%! But I can only repeat myself:
c> USED column tells you ``how much
c> space would be freed if I destroyed the thing on this row,''
AND
c> after you delete something, the USED column will
c> reshuffle,
I'd been staring at the USED column for over a year, and did not know
either of those two things until I ran the experiment in my post.
I'm not saying it's necessarily working properly, but I see no
evidence of a flaw from the numbers in the mail I posted, and in your
writeup I see a bunch of assumptions that are not worth
untangling---paragraphs-long explanations don't work for everyone,
including me. Adam, suggest you keep doing tests until you understand
the actual behavior, because at least the behavior seen in my post is
understandable and sane to me.
pgp8WqrxYZIzJ.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
