On Fri, Sep 14, 2012 at 11:07 PM, Bill Sommerfeld <sommerf...@hamachi.org>wrote:
> On 09/14/12 22:39, Edward Ned Harvey > (**opensolarisisdeadlongliveopens**olaris) > wrote: > >> From: >> zfs-discuss-bounces@**opensolaris.org<zfs-discuss-boun...@opensolaris.org>[mailto: >>> zfs-discuss- >>> boun...@opensolaris.org] On Behalf Of Dave Pooser >>> >>> Unfortunately I did not realize that zvols require disk space sufficient >>> to duplicate the zvol, and my zpool wasn't big enough. After a false >>> start >>> (zpool add is dangerous when low on sleep) I added a 250GB mirror and a >>> pair of 3GB mirrors to miniraid and was able to successfully snapshot the >>> zvol: miniraid/RichRAID@exportable >>> >> >> This doesn't make any sense to me. The snapshot should not take up any >> (significant) space on the sending side. It's only on the receiving side, >> trying to receive a snapshot, that you require space. Because it won't >> clobber the existing zvol on the receiving side until the complete new zvol >> was received to clobber it with. >> >> But simply creating the snapshot on the sending side should be no problem. >> > > By default, zvols have reservations equal to their size (so that writes > don't fail due to the pool being out of space). > > Creating a snapshot in the presence of a reservation requires reserving > enough space to overwrite every block on the device. > > You can remove or shrink the reservation if you know that the entire > device won't be overwritten. > > This is the right idea, but it's actually the refreservation (reservation on referenced space) that has this behavior, and is set by default on zvols. The reservation (on "used" space) covers the space consumed by snapshots, so taking a snapshot doesn't affect it (at first, but the reservation will be consumed as you overwrite space and the snapshot "grows"). --matt
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
