Hi Cyril,
But: Isn't there an implicit expectation for a space guarantee associated
with a dataset? In other words, if a dataset has 1GB of data, isn't it
natural to expect to be able to overwrite that space with other data? One
I'd say that expectation is not [always] valid. Assume you have a
dataset of 1GB of data and the pool free space is 200 MB. You are
cloning that dataset and trying to overwrite the data on the cloned
dataset. You will hit "no more space left on device" pretty soon.
Wonders of virtualization :)
The point I wanted to make is that by defining a (ref)reservation for that
clone, ZFS won't even create it if space does not suffice:
r...@haggis:~# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
rpool 416G 187G 229G 44% ONLINE -
r...@haggis:~# zfs clone -o refreservation=230g
rpool/export/home/slink/t...@zfs-auto-snap:frequent-2009-11-03-22:04:46 rpool/test
cannot create 'rpool/test': out of space
I don't see how a similar guarantee could be given with de-dup.
Nils
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
